SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company uses AWS CloudFormation to manage infrastructure. The operations team wants to implement a change management process where all stack updates must be reviewed and approved before execution. The team currently uses AWS CodePipeline for CI/CD. Which solution meets these requirements with the LEAST operational overhead?

⚠ Common exam trap

SAP-C02 often tests the 'least operational overhead' constraint — candidates may over-engineer with Lambda/SNS or Service Catalog when the native CodePipeline approval action is the simplest fit.

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

✓

Create a CodePipeline pipeline with an approval stage before the CloudFormation deployment action.

AWS CodePipeline natively supports approval actions, allowing a manual approval stage to be inserted before the CloudFormation deployment action. This integrates directly with the existing CI/CD pipeline, requires minimal custom code, and enforces review/approval before stack updates. It is the lowest-operational-overhead solution that meets the change management requirement.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use CloudFormation Change Sets and require a senior engineer to execute them.
Why it's wrong here
Change Sets only preview differences; a senior engineer must manually execute each update, adding human toil and no pipeline integration. Change Sets suit ad-hoc review of a single stack change, not an automated approval gate inside an existing CodePipeline workflow.
✗
Write an AWS Lambda function that triggers on stack update events and requires approval via Amazon SNS.
Why it's wrong here
A Lambda function reacting to stack update events fires after the update has begun, so it cannot block execution; approval must precede the change. Event-driven notification suits alerting on drift or failures, not pre-execution authorisation.
✗
Use AWS Service Catalog to govern CloudFormation templates and require approval for provisioning.
Why it's wrong here
Service Catalog governs provisioning of new products, not updates to existing CloudFormation stacks, so it cannot gate stack changes. It is tempting because approval workflows are native, and it would be correct for controlling which portfolios end users may launch.
✗
Store CloudFormation templates in AWS CodeCommit and use AWS CLI to execute updates after peer review.
Why it's wrong here
CodeCommit stores templates and the AWS CLI runs updates, but nothing enforces peer review before execution, and manual CLI invocation adds operational overhead. This pattern suits teams without CI/CD tooling who accept manual release discipline.
✓
Create a CodePipeline pipeline with an approval stage before the CloudFormation deployment action.
Why this is correct
A manual approval stage in CodePipeline halts the pipeline until a nominated reviewer approves, then triggers the CloudFormation deploy action. This satisfies the mandated review-and-approval gate before execution while reusing the existing CI/CD tooling, so no custom change-management system is built, keeping operational overhead minimal.

Go deeper

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question