Study DOP-C02 CI/CD pipeline design for stages, promotion, cross-account delivery, secrets, and release control.
DOP-C02 pipeline questions are rarely about memorizing one AWS service. They are about whether the release path is trustworthy. The best answer usually creates one repeatable delivery flow from source through promotion, with clear stage boundaries, scoped credentials, and evidence that the released version is the one that was tested.
The current AWS domain guidance points to:
That means the question is often broader than “which Code* service?” The real topic is how the pipeline should be structured and secured.
Treat the pipeline as five distinct responsibilities:
Weak answers blur those responsibilities together.
| Requirement | Strongest first fit | Why |
|---|---|---|
| Small isolated environment | Single-account pipeline with clear role separation | Simpler control plane when account sprawl adds no benefit |
| Strong separation between dev, staging, and production | Multi-account promotion pipeline | Cleaner blast-radius boundaries and audit separation |
| Frequent releases with approval checkpoints | Automated pipeline with narrow manual approval stage where needed | Keeps flow automated without losing governance |
| Shared deployment logic across many services | Reusable pipeline templates or shared modules | Consistency beats hand-built per-team variance |
The strongest answer often builds once and promotes the same artifact forward. Rebuilding a new binary or image for production after tests already passed breaks traceability and increases drift risk.
If the scenario cares about audit, compliance, or consistent rollback, prefer a design where the same tested artifact moves between stages.
DOP-C02 likes scenarios where the delivery system lives in one account but deploys into others. The exam is usually testing:
If the prompt stresses isolation or separate ownership, a one-account-everything answer is often too weak.
The pipeline needs access to deployment material, but not by hardcoding it. Strong answers usually favor:
If a choice stores deployment keys or passwords directly in source or pipeline definitions, it is usually not the strongest security posture.
When the question says repeatable, auditable, and low-risk, think build once, promote forward, isolate environments sensibly, scope roles and secrets tightly, and keep approvals only where they add real control.
Continue with 1.2 Automated Testing in Pipelines once the release path itself is clear.