How to Enforce S3 Bucket Tags and Policies with Self-Service Provisioning?

Answer Correct answer: D — Use AWS Service Catalog products that apply the Confidential or Nonconfidential tag and restrictive bucket policy to S3 buckets at creation.

A security team requires that all Amazon S3 buckets that contain sensitive data must be tagged as "Confidential" and use a restrictive bucket policy. All other buckets must be tagged as "Nonconfidential". A CloudOps engineer needs to provide a self-service provisioning mechanism that allows different development teams to create S3 buckets with the appropriate tags and policies applied upon creation. Which solution will meet these requirements in the MOST reliable way?

  1. Create an AWS CloudFormation template to create S3 buckets that include a parameter for the classification tag. Distribute the template to all the development teams to use when creating S3 buckets.
  2. Create an AWS Step Functions workflow that is triggered by every newly created S3 bucket. Configure the workflow to assign the correct bucket policy after the buckets are provisioned by the development teams.
  3. Create an AWS Config rule to check if newly created S3 buckets are correctly tagged as "Nonconfidential" or "Confidential" after the buckets are provisioned by the development teams. Create an AWS Systems Manager Automation document to be triggered by AWS Config for noncompliant buckets.
  4. Create two separate AWS Service Catalog products named "Nonconfidential S3 Bucket" and "Confidential S3 Bucket" for creating the S3 buckets. Preconfigure each product with an S3 bucket and the appropriate bucket policy for its classification tag. Correct Answer

Community Insight

The question tests preventive self-service governance versus detective remediation; the trap is choosing AWS Config or a distributed CloudFormation template that teams can alter or bypass.

AWS Service Catalog products let an administrator preconfigure S3 bucket tags and restrictive bucket policies so development teams self-provision compliant Confidential or Nonconfidential buckets. This page confirms option D as the most reliable preventive control for the SOA-C03 scenario.

Learners often pick AWS Config with SSM Automation (C) because it sounds automated, but it only detects and remediates noncompliant buckets after creation rather than enforcing tags and policies at provisioning time.

Community Discussion (1 comments)

Bad_Mat 👍 1 Selected: D
The correct answer is D. Create two separate AWS Service Catalog products named "Nonconfidential S3 Bucket" and "Confidential S3 Bucket" for creating the S3 buckets. Preconfigure each product with an S3 bucket and the appropriate bucket policy for its classification tag.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

AWS Service Catalog is built for governed self-service: an administrator publishes products that encapsulate an S3 bucket, its classification tag, and the required restrictive bucket policy, and development teams launch only those products. Because the tag and policy are baked into each product's template or launch constraint, teams cannot accidentally create a bucket without the "Confidential" or "Nonconfidential" tag. This makes D the only option that enforces the requirement at creation time while still giving teams self-service. It also centralizes updates and access control through portfolios.

Why the Other Options Are Wrong

Option A distributes a CloudFormation template with a classification parameter; teams can choose the wrong value, edit the template, or create buckets outside it, so it is not reliable enforcement. Option B reacts after the bucket exists and would need an EventBridge integration; even then, there is a window where the bucket is untagged and lacks the policy. Option C uses AWS Config and SSM Automation, which are detective and remedial controls that run after provisioning—the bucket can already be noncompliant and potentially used before remediation. None of A, B, or C prevents the misconfiguration at the moment of creation.

Community Comment Notes

Bad_Mat's comment states "The correct answer is D. Create two separate AWS Service Catalog products" and explains that each product should preconfigure the S3 bucket and the appropriate bucket policy for its classification tag. That aligns with the preventive, self-service design of Service Catalog. The comment effectively rejects the after-the-fact approaches in B and C and the editable template in A.

Official Reference

Exam Strategy

When the stem asks for self-service provisioning with guaranteed tags or policies at creation, favor AWS Service Catalog products; when it asks to detect drift or remediate existing resources, favor AWS Config. Watch for phrases such as "most reliable" and "upon creation" because they point to preventive controls over detective ones.

Frequently Asked Questions

Why is a CloudFormation template parameter insufficient for enforcing the Confidential tag?

A distributed template can be modified or skipped by teams, and the parameter allows either tag; only Service Catalog products constrain the input and policy at provisioning.

Why does AWS Config with SSM Automation not meet the 'upon creation' requirement?

AWS Config evaluates buckets after they exist, so a noncompliant bucket can be created and used before remediation runs; it is detective, not preventive.

More SOA-C03 FAQ →

Related Analysis

Practice All SOA-C03 Questions

Access 100 questions with complete answers and detailed explanations.

View Full SOA-C03 Practice Test →

← Back to SOA-C03 Study Guide