Courseiva
SDLC AutomationmediumMultiple ChoiceObjective-mapped

DOP-C02 SDLC Automation Practice Question

A DevOps team uses AWS CodePipeline with a multi-branch strategy. The pipeline should deploy to production only from the 'main' branch, but run unit tests for all branches. How should the team configure the pipeline?

⚠ Common exam trap

Candidates often think they need separate pipelines or multiple source stages to handle branch-specific logic, but CodePipeline's branch filtering and conditional actions (like Lambda checks or manual approvals) allow a single pipeline to handle all branches efficiently.

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

Configure the pipeline source stage to trigger on all branches, use branch-specific logic in the test stage, and add a manual approval step for production deployment only when the branch is 'main'.

AWS CodePipeline supports branch filtering in the source stage to trigger on all branches, and you can use a condition in the deploy stage (e.g., via a Lambda function or a manual approval step) to restrict production deployment to the 'main' branch only. This approach avoids duplicating pipelines while ensuring unit tests run for every branch, meeting the multi-branch strategy requirement efficiently.

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 the pipeline source stage to trigger on all branches, use branch-specific logic in the test stage, and add a manual approval step for production deployment only when the branch is 'main'.

    Why this is correct

    Configuring the source stage to trigger on all branches is the recommended approach because CodePipeline natively supports branch filters on source actions, allowing a single pipeline to react to every branch push. Branch-specific logic can then be implemented in the test stage using environment variables or run-time conditions to vary test suites, while a manual approval action can be conditionally added to the deploy stage only when the branch is 'main'. This leverages built-in pipeline features, avoids duplication, and keeps the deployment workflow centralized and auditable, which is the most scalable and maintainable design.

  • Use an AWS Lambda function to check the branch name and invoke different CodePipeline executions for testing and deployment.

    Why it's wrong here

    Using a Lambda function to inspect the branch name and manually invoke different CodePipeline executions introduces unnecessary external orchestration, adding latency, potential permission complexity, and a custom code path that duplicates functionality CodePipeline already provides. The source action's built-in branch filter and pipeline conditional stages can handle branch-based triggers and deployments without requiring a separate compute service. Additionally, managing invocation errors, idempotency, and pipeline execution races makes this solution less reliable and more complex than the native branch filtering approach.

  • Create one pipeline with two source stages: one for 'main' and one for all other branches, each with its own test and deploy actions.

    Why it's wrong here

    A single pipeline cannot contain two source stages for different branches because CodePipeline executes stages in a strict linear sequence, with each execution tied to one source revision; there is no way to branch the stage flow into parallel branch-specific paths. Even if you attempted to place multiple source actions in one stage, the pipeline would still treat them as multiple sources for a single execution rather than as separate branch triggers, and you could not have distinct test and deploy actions run per branch in the same linear flow. This design fundamentally misunderstands CodePipeline's execution model and would either fail validation or produce incorrect cross-branch behavior.

  • Create a separate pipeline for each branch, each with identical test and deploy stages.

    Why it's wrong here

    Creating a separate pipeline for every branch leads to significant duplication of stage definitions, resulting in high operational overhead, configuration drift, and inconsistent deployments as branches and pipeline settings inevitably diverge. Each new branch requires manually cloning and updating the entire pipeline, and changes to the test or deploy logic must be propagated across all pipelines individually, increasing the chance of error. CodePipeline's branch filter and conditional execution features are explicitly designed to avoid this anti-pattern, making per-branch pipelines a costly and maintenance-heavy alternative.

Quick reference

Cloud Service Model Comparison

ModelYou ManageProvider ManagesExamples
IaaSOS, runtime, apps, dataHardware, hypervisor, networkingEC2, Azure VMs, GCP Compute Engine
PaaSApps and dataOS, runtime, middleware, hardwareElastic Beanstalk, Azure App Service
SaaSData and settings onlyEverything elseMicrosoft 365, Salesforce, Workday
FaaS / ServerlessFunction code onlyInfra, scaling, runtimeLambda, Azure Functions, Cloud Run
CaaSContainers and appsKubernetes, OS, hardwareEKS, AKS, GKE

About these practice questions

One of 251 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

1 more way this is tested on DOP-C02

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. An organization uses AWS CodePipeline with a multi-branch strategy. They want to run unit tests on every push to any branch, but only deploy to production on pushes to the 'main' branch. What is the most efficient way to achieve this?

medium
  • A.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'.
  • B.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.
  • C.Create separate pipelines for each branch, each with its own test and deploy stages.
  • D.Use a single pipeline with a source action that only triggers on the 'main' branch, and run tests in a separate system.

Why A: AWS CodePipeline supports a single pipeline with a source action configured to trigger on all branches (e.g., using a webhook event filter for 'refs/heads/*'). You can then add a 'branch' condition on the deployment stage using a Lambda function or a manual approval action that checks the branch name, ensuring only pushes to 'main' proceed to production. This approach avoids duplicating pipelines while still running unit tests on every push.

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.