SCS-C02 Security Logging and Monitoring Practice Question

Exhibit

Refer to the exhibit.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-log-bucket/AWSLogs/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    }
  ]
}

A security engineer has attached the above IAM policy to a role used by an application to write logs to an S3 bucket. However, the application is unable to write logs. What is the MOST likely reason?

⚠ Common exam trap

The trap here is that candidates often focus on IAM policy syntax errors (like ARN format or missing actions) and overlook the requirement for specific request headers (like ACLs) that are enforced by the bucket policy or S3 default settings, not by the IAM policy itself.

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 application does not set the x-amz-acl header to bucket-owner-full-control on PutObject requests.

When an IAM policy grants PutObject access to an S3 bucket, the application must also include the `x-amz-acl: bucket-owner-full-control` header in its PutObject requests to ensure the bucket owner retains full control over the uploaded objects. Without this header, the object is owned by the writer (the role), and the bucket owner cannot manage it, causing the write to fail due to access control mismatches, especially in cross-account scenarios or when the bucket policy enforces specific ACLs.

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 Effect is set to Allow, which is too permissive.
Why it's wrong here
The Effect line is correctly set to Allow because that is the only way to grant the application permission to call PutObject. Changing it to Deny would actively block every write request, including legitimate ones that include the required ACL header. The policy already applies least privilege by using a Condition that constrains allowed requests to those with bucket-owner-full-control, so Allow is not too permissive.
✓
The application does not set the x-amz-acl header to bucket-owner-full-control on PutObject requests.
Why this is correct
The application is failing because the IAM policy includes a Condition key s3:x-amz-acl with StringEquals bucket-owner-full-control. For S3 to allow a PutObject call, the request must carry an x-amz-acl header matching that exact value; if the header is absent or different, S3 treats the condition as unmet and denies the request. IAM permissions alone don't bypass S3's request-level parameter checks. The application must explicitly set the header in each PutObject request.
✗
The policy does not allow server-side encryption.
Why it's wrong here
Server-side encryption is a separate concern from the policy that governs access; the policy's lack of an encryption reference does not cause the failure. IAM policies cannot 'allow' encryption—they only allow or deny S3 actions, optionally conditioned on encryption headers. If encryption were required, the bucket would likely have a default or the application would need to send x-amz-server-side-encryption, but that isn't related to the x-amz-acl condition that is actually rejecting the request.
✗
The resource ARN is incorrect; it should be arn:aws:s3:::my-log-bucket/*.
Why it's wrong here
The resource ARN shown in the policy is already appropriate: it targets the AWSLogs/ prefix where the logs are written, e.g., arn:aws:s3:::my-log-bucket/AWSLogs/*. Using my-log-bucket/* would merely broaden scope to all objects, not fix the denial, because S3 would still refuse the request due to the missing ACL header. S3 resource ARNs for objects always end with /*, so the provided ARN is syntactically and semantically correct.

Visual reference

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

Practice tests

Short scored sets — answer, get feedback, read the explanation, move on.

SCS-C02 Exam Simulation 1 — 100 Questions→Free SCS-C02 Practice Test 1 — 30 Questions→

Domain-focused practice

Drill one exam section at a time instead of jumping between unrelated topics.

Security Logging and Monitoring Identity and Access Management Threat Detection and Incident Response

Practice by question type

Pick a question style and work only that format until it feels routine.

Browse scenarios

Go deeper on a topic

One concept per page — questions, worked explanations, and a short concept guide.

Security Logging and Monitoring practice questions SCS-C02 troubleshooting practice questions Threat Detection and Incident Response practice questions

Keep going

All SCS-C02 questions AWS Certified Security Specialty SCS-C02 exam guide SCS-C02 practice test

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.

SCS-C02 Security Logging and Monitoring Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question