A company has a central S3 bucket for logs (central-logs-bucket) in account 123456789012. The bucket policy is shown in the exhibit. A developer in account 111111111111 tries to access an object in the bucket using the AWS CLI without the --no-sign-request option. The request fails. What is the MOST likely cause?
The Principal is set to the root user of the bucket owner account.
Why this answer
The bucket policy in the exhibit uses a Principal element of `"AWS": "arn:aws:iam::123456789012:root"`. This grants access only to the root user of account 123456789012, not to any IAM users or roles in that account, and certainly not to any principals in account 111111111111. When the developer from account 111111111111 attempts to access the object with a signed request (no --no-sign-request), the request is signed with credentials from that account, which are not listed in the Principal, so S3 denies the request.
Exam trap
The trap here is that candidates often confuse the `aws:SecureTransport` condition with request signing, or assume that a bucket policy that grants access to one account's root user automatically allows all IAM users in that account, when in fact it only allows the root user itself.
How to eliminate wrong answers
Option A is wrong because the bucket policy does not explicitly deny access from other accounts; it simply grants access only to the root user of account 123456789012, which implicitly denies all others by default. Option C is wrong because the question states the developer uses the AWS CLI without --no-sign-request, meaning the request is signed, and there is no indication that HTTPS is not used; the `aws:SecureTransport` condition would only deny if the request were over HTTP, which is not stated. Option D is wrong because the request is signed (no --no-sign-request), so it is not an unsigned request; the `aws:SecureTransport` condition checks for HTTPS, not for signing, and the failure is due to the Principal restriction, not transport security.