DVA-C02 Security Practice Question
A company has an S3 bucket that stores log files. The bucket policy grants the AWSServiceRoleForSSO service role write access. However, the logs are not being written. What is the MOST likely reason?
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 bucket policy uses a service role ARN that is not a valid principal for S3 bucket policies.
The bucket policy uses the ARN of the AWSServiceRoleForSSO service-linked role as the principal, but S3 bucket policies do not accept service role ARNs as valid principals. Instead, you must use the AWS service principal (e.g., sso.amazonaws.com) when granting permissions to an AWS service that uses a service role. Therefore, the policy fails to grant write access. Options A, C, and D are incorrect: S3 Block Public Access settings only block public access, not access from service roles; bucket ACLs are not effective when a bucket policy exists and private ACLs do not prevent authorized writes; default encryption with SSE-S3 does not block writes from any principal.
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 bucket has S3 Block Public Access enabled, which blocks all service role access.
Why it's wrong here
S3 Block Public Access (BPA) is designed to prevent unintended public exposure of S3 buckets and objects, specifically blocking access from unauthenticated users or cross-account authenticated users that are not explicitly granted access via an IAM policy. It does not, however, block access from AWS service roles operating within the same account or explicitly authorized cross-account roles. Service roles are considered trusted principals, not "public" entities in the context of BPA, and their access is governed by IAM policies and bucket policies.
- ✓
The bucket policy uses a service role ARN that is not a valid principal for S3 bucket policies.
Why this is correct
S3 bucket policies require a valid principal to define who can perform actions on the bucket. While IAM roles are principals, a service role's ARN itself is typically not the correct principal to specify directly in an S3 bucket policy when granting permissions to an AWS service. Instead, the *service principal* for the AWS service (e.g., `logs.amazonaws.com` for CloudWatch Logs, or `s3.amazonaws.com` for S3 itself) should be used to allow the service to write to the bucket on behalf of its users or internal processes. This distinction is crucial for proper cross-service authorization.
- ✗
The bucket ACL is set to private, which prevents service role writes.
Why it's wrong here
Bucket Access Control Lists (ACLs) are a legacy access control mechanism primarily used for granting permissions to other AWS accounts or predefined S3 groups at the bucket or object level. They are not the primary or recommended method for granting permissions to AWS service roles or AWS services. Modern S3 access control relies heavily on IAM policies and S3 bucket policies, which offer more granular control and are the appropriate mechanisms for defining permissions for service roles to interact with S3 buckets.
- ✗
The bucket has default encryption enabled using SSE-S3, which prevents writes from service roles.
Why it's wrong here
Server-Side Encryption with S3-managed keys (SSE-S3) automatically encrypts objects as they are written to S3 and decrypts them upon retrieval. This encryption mechanism is transparent to authorized users and services; it does not act as an access control layer to prevent writes. Any principal with `s3:PutObject` permissions can write objects, and S3 handles the encryption and decryption seamlessly using its own keys, without blocking legitimate write operations from service roles.
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 DVA-C02 question from scratch — 1,135 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 DVA-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 DVA-C02 exam.