Quiz: AWS IAM¶
6 questions
L1 (4 questions)¶
1. A bucket policy allows s3:GetObject for Principal: '*'. An IAM policy attached to user Alice explicitly denies s3:GetObject. Can Alice read objects from the bucket?
Show answer
No. An explicit Deny in any policy always overrides an Allow from any other policy. Alice's IAM Deny takes precedence over the bucket policy's Allow. This is the fundamental rule of AWS policy evaluation:1. If any policy explicitly Denies, the request is denied (final).
2. If any policy explicitly Allows and no policy Denies, the request is allowed.
3. If no policy addresses the action, the request is denied by default (implicit deny). However: this only applies to principals within the same AWS account. Anonymous (unauthenticated) users are not subject to Alice's IAM policy — they would still be allowed by the bucket policy's Principal: '*'. To truly block public access, use S3 Block Public Access.
2. Alice in Account-A has an IAM policy allowing sts:AssumeRole for a role in Account-B. She cannot assume it and gets AccessDenied. What is missing?
Show answer
The role in Account-B must have a trust policy (AssumeRolePolicyDocument) that explicitly allows Account-A (or Alice specifically) to assume it. Cross-account role assumption requires BOTH sides to agree:1. The caller's identity-based policy must allow sts:AssumeRole on the target role ARN (Alice has this).
2. The target role's trust policy must allow the caller's principal (account, user, or role ARN) in its Principal element. Without the trust policy allowing Account-A, the AssumeRole call is denied regardless of Alice's permissions. This two-way handshake prevents one account from unilaterally accessing another account's resources.
3. A Lambda function assumes an IAM role and receives temporary credentials. The function runs as a long-running batch job (15 minutes, the Lambda max). Halfway through, API calls start failing with ExpiredTokenException. What happened?
Show answer
Lambda's default execution role credentials are automatically refreshed by the Lambda runtime and typically last for the duration of the invocation (up to 6 hours). ExpiredTokenException in a Lambda usually means:1. The function manually calls sts:AssumeRole to get a DIFFERENT role's credentials, and those credentials expired (default STS token duration is 1 hour, but can be as short as 15 minutes).
2. The assumed role's maximum session duration is set lower than expected. Fix: set DurationSeconds in the AssumeRole call to match your job's runtime, ensure the role's MaxSessionDuration allows it (default 1 hour, max 12 hours). For Lambda's own execution role, credentials are managed automatically — you should not need to manually assume it.
4. IAM Access Analyzer finds a role with AdministratorAccess that hasn't been used in 90 days. Should you delete it immediately?
Show answer
No. First investigate:1. Check the role's last-used data (IAM console > Role > Last activity) — 90 days unused could mean it's for quarterly jobs (DR drills, annual audits, compliance scans).
2. Check if the role is referenced in automation (CloudFormation, Terraform, CI/CD) that hasn't run recently.
3. Check if it's a break-glass role for emergencies — these are intentionally rarely used. Safe approach:
1. Add a Deny-all inline policy to the role (effectively disabling it without deleting).
2. Wait 2-4 weeks and monitor for failures.
3. If nothing breaks, delete the role. For AdministratorAccess specifically: even if the role is legitimately needed, scope it down to the actual required permissions using the Access Advisor's service-last-accessed data.
L2 (2 questions)¶
1. You create a delegated-admin role with a permission boundary that restricts actions to us-east-1. The admin creates an EC2 instance in us-west-2. Does it succeed?
Show answer
No. Permission boundaries set the maximum permissions an IAM entity can have. The effective permissions are the intersection of the identity-based policy AND the permission boundary. Even if the delegated-admin role's identity policy allows ec2:RunInstances in all regions, the permission boundary limiting to us-east-1 means the us-west-2 request is outside the intersection and is denied. Permission boundaries are designed for exactly this delegation use case: you grant broad EC2 management permissions in the identity policy but use the boundary to scope it to specific regions, accounts, or resource types. The admin can never exceed the boundary, even if they modify their own identity policies (which the boundary also restricts).2. Your Organization has an SCP that allows only s3:GetObject and s3:PutObject. An IAM policy in a member account grants s3:*. Can a user in that account perform s3:DeleteObject?