DOP-C02 Configuration Management and IaC Practice Question
A company uses AWS CodePipeline with a multi-branch strategy. The pipeline deploys a Lambda function using CloudFormation. The DevOps engineer notices that when a new branch is created, the pipeline executes but the CloudFormation stack fails because the stack name already exists. What is the MOST efficient way to resolve this issue?
⚠ Common exam trap
Many candidates think hardcoding stack names per branch (Option B) is acceptable, but they overlook the operational overhead and lack of automation; AWS expects you to use dynamic parameters to handle multi-branch pipelines 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
✓
Modify the pipeline to use a dynamic stack name parameter, such as the branch name.
Using a dynamic stack name parameter, such as the branch name, ensures each branch creates a unique CloudFormation stack. This avoids naming conflicts while allowing independent infrastructure per branch. In CodePipeline, you can pass the branch name as a variable (e.g., #{SourceVariables.BranchName}) to the CloudFormation deploy action, making the stack name unique without manual intervention.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Modify the pipeline to use a dynamic stack name parameter, such as the branch name.
Why this is correct
Using a dynamic stack name parameter, such as inserting the branch name into the stack name (e.g., `MyApp-${Branch}`), lets each branch deploy to a unique CloudFormation stack. This isolation prevents resource name collisions when multiple branches are deployed concurrently, supports per-branch rollback and lifecycle management, and eliminates the need to manually reconfigure the pipeline when a new branch is created.
- ✗
Hardcode a different stack name for each branch in the pipeline.
Why it's wrong here
Hardcoding a different stack name for each branch in the pipeline definition requires manual code changes whenever a branch is added or renamed, making the process unscalable and error-prone. It also defeats the purpose of a multi-branch strategy because the pipeline cannot dynamically adapt to branch creation without human intervention, increasing the risk of misconfiguration and inconsistent deployments.
- ✗
Delete the existing stack before each deployment.
Why it's wrong here
Deleting the existing CloudFormation stack before every deployment creates a window of downtime and, if the stack deletion fails (e.g., due to non-empty S3 buckets or retained resources) or the subsequent creation fails, you are left with no running infrastructure. CloudFormation updates are designed to apply changes in-place, preserving the stack and its outputs; a delete-before-create approach also loses stack history and makes rollback impossible.
- ✗
Use the CloudFormation 'Override' parameter to reuse the same stack.
Why it's wrong here
CloudFormation does not support an 'Override' parameter for stack names—the stack name is a fixed identifier set when the stack is created, and the CodePipeline CloudFormation 'Override' action only overrides template parameter values, not the stack name itself. Even if you could override parameters, reusing the same stack for multiple branches would cause them to overwrite each other's resources, leading to unintended shared state and deployment conflicts.
Visual reference
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,298-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
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.