Deployment alarms and automatic rollback

Exam alignment: DOP-C02 Domain 1 task statements for pipelines, testing, artifacts, or deployment.

Learning objective

Connect technical and business metrics to safe release decisions.

Difficulty / Schwierigkeitsgrad	Advanced
Study time / Lernzeit	120 minutes
Prerequisites / Voraussetzungen	Previous lessons in this volume

Professional scenario

A release passes instance health but payment failures rise sharply.

Core concepts

• Infrastructure health is necessary but not sufficient.
• Business metrics measure customer outcomes.
• Alarms can stop or roll back supported deployments.
• Rollback must account for schema and configuration compatibility.

Architecture flow

1. Identify the release input and immutable identity.
2. Select the managed AWS control plane and least-privilege role.
3. Execute build, test, artifact, or deployment work.
4. Collect service events, logs, reports, and runtime metrics.
5. Stop, retry, or roll back according to explicit rules.

Decision matrix

Requirement	Preferred choice	Reason
Severe fast failure	Short robust alarm window	Quick containment
Noisy signals	Composite alarm	Reduce false rollback
Critical transaction	Custom business metric	Measures customer outcome

Failure modes and troubleshooting

• Average hides tail latency.
• Missing-data behavior is wrong.
• Code rollback cannot reverse schema change.

Security and operations

• Use short-lived service roles and least privilege.
• Encrypt artifacts and protect logs from secret exposure.
• Record changes and approvals for audit.

Hands-on lab

Goal / Ziel: Create one technical and one business rollback alarm.

Tasks

1. Create the smallest safe test architecture.
2. Implement or simulate the main workflow.
3. Introduce one controlled failure.
4. Diagnose it from service evidence.
5. Document cleanup and one improvement.

Validation

• The workflow uses an immutable version.
• A required failure blocks promotion.
• The diagnosis identifies the first failed transition.

Cost control / Kostenkontrolle: Keep resources short lived; read cleanup before starting.

Cleanup

1. Delete pipeline/build/deployment resources.
2. Delete temporary artifacts, images, logs, and roles.

Exam traps

• Monitoring only CPU.
• Using an unrelated metric.

Key takeaways

• Infrastructure health is necessary but not sufficient.
• Rollback must account for schema and configuration compatibility.
• Decisions must be justified by requirements and failure behavior.

Review questions

1. What is the immutable release identity?
2. Which evidence proves failure or success?
3. What is the safest recovery action?

Answers

1. A version, digest, or uniquely versioned artifact.
2. Service events, logs, reports, health checks, and runtime metrics.
3. Restore the known-good version using the configured rollback path.