Q. Last IAM change you led that reduced risk (what + why)

In my roles at OpenText and Diehl Metering, I worked on multi-account AWS environments using landing zones, SCP guardrails, and IAM role-based access.

During an IAM audit, I identified key risks:

  • Long-lived IAM users with static access keys

  • Access keys not rotated or encrypted

  • Over-permissive policies (*:*)

  • Credential sharing across application teams

  • Inconsistent IAM practices across accounts

For example, we found production access keys older than 90 days still active and not rotated, which increased the risk of credential compromise.

Actions taken:

  • Migrated from IAM users to IAM roles using STS-based temporary credentials

  • Enforced role-based access for applications and engineers

  • Designed IAM roles aligned to job functions and service boundaries

  • Automated access key remediation: - Detected non-compliant keys (age, usage, encryption) - Used AWS Lambda with EventBridge and Step Functions to deactivate or delete keys

  • Prevented over-permissive access: - Introduced guardrails to detect *:* patterns - Enforced policy review before deployment

  • Removed credential sharing: - Shifted teams to role-based access - Reinforced shared responsibility model

  • Standardised IAM using Terraform modules and defined a consistent process for IAM changes

Outcome:

  • Eliminated long-lived credentials in production

  • Reduced identity-related attack surface

  • Prevented creation of overly permissive policies

  • Improved consistency of IAM practices across accounts