Sample question 1 — Security and Compliance
A security team in account 111122223333 needs to read objects from a bucket owned by account 444455556666. The bucket policy in the owning account already grants s3:GetObject and s3:ListBucket to the role arn:aws:iam::111122223333:role/AuditRole. When an engineer assumes AuditRole and runs an aws s3 ls command, the request returns AccessDenied even though the bucket policy looks correct. Which cause should the SysOps administrator investigate first?
- A. The bucket policy lacks a condition restricting access to the AuditRole's VPC endpoint
- B. The role's trust policy does not list the audit account as a permitted principal
- C. The identity-based policy attached to AuditRole does not allow the S3 read actions
- D. The S3 bucket is encrypted with SSE-KMS and the role lacks kms:Decrypt permission
Answer: C. Option C is correct because cross-account access requires both the resource-based bucket policy and an identity-based policy on the role to allow the action; if AuditRole has no S3 permissions attached, the request is denied even though the bucket policy grants access. Option D is incorrect because an SSE-KMS denial would surface only for objects encrypted with a customer managed key and would not block the s3 ls listing call itself. Option A is incorrect because a missing VPC endpoint condition would not cause a denial; the bucket policy already grants the actions unconditionally. Option B is incorrect because the trust policy controls who may assume AuditRole, and the engineer successfully assumed it, so the trust relationship is already working.