DVA-C02 Deployment 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.

• ✓

  No action is needed; CodePipeline automatically stops on stage failure

  Why this is correct

  AWS CodePipeline is inherently designed to halt execution when any action within a stage fails, causing the entire stage to be marked as failed. This default behavior prevents the pipeline from automatically transitioning to subsequent stages, ensuring that faulty code or configurations do not progress further into environments like staging or production. Therefore, no explicit configuration is needed to stop the pipeline on stage failure; it is a built-in safety mechanism.

• ✗

  Add a manual approval step before Prod Deploy

  Why it's wrong here

  Adding a manual approval step is intended to introduce a deliberate human gate in the pipeline, requiring explicit consent before proceeding to the next stage, typically for successful deployments. Its purpose is not to handle or prevent progression due to a stage failure. Since CodePipeline already stops automatically when a stage fails, introducing a manual approval step specifically for this scenario is redundant and does not address the core issue of a failed deployment.

• ✗

  Disable the transition from Staging Test to Prod Deploy

  Why it's wrong here

  Disabling a transition between stages prevents the pipeline from automatically moving from the preceding stage to the subsequent one, regardless of the preceding stage's outcome. This action effectively requires manual intervention to release the transition for every deployment. However, CodePipeline's default behavior already ensures that progression is stopped if a stage fails, making this configuration unnecessary for the goal of halting on failure. Disabling a transition is typically used when permanent manual gating is desired.

• ✗

  Configure the pipeline execution mode to 'Superseded'

  Why it's wrong here

  The pipeline execution mode, such as 'Superseded' or 'Queued', governs how CodePipeline manages multiple concurrent executions triggered by new source changes. 'Superseded' mode dictates that a new execution will cancel and replace any currently running execution. This setting, however, has no bearing on how a single pipeline execution reacts to a stage failure. A stage failure will still cause that specific execution to halt, irrespective of whether new executions are superseding older ones.