SOA-C02 Deployment, Provisioning, and Automation Practice Question

Exhibit

Refer to the exhibit.

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

A SysOps administrator is troubleshooting a CodeDeploy deployment that uploads artifacts to an S3 bucket. The deployment fails with an 'AccessDenied' error. The IAM policy for the CodeDeploy service role includes the statement shown in the exhibit. What is the most likely cause of the failure?

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 upload does not set the ACL to 'bucket-owner-full-control'.

The policy includes a condition that requires the object's ACL to be set to 'bucket-owner-full-control'. If the upload does not specify this ACL in the request, the condition is not met, and the request fails with AccessDenied. Therefore, option A is correct. Option B is incorrect because the resource ARN does include the bucket (the policy grants access to objects within the bucket). Option C is incorrect because the policy does not mention encryption headers; the condition is about ACL. Option D is incorrect because the s3:PutObject action is allowed by the policy; the failure is due to the condition on ACL.

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 upload does not set the ACL to 'bucket-owner-full-control'.
Why this is correct
The upload is denied because CodeDeploy's S3 upload does not include the 'x-amz-acl' header set to 'bucket-owner-full-control'. The bucket policy's condition explicitly requires this ACL value for any PutObject request, and because the header is absent or set differently, S3 evaluates the condition as false and returns AccessDenied. This is the exact mismatch the policy is designed to catch, making the fix to add --acl bucket-owner-full-control to the upload command.
✗
The resource ARN does not include the bucket itself.
Why it's wrong here
The resource ARN in a bucket policy for an object operation uses the pattern 'arn:aws:s3:::bucket/*' to match objects within the bucket. Including the bucket itself ('arn:aws:s3:::bucket') would only match operations on the bucket resource, not on individual objects, but for PutObject that ARN is not required. The policy's resource ARN already correctly covers the target objects, so this is not the cause of the failure.
✗
The policy does not allow encryption headers.
Why it's wrong here
Encryption headers such as 'x-amz-server-side-encryption' are unrelated to the failure because the bucket policy condition targets the 's3:x-amz-acl' header, not encryption-related headers. S3 evaluates condition keys independently; an ACL mismatch does not involve encryption, and adding encryption headers would not satisfy the ACL condition. Therefore, this option misidentifies the failing header type.
✗
The policy does not allow the s3:PutObject action.
Why it's wrong here
The policy explicitly includes the 's3:PutObject' action in the Allow statement, so the action itself is permitted. If the action were not allowed, the request would be denied regardless of the ACL header, but the error occurs because the ACL condition fails after the action is matched. Since the policy only blocks requests that lack the required ACL, the action being allowed is confirmed by the request progressing to condition evaluation.

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

1 more way this is tested on SOA-C02

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. A SysOps administrator is deploying a new version of an application using AWS CodeDeploy. The deployment to an Auto Scaling group fails, and the instances are rolled back. What is the most likely reason for the failure?

easy

A.The instances are in a private subnet without a NAT gateway.
B.The instances do not have internet access.
✓ C.The IAM instance profile does not have permission to download the revision from S3.
D.The application's health check is failing on the target group.

Why C: CodeDeploy agents on EC2 instances must download the application revision from its S3 bucket or GitHub location, and they authenticate using the instance profile attached to the instance. If that IAM role lacks `s3:GetObject` on the revision bucket, the download fails and CodeDeploy rolls back the deployment. This is the most common cause of a CodeDeploy failure that triggers automatic rollback.

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SOA-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 SOA-C02 exam.