DEA-C01 Data Security and Governance Practice Question
A data engineer needs to restrict access to an S3 bucket so that only users from a specific AWS account can read objects. Which S3 bucket policy element should be used?
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
✓
Principal
The Principal element in an S3 bucket policy specifies the AWS account, user, or role that the policy applies to. By setting the Principal to a specific AWS account ID, only users from that account can read objects. Option A is wrong because the Action element specifies the allowed or denied operations (e.g., s3:GetObject), not the account. Option C is wrong because the Resource element identifies the bucket or objects, not the requester. Option D is wrong because the Condition element adds additional constraints (e.g., IP address), but it is not the primary element for specifying the allowed account; Principal is the correct element for that purpose.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Action
Why it's wrong here
Action lists the S3 operations permitted, such as s3:GetObject, but never identifies which AWS account may perform them, so any principal granted that action could read objects. It is tempting because specifying s3:GetObject is mandatory in any read policy, and it correctly limits access to read-only operations.
- ✓
Principal
Why this is correct
The Principal element names the AWS account permitted to read objects, directly satisfying the cross-account restriction. Bucket policies evaluate Principal against the requesting identity, so specifying the trusted account's ARN grants access solely to its users, excluding all other accounts.
- ✗
Resource
Why it's wrong here
Resource identifies the bucket or objects the statement applies to, not who may access them, so it cannot restrict reads to a specific AWS account. It is tempting because every bucket policy requires a Resource element, and scoping it to object ARNs correctly limits which objects a statement covers.
- ✗
Condition
Why it's wrong here
Condition adds constraints such as source IP or MFA to a statement but does not itself name the trusted AWS account, so reads would not be limited to that account. It is tempting because conditions commonly restrict access by network origin, which suits scenarios where the trusted account's IP range is fixed.
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 DEA-C01 question from scratch — 1,321 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 DEA-C01 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 DEA-C01 exam.