SAP-C02 Practice Question: Design Solutions for Organizational Complexity

A company needs to share a central Amazon S3 bucket containing common data files with multiple accounts in AWS Organizations. Which approach is most secure and scalable?

⚠ Common exam trap

Watch out — candidates often choose Option C (cross-account IAM roles) because it is a familiar pattern, but they overlook the simpler and more scalable centralized policy approach using the Organization ID condition key, which AWS specifically tests for centralized resource sharing scenarios.

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

✓

Use an S3 bucket policy that grants access to the organization using aws:PrincipalOrgID condition key.

Using the `aws:PrincipalOrgID` condition key in an S3 bucket policy allows you to grant access to all principals (users, roles) within your AWS Organization without needing to list individual account IDs. This approach is both secure (no public access) and scalable (automatically includes new accounts added to the organization).

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Make the bucket public with read-only access.
Why it's wrong here
Public read access exposes the objects to anyone on the internet, removing account-level control and violating least privilege. Bucket policies scoped to organisation account principals, combined with IAM roles, grant access only to the intended accounts. Public buckets are chosen only for genuinely anonymous content such as static website assets.
✗
Generate presigned URLs for each account to access the bucket.
Why it's wrong here
Presigned URLs expire and must be generated per object or prefix, so they cannot scale to ongoing multi-account access to a shared bucket. They suit temporary, time-limited downloads by unauthenticated or external parties. Cross-account access with bucket policies and IAM roles provides durable, auditable sharing.
✗
Create IAM roles in each account with permissions to assume a role in the central account.
Why it's wrong here
This inverts the trust direction: each account's role would need to be trusted by the central account, multiplying trust policies and credentials as accounts grow. Resource-based bucket policies granting Organisation-wide access scale without per-account roles. Cross-account role assumption suits one-off, tightly scoped access between two named accounts.
✓
Use an S3 bucket policy that grants access to the organization using aws:PrincipalOrgID condition key.
Why this is correct
The aws:PrincipalOrgID condition restricts the bucket policy to principals belonging to the specified organisation, so any current or future member account gains access without editing the policy. This scales automatically as accounts are added and avoids wildcard principal exposure.

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

SAP-C02 Practice Question: Design Solutions for Organizational Complexity

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question