Exams / DOP-C02 / Study guide / CodePipeline structure, stages and triggers

CodePipeline structure, stages and triggers: DOP-C02 study notes and practice questions

What to know about CodePipeline structure, stages and triggers for the DOP-C02 exam, from the SDLC Automation domain (22% of the exam guide), then 1 free question to test it. Part of the DOP-C02 study guide.

Last verified October 2026 against current AWS documentation ·How we write our questions

What to know for the exam

Pipeline questions ask how to structure a release process, start it on the right events and stop bad changes from moving forward.

Structure

A pipeline has stages; each stage has actions (source, build, test, deploy, approval, invoke) that run in sequence or in parallel by run order.
Artifacts pass between actions through an S3 artifact store, encrypted with KMS. Cross-Region actions need an artifact store in each Region.
Manual approval actions pause for a person, with SNS notification and a review URL.
Invoke actions call Lambda or Step Functions for custom steps.

V2 pipeline features

Feature	Use
Triggers with filters	Start on pushes or pull requests that match branches, file paths or tags, so a monorepo runs only the affected pipeline
Execution modes	Superseded (default; a newer run replaces a waiting one), Queued (one at a time, in order) or Parallel
Pipeline-level variables	Pass values at start time
Stage conditions	Entry, on-success and on-failure rules, such as checking a CloudWatch alarm or a deployment window before entering a stage
Stage rollback	Roll a stage back to the last successful run, automatically on failure if set

Events and notifications

Pipeline, stage and action state changes are EventBridge events, so rules can notify chat or open tickets.
Notification rules send to SNS or Amazon Q Developer in chat applications.

Designing good pipelines

Build once, deploy the same artifact to every environment.
Run fast tests first; put slower integration tests later.
Gate production with alarms, approvals or both.
Keep pipeline definitions in code (CloudFormation or CDK).

Common traps

A Lambda webhook to filter pushes by path. V2 triggers do it.
Separate pipelines per folder started by custom code.
Superseded mode when every commit must deploy in order. Use Queued.
A missing artifact store in the target Region for a cross-Region deploy action.

Try the 1 practice question

Practice CodePipeline structure, stages and triggers Take the free practice exam

Question 1

Medium ·Link to this question

A logistics company deploys its route-planning service to Amazon ECS from an AWS CodePipeline pipeline. The source is a GitHub monorepo connected through AWS CodeConnections, and the service lives under a services/routing folder beside web frontends and documentation.

Today the pipeline starts on every push to every branch, so feature-branch commits reach the production approval stage and documentation-only commits trigger full deployments. Release managers want a run to start only for pushes to the main branch that change files under services/routing.

The team also wants no custom code to host, patch or debug, and the existing pipeline to remain the single place where production deployments are approved.

Which change meets these requirements with the LEAST operational overhead?

Choose one answer.

A. Add an Amazon API Gateway endpoint and a Lambda function that receives every GitHub webhook, reads the changed file paths, and calls StartPipelineExecution only for matching pushes to main.
B. Convert the pipeline to a V2 pipeline, and set a push trigger on the CodeConnections source action with branch filters for main and file path filters for services/routing/**.
C. Keep the V1 pipeline and add a first CodeBuild stage that diffs the commit and fails when no routing files changed, so the run stops before any deployment starts.
D. Keep the V1 pipeline unchanged, and have a release engineer review each push to main and start the pipeline by hand from the console when the routing folder has changed.

Show the answer and explanation

Answer: B

A. Wrong: This would work, but the team would write, host and patch a webhook receiver and its filtering logic. The release path gains a moving part for a filter that the pipeline can express natively. Learn more: StartPipelineExecution (opens in a new tab)
B. Right: Correct. V2 pipelines can start a run from a Git push that matches branch and file path filters, with no custom code. The production stage and its approval actions stay in the same pipeline, so the release process does not change. Learn more: Automate starting pipelines using triggers and filtering (opens in a new tab)
C. Wrong: Every push still starts a run, and each unrelated commit leaves a failed execution in the history. The team would also maintain a diff script, which is more upkeep than a native trigger filter. Learn more: Build specification reference for CodeBuild (opens in a new tab)
D. Wrong: Manual starts depend on someone noticing the change, which causes delays and missed releases. The requirement is for matching pushes to start runs automatically, and this design removes that automation.

Explanation

A V2 pipeline can filter Git pushes by branch and by changed file path, and a CodeConnections source action delivers those events without extra infrastructure. A webhook function, a diff stage or a manual start each adds code or steps the team must run, and the diff stage still records a run for every unrelated commit.

Study

Want more on CodePipeline structure, stages and triggers? The 5 full-length practice sets have 8 more CodePipeline structure, stages and triggers questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets

Study CodePipeline structure, stages and triggers

CodePipeline concepts