AWS Certified Security – SpecialtyDomain 4: Identity and Access ManagementMedium
A company is implementing a new compliance requirement that mandates all access to AWS resources must adhere to the principle of least privilege. They have an existing IAM user, 'AuditorUser', who has an attached policy allowing `s3:GetObject` on `arn:aws:s3:::my-sensitive-data-bucket/*`. However, a separate, broader policy attached to the 'AuditorGroup' (to which 'AuditorUser' belongs) explicitly denies `s3:*` actions on `arn:aws:s3:::my-sensitive-data-bucket/*`. When 'AuditorUser' attempts to retrieve an object from `my-sensitive-data-bucket`, what is the outcome, and why?
- AAccess is denied because the `s3:GetObject` action is less privileged than `s3:*`, and the broader deny takes precedence.
- BAccess is allowed because the explicit allow policy on the user takes precedence over the group's explicit deny policy.
- CAccess is denied because an explicit deny policy always overrides any allow policies, regardless of where they are attached.
- DAccess is allowed because group policies are evaluated first, and if allowed, user policies are then applied.
Show answer & explanationAnswer & explanation
Correct answer: C. Access is denied because an explicit deny policy always overrides any allow policies, regardless of where they are attached.
In IAM policy evaluation, an explicit deny always takes precedence over any explicit allow. This means if any policy (user, group, role, resource, or SCP) explicitly denies an action, that action will be denied, even if another policy explicitly allows it.
Why the other options are wrong
- A. The granularity of the action (`s3:GetObject` vs `s3:*`) does not change the explicit deny's precedence. The `s3:*` in the deny covers `s3:GetObject`.
- B. This is incorrect. Explicit denies always override explicit allows in IAM policy evaluation.
- D. The order of evaluation (user vs. group) does not change the fundamental rule that an explicit deny takes precedence.
IAM Policy Evaluation Logic
AWS IAM evaluates policies (identity-based, resource-based, SCPs, permissions boundaries) to determine access, with an explicit deny always overriding any explicit allow.
- Explicit Deny > Explicit Allow.
- Default Deny if no explicit allow or deny.
- Context (conditions) also affects evaluation.
- Policies are evaluated in combination, not sequentially.
Memory trick: Deny is a Red Light, always stops an Allow Green Light.