DOP-C02 SDLC Automation Practice Question
A DevOps engineer is setting up an AWS CodePipeline for a serverless application. The source code is in AWS CodeCommit, and the build and deploy stages use AWS CodeBuild and AWS CloudFormation respectively. The engineer wants to ensure that the pipeline automatically creates a new stack for each feature branch and deletes the stack when the branch is deleted. Which combination of actions should the engineer take to achieve this with minimal operational overhead?
⚠ Common exam trap
The trap here is assuming that a single stack with a branch parameter or manual pipelines can handle multiple branches efficiently, when in fact isolation and automated cleanup require per-branch stacks and event-driven deletion.
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
✓
Use AWS CodePipeline with a source action that triggers on all branches, and configure the build stage to pass the branch name to CloudFormation, creating a stack per branch with a naming convention, and use a cleanup Lambda triggered by CodeCommit branch deletion events.
To automatically create and delete CloudFormation stacks per feature branch, the engineer should use CodePipeline's branch-based triggering and pass the branch name to CloudFormation to create uniquely named stacks. A Lambda function triggered by CodeCommit branch deletion events can then delete the corresponding stack. This leverages native AWS services for automation, minimizing operational overhead. The other options either use inappropriate services, lack automation, or do not provide isolation.
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 to trigger on all branches and use a single CloudFormation stack with a parameter that includes the branch name.
Why it's wrong here
Using a single stack with a branch name parameter would cause conflicts because multiple branches would attempt to update the same stack, leading to race conditions and potential failures. CloudFormation stacks are not designed to be shared across branches in this manner. This approach lacks isolation and does not automatically delete stacks when branches are deleted. It requires manual intervention to manage stack lifecycle, increasing operational overhead.
- ✓
Use AWS CodePipeline with a source action that triggers on all branches, and configure the build stage to pass the branch name to CloudFormation, creating a stack per branch with a naming convention, and use a cleanup Lambda triggered by CodeCommit branch deletion events.
Why this is correct
This approach leverages CodePipeline's ability to trigger on all branches and dynamically create CloudFormation stacks per branch using the branch name as part of the stack name. A Lambda function triggered by CodeCommit branch deletion events can delete the corresponding stack. This automates stack lifecycle management with minimal overhead, as the pipeline and Lambda handle creation and deletion. It provides isolation and scalability across branches.
- ✗
Create a separate pipeline for each branch using AWS CloudFormation templates and AWS Lambda to manage stack creation and deletion.
Why it's wrong here
Creating a separate pipeline for each branch is operationally intensive and does not scale well. While it provides isolation, it requires manual setup for each branch and does not automatically handle branch deletion. Using Lambda to manage stacks adds complexity and is not integrated with CodePipeline's branch-based triggers. This approach increases overhead and is not minimal. The engineer should leverage native CodePipeline features for branch-based deployments.
- ✗
Configure CodePipeline to use a single stage that deploys to AWS Elastic Beanstalk environments named after each branch, and rely on Elastic Beanstalk's environment lifecycle policies to delete environments when branches are deleted.
Why it's wrong here
The application is serverless and uses CloudFormation, not Elastic Beanstalk. Elastic Beanstalk is for deploying applications to managed environments, not for serverless stacks. Additionally, Elastic Beanstalk does not automatically delete environments when branches are deleted; that would require custom automation. This option misaligns with the technology stack and does not achieve the goal. It introduces unnecessary services and complexity.
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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
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.