Store guardrail templates in CodeCommit and auto-trigger a CodePipeline pipeline via EventBridge for each OU

Why the Answer Is Correct

The solution must satisfy four properties: the guardrails are applied to all accounts in an organizational unit, they are under version control so they can be reviewed and rolled back, they are managed by the security team within their own OU, and only new guardrails the security team has approved may be applied. Storing individual CloudFormation templates, each containing an AWS::ControlTower::EnableControl logical resource for an organizational unit, in an AWS CodeCommit repository provides the version control, the review workflow through pull requests, and the rollback capability through commit history that the requirement asks for (C). A CodePipeline pipeline in the security team's account is then configured, and an Amazon EventBridge rule is set to invoke it when changes occur in that CodeCommit repository (C). Because the pipeline runs only in response to a repository change, a guardrail takes effect only after it has been committed, which makes the commit the approval gate and satisfies the requirement that only approved guardrails be applied; it also removes the manual pipeline invocation step. Srikantha noted that version control is managed through CodeCommit so guardrail changes can be reviewed and rolled back if necessary, and that approval and governance are built into the process. uncledana described C as the most efficient and scalable solution, meeting the requirements for version control, approval, and rollback with minimal effort. C is the correct answer.

Why the Other Options Are Wrong

A creates individual CloudFormation templates containing the EnableControl resource and stores them in CodeCommit, but configures an AWS CodeBuild project that an EventBridge rule invokes on CodeCommit changes, and declares the resource for each OU. Using CodeBuild rather than CodePipeline is the defect: CodeBuild performs a build and cannot provide the staged source, approval, and deploy phases that the requirement's review, approval, and rollback behavior depends on, so a commit would not be gated before its changes took effect. B creates the same CodeCommit-stored templates but configures a CodePipeline pipeline that the security team invokes manually, supplying parameters at each start. Requiring a person to start every deployment means a guardrail could not be applied through an approved commit alone and adds a manual step for every change, which weakens the approval property and increases operational effort. D configures a CodePipeline pipeline invoked by an EventBridge rule on PutObject events to an S3 bucket, and stores the templates in that bucket. As c87b433 pointed out, storing the source templates in S3 rather than a version-controlled repository removes the version control, review, and rollback capability the requirement explicitly demands. C is correct.

Community Comment Notes

Community voted C (83), with D a minority (17). Srikantha explained that version control is managed through CodeCommit so guardrail changes can be reviewed and rolled back if necessary, and that approval and governance are built into the process. uncledana described C as the most efficient and scalable option for automating guardrails while meeting the requirements for version control, approval, and rollback. c87b433 was the sole dissenter, noting that option D uses PutObject events to an S3 bucket to invoke CodePipeline whereas the solution should be invoked by the security team's commits, which is precisely the versioning objection. No alternative received majority support.