Season 4: One Company, Two Clouds · Episode 7 of 8
An IAM Policy Walks into a Bucket
You play: AI Engineering Intern
Included with Core programme and Certification prep
The situation
An audit-log alert fires: the partner analytics role, `partner-analytics`, is reading creator export files it shouldn't be able to see. Its policy was meant to allow one approved prefix of exports; it actually allows the whole export bucket, including raw pipeline output. While you're in the logs, Lydia points at a second problem — someone has been running daily deploys as the AWS root account.
What you'll learn
- CLF-C02 security and compliance: the shared responsibility model for security, IAM policy evaluation (default deny, explicit allow, explicit deny wins), least-privilege policy scoping, root-account protection, encryption at rest and in transit, audit logs as evidence, and who owns which control.
- Matching security needs to AWS services (Shield, WAF, Firewall Manager, GuardDuty, Detective, Security Hub, Inspector, Macie, KMS, Secrets Manager, Certificate Manager, Artifact, Config, CloudTrail, Audit Manager, Trusted Advisor), tasks only the root user can do, IAM Identity Center, and avoiding long-lived access keys.
Who you work with
Lydia Roe
Security Engineer
Priya Naidoo
Cloud Architect
Scenes
- 1.The audit alert
- 2.Fine or risky
- 3.Scope the policy
- 4.Write the bucket policy
- 5.Which security service?
- 6.Read the log again
- 7.Security check
What you leave with
The partner role is scoped to the approved export bucket only — read approved allowed, read raw denied, no write — with the policy diff and the two-sided test kept as audit evidence. Reading the log again caught the caption function's role writing where it shouldn't, correctly identified as a Code Nexus-owned IAM misconfiguration under shared responsibility, and root-for-deploys was flagged as a separate finding.