SCS-C02 Management and Security Governance Practice Question
A company wants to grant cross-account access to an S3 bucket owned by Account A to a user in Account B. The bucket policy in Account A allows access from Account B. What additional configuration is required?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The IAM user in Account B must have a policy that allows access to the S3 bucket.
Cross-account access to an S3 bucket requires both a resource-based policy (the bucket policy in Account A) and an identity-based policy (an IAM policy attached to the user or role in Account B). The bucket policy grants access to the external account, but the IAM user in Account B must also have an explicit policy that allows the desired actions (e.g., s3:GetObject). Therefore, Option A is correct. Option B is incorrect because the bucket policy alone is not sufficient. Option C is incorrect because ACLs are not required and are generally not recommended for cross-account access. Option D is incorrect because SCPs (Service Control Policies) are used for organization-wide guardrails and are not required for this specific cross-account access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The IAM user in Account B must have a policy that allows access to the S3 bucket.
Why this is correct
The bucket policy in Account A grants the IAM user (or Account B) the ability to access the S3 bucket, but cross-account access requires an explicit allow from the requester's own account as well. The IAM user in Account B must have an identity-based policy that permits the specific S3 action (e.g., s3:GetObject) on the target bucket or object ARN. AWS evaluates both the resource-based bucket policy and the identity-based policy, and if either does not explicitly allow the action, the request is denied. Without this IAM policy, the user may have no effective permission to perform the S3 operation despite the bucket policy granting access.
- ✗
Nothing; the bucket policy is sufficient.
Why it's wrong here
A bucket policy alone is not sufficient for cross-account S3 access because resource-based policies only control the resource side of the authorization and do not grant an identity permission to make the request. The IAM user in Account B must also have an identity-based policy that authorizes the s3:GetObject action; otherwise, the user's own account denies access before the resource-based policy is even meaningfully evaluated. In AWS authorization, an explicit allow from both the identity-based and resource-based policies is required for cross-account requests, so the statement that nothing else is needed is incorrect.
- ✗
The bucket must be configured with ACLs.
Why it's wrong here
S3 access control lists (ACLs) are a legacy authorization mechanism that is not required for cross-account access and is disabled by default when Object Ownership is set to bucket owner enforced. Modern cross-account access should be configured using bucket policies combined with IAM identity-based policies, which provide more flexible, principal-based grants. Even if ACLs are present, they alone do not grant an IAM user in Account B the required permissions because ACLs typically grant access to AWS accounts, and the IAM user still needs an identity-based policy. Therefore, saying the bucket must be configured with ACLs is incorrect.
- ✗
An SCP must allow the s3:GetObject action.
Why it's wrong here
Service control policies (SCPs) are used in AWS Organizations to guardrail the maximum permissions available to accounts, and they never grant or allow actions. An SCP that explicitly denies s3:GetObject could block cross-account access, but the absence of an SCP deny is all that matters from an SCP perspective; SCPs are not a required component for cross-account access. Cross-account access is governed by identity-based and resource-based policies, not by SCPs, which only filter permissions when the accounts belong to an organization. Thus, requiring an SCP to allow the s3:GetObject action is incorrect.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
Courseiva writes every SCS-C02 question from scratch — 1,205 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SCS-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SCS-C02 exam.