How to Enforce S3 Bucket Versioning with AWS Config?

Answer Correct answer: B — Use AWS Config's s3-bucket-versioning-enabled rule with automatic remediation via the AWS-ConfigureS3BucketVersioning SSM Automation runbook.

A CloudOps engineer must ensure that all of a company's Amazon S3 buckets have versioning enabled. Which solution will meet this requirement?

  1. Enable AWS Config. Set up the s3-bucket-versioning-enabled AWS Config managed rule. Specify the configuration changes trigger type. Configure an automatic remediation action that uses an AWS Lambda function to enable versioning on noncompliant S3 buckets.
  2. Enable AWS Config. Set up the s3-bucket-versioning-enabled AWS Config managed rule. Specify the configuration changes trigger type. Configure an automatic remediation action that uses the AWS-ConfigureS3BucketVersioning AWS Systems Manager Automation runbook to enable versioning on noncompliant S3 buckets. Correct Answer
  3. Enable Amazon GuardDuty. Use GuardDuty to identify S3 buckets that have versioning disabled. Create an Amazon EventBridge rule that sends the GuardDuty findings to AWS Systems Manager Automation. Specify the AWS-ConfigureS3BucketVersioning Systems Manager Automation runbook to enable versioning on noncompliant S3 buckets.
  4. Enable Amazon GuardDuty. Use GuardDuty to identify S3 buckets that have versioning disabled. Create an Amazon EventBridge rule that sends the GuardDuty findings to a target AWS Lambda function. Configure the Lambda function to enable versioning on noncompliant S3 buckets.

Community Insight

The exam tests configuration-compliance remediation versus threat detection; the trap is assuming GuardDuty can report a disabled S3 versioning setting or that a custom Lambda is required.

This SOA-C03 question tests enforcing Amazon S3 bucket versioning with an AWS Config managed rule and automatic remediation. The correct solution uses the s3-bucket-versioning-enabled rule with the AWS-ConfigureS3BucketVersioning Systems Manager Automation runbook (B), not GuardDuty findings or a custom Lambda.

A common mistake is selecting GuardDuty-based options C or D because GuardDuty surfaces S3-related findings, but it detects threats and anomalous activity rather than whether versioning is enabled; a custom Lambda (A) also adds unnecessary code when the managed SSM runbook exists.

Community Discussion (1 comments)

Bad_Mat 👍 1 Selected: B
B. Enable AWS Config. Set up the s3-bucket-versioning-enabled AWS Config managed rule. Specify the configuration changes trigger type. Configure an automatic remediation action that uses the AWS-ConfigureS3BucketVersioning AWS Systems Manager Automation runbook to enable versioning on noncompliant S3 buckets

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

Option B aligns with AWS Config's intended compliance-and-remediation workflow: the managed rule s3-bucket-versioning-enabled continuously evaluates S3 bucket configuration, and the configuration-changes trigger evaluates buckets when their settings change. The automatic remediation action invokes the AWS-ConfigureS3BucketVersioning Systems Manager Automation runbook, which enables versioning on each noncompliant bucket without custom code. This is the cleanest fit for ensuring all S3 buckets have versioning enabled because it combines detection with a native, repeatable remediation. It also keeps remediation logic in AWS-managed automation rather than an engineer-maintained function.

Why the Other Options Are Wrong

Option A is not the best answer because it uses a custom Lambda function for remediation; although Lambda can call PutBucketVersioning, it adds code and permissions that the managed SSM runbook already provides. Options C and D rely on Amazon GuardDuty to identify buckets with versioning disabled, but GuardDuty is a threat-detection service and does not produce findings for a missing bucket configuration. Consequently, the EventBridge-to-SSM or EventBridge-to-Lambda paths in C and D have no valid GuardDuty finding to trigger on. The exam favors the AWS Config managed rule plus managed remediation over either custom or misapplied service wiring.

Community Comment Notes

Bad_Mat's comment selects option B and calls out the AWS-ConfigureS3BucketVersioning runbook as the remediation target, which matches the AWS Config native pattern. There is no substantive counter-comment in the provided thread, so the community signal is sparse but consistent with option B. The key takeaway from the comment is that the runbook, not a custom Lambda, is the expected remediation mechanism for this managed rule. Learners should still verify the rule and runbook names in current AWS documentation because AWS occasionally updates remediation assets.

Official Reference

Exam Strategy

When the requirement is to enforce a resource configuration standard, look first for an AWS Config managed rule plus automatic remediation. Eliminate GuardDuty options because GuardDuty is not a configuration-compliance evaluator, and prefer AWS-managed SSM Automation runbooks over custom Lambda code.

Frequently Asked Questions

Why can't GuardDuty detect S3 buckets with versioning disabled?

GuardDuty is a threat-detection service that analyzes activity and produces security findings, not resource configuration compliance; it does not evaluate S3 versioning settings.

Why use the AWS-ConfigureS3BucketVersioning runbook instead of a Lambda function?

The SSM Automation runbook is an AWS-managed remediation that enables versioning without custom code, while a Lambda function requires you to build and maintain the logic.

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