DOP-C02 SDLC 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.

• ✓

  Configure a single pipeline with a source action that triggers on all branches, then use a 'branch' condition on the deployment stage to only proceed if the branch is 'main'.

  Why this is correct

  This option uses a single CodePipeline execution triggered by all branch updates, and then applies a stage condition such as #{SourceVariables.BranchName} == 'main' on the deployment action. Test and build stages still run for every branch, but non-main branches are skipped at the deployment stage, so no production release occurs for feature branches. This minimizes pipeline infrastructure, reduces maintenance, and keeps the automation fully managed inside the pipeline.

• ✗

  Use a single pipeline with a source action that triggers on all branches, and deploy to a test environment for all branches, then promote to production manually.

  Why it's wrong here

  Automatically deploying every branch to a test environment wastes compute and storage and can cause concurrent executions to contend for the same staged resources, especially with many short-lived feature branches. Requiring a manual promotion to production injects human latency and error risk into the CD process, bypasses CodePipeline's built-in approval gates, and means developers must remember to re-trigger or resume the execution, undermining the CI/CD feedback loop.

• ✗

  Create separate pipelines for each branch, each with its own test and deploy stages.

  Why it's wrong here

  Creating a dedicated pipeline for each branch multiplies your pipeline definitions, CloudFormation stacks, IAM roles, and associated notification rules, and every new branch requires manual pipeline creation before the developer receives any CI/CD support. Such a design becomes quickly unmanageable for a team using ephemeral or feature branches and makes it easy for stage configurations to drift between pipelines, so a fix applied to one branch's pipeline may be missing from another.

• ✗

  Use a single pipeline with a source action that only triggers on the 'main' branch, and run tests in a separate system.

  Why it's wrong here

  With the pipeline only listening for changes on main, feature-branch commits never trigger a pipeline execution, so there is no automated run of unit tests, static analysis, or build validation until code is merged; integration problems are detected too late. Running tests in an external system breaks the correlation between a specific commit and its test results, because the external system is unaware of CodePipeline's source variables and artifact handling, giving developers a slower and less transparent feedback path.

Go deeper

Related to this question