SOA-C02 Deployment, Provisioning, and Automation Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Add an approval stage in the pipeline using the Amazon SNS topic as a notification method.

  Why it's wrong here

  An Amazon SNS topic is only a notification channel; it cannot pause a pipeline or serve as an approval gate by itself. In CodePipeline, manual approval requires an action with the category "Approval" added to a stage, and while you may associate an SNS topic with that approval action to alert reviewers, simply adding the SNS topic as a stage does not stop the pipeline or enforce a review. Without the actual Approval action, the pipeline will continue executing past the stage, so this approach fails to meet the requirement.

• ✓

  Add a manual approval action in the pipeline using the AWS CodePipeline approval action type.

  Why this is correct

  CodePipeline has a native manual approval action with the category "Approval" that can be inserted into any stage. When configured, this action pauses the pipeline and waits for an authorized user to approve or reject the deployment via the console, CLI, or PutApprovalResult API call. You can optionally attach an SNS topic to send notifications to approvers, but the verification step is enforced by the Approval action itself, making this the correct way to implement a manual gate within the existing pipeline.

• ✗

  Use an AWS CloudFormation change set to require manual approval.

  Why it's wrong here

  An AWS CloudFormation change set lets you review stack changes before execution, but it is not a CodePipeline approval step and does not pause the pipeline automatically. In a CodePipeline deployment, you would still need a separate Approval action before executing a change set; the change set itself merely describes the proposed resources and requires a separate CloudFormation action to execute it. Using change sets alone would require manual intervention outside the pipeline's execution and does not integrate as a built-in approval gate.

• ✗

  Create a separate pipeline for production and trigger it manually.

  Why it's wrong here

  Creating a second pipeline for production and triggering it manually avoids adding an approval step to the existing pipeline, but it duplicates the entire pipeline configuration and requires manual operation outside of CodePipeline's automated flow. This approach adds operational overhead, increases the risk of configuration drift between pipelines, and does not provide an inline manual approval checkpoint within a single pipeline. The requirement asks for a manual approval step in the pipeline, so this is less efficient and not the correct solution.

Go deeper

Related to this question