← DOP-C02·Amazon Web Services

DOP-C02 SDLC Automation Practice Question

A company uses AWS CodePipeline with multiple stages: Source (Amazon S3), Build (AWS CodeBuild), and Deploy (AWS CodeDeploy). The build stage runs a series of tests, and if they pass, the pipeline proceeds to deploy. Recently, a developer committed a change that passed all tests but caused a production outage. The team wants to add an approval step before the deploy stage, but they also want to ensure that only changes from specific branches can be deployed. What is the MOST secure and maintainable way to enforce this?

⚠ Common exam trap

The trap here is that candidates often overestimate the flexibility of CodePipeline's built-in filtering or underestimate the security and maintainability benefits of using separate pipelines per branch, leading them to choose a custom Lambda solution (Option A) that introduces unnecessary complexity and risk.

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

✓

Create a separate pipeline for each allowed branch, with the approval step only in the production pipeline.

It enforces branch-based deployment at the pipeline level, ensuring that only changes from specific branches trigger the production pipeline with the approval step. This approach is secure and maintainable as it leverages AWS CodePipeline's native ability to trigger on branch events, avoiding custom logic or manual verification. By isolating production deployments to a dedicated pipeline, the team reduces the risk of unauthorized or untested code reaching production.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use a Lambda function in the pipeline to check the branch name and fail if not allowed.
Why it's wrong here
Implementing a custom Lambda function as a branch guard is brittle governance because the function and its invocation only exist inside the pipeline definition. Any developer with permissions to edit the pipeline can simply remove the Lambda action, alter its environment variables, or inject a different handler, effectively disabling the check. Moreover, the approach relies on parsing branch names from source action metadata, which is not a native enforcement point in CodePipeline's model—it is a scripted convention rather than a structural control.
✗
Add a manual approval step in the pipeline and rely on the approver to verify the branch.
Why it's wrong here
A manual approval step does not enforce separation of duties because CodePipeline does not automatically verify that the approver is someone other than the developer who committed the change. The approval action is just a gate that any IAM principal with the necessary pipeline and approver permissions can complete—including the same developer who pushed the branch. To make approval a real control, you must combine it with a distinct IAM role or group for approvers, which the pipeline structure itself does not enforce.
✓
Create a separate pipeline for each allowed branch, with the approval step only in the production pipeline.
Why this is correct
Creating a separate pipeline per allowed branch makes the pipeline definition itself the security boundary. Only branches that have an explicitly defined pipeline can ever proceed through the release stages, so committing to an unauthorized branch simply does not trigger a deployment even if the code is structurally valid. The production pipeline includes a manual approval step, and because that pipeline sources solely from an approved branch (e.g., main), the approval verifies the intended deployable artifact rather than attempting to check a branch name at runtime. This isolation prevents accidental or malicious deployment from unapproved branches without relying on inline validation or easily modified Lambda actions.
✗
Tag the source artifacts with the branch name and use a condition in CodePipeline to allow only specific tags.
Why it's wrong here
CodePipeline has no native support for conditional execution based on artifact tags—tags are resource metadata for cost allocation, permissions, or identification, not inputs to pipeline stage transitions. There is no IAM policy condition key that evaluates an artifact's tag to allow or deny a specific pipeline action. Even if you tagged artifacts with the branch name, the tag would be ignored during pipeline execution unless you built a custom Lambda to read it, which reintroduces the same modification and bypass risks found in Option 1. Thus, this is not a supported or reliable control mechanism in CodePipeline.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

DOP-C02 SDLC Automation Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question