---
tags:
- devops
- l1
- flashcard-deck
- change-management
---
<!-- wiki:breadcrumb:start -->
[Portal](../../../../library/portal/index.md) | **Level:** [L1: Foundations](../../../../library/portal/levels.md) | **Topics:** [Change Management](../../../../library/portal/topics.md) | **Domain:** DevOps & Tooling
<!-- wiki:breadcrumb:end -->

id	category	difficulty	tags	question	answer	source_path
change-management/a516a43ea5c9	change-management	easy	change-management, categories, process	What are the three change categories and their approval requirements?	Standard (pre-approved, low-risk, repeatable), Normal (planned, peer-reviewed or CAB-approved, scheduled), and Emergency (unplanned, expedited approval, used only to restore service during an active incident).\n\nRemember: peer review catches errors automation misses. At minimum: what's changing, why, rollback plan, risk assessment, and who approved.	training/library/topics/change-management/primer.md
change-management/9f0b80756986	change-management	easy	change-management, windows, scheduling	What days and times are considered the best change windows?	Tuesday through Thursday, during business hours when the full team is available. Avoid Friday afternoons, before holidays, or during on-call handoff.\n\nFun fact: Google's SRE book documents 'change Fridays' as a leading cause of weekend incidents. 'No deploy Friday' is nearly universal in ops culture.\n\nGotcha: 'business hours' means when engineers who can fix problems are available, not necessarily 9-5 for global services.\n\nGotcha: 'off-hours' maintenance windows still affect global teams. Coordinate across time zones and communicate widely.	training/library/topics/change-management/primer.md
change-management/2c6c36b6309a	change-management	easy	change-management, validation, monitoring	How long should you wait after a change before declaring it successful?	At least 15 minutes (one full monitoring cycle). Some failures are delayed due to cache expiration, connection pool exhaustion, or slow memory leaks.\n\nGotcha: some failures are delayed — connection pool exhaustion takes 30-60 min, memory leaks take hours. Tune soak time to your service's known failure modes.	training/library/topics/change-management/primer.md
change-management/6596e59070f6	change-management	medium	change-management, rollback, criteria	What four questions must a rollback plan answer?	1. How — exact commands or pipeline to execute. 2. Who — who has authority to trigger the rollback. 3. When — the time window after which rollback is no longer safe. 4. Verification — how to confirm the rollback succeeded.\n\nRemember: every change needs a rollback plan. If the rollback plan is 'restore from backup,' that's not a plan — it's a prayer. Test your rollback.	training/library/topics/change-management/primer.md
change-management/662e50f4c265	change-management	medium	change-management, risk, assessment	Name at least five factors used in change risk assessment.	Blast radius (single service vs cross-service), reversibility (one-command rollback vs hours-long migration), dependency count, testing confidence, time sensitivity, data impact (schema changes), and history of previous incidents from similar changes.	training/library/topics/change-management/primer.md
change-management/0ec3a96af160	change-management	medium	change-management, freeze, discipline	What are the five rules for managing a change freeze?	1. Define the exact window and communicate 2+ weeks ahead. \n2. Define exceptions for emergencies that override the freeze. \n3. Enforce at the pipeline level, not just via Slack messages. \n4. Complete all planned changes 48+ hours before the freeze. \n5. Do not batch up changes to deploy the moment the freeze ends.	training/library/topics/change-management/primer.md
change-management/44d3cc138d1e	change-management	medium	change-management, communication, process	How should communication scale with change risk?	Standard changes get automated notifications in the deploy channel. Normal changes get pre-change announcements and post-change validation messages. Emergency changes get real-time updates in the incident channel. High-risk changes get advance email to stakeholders and a dedicated Slack thread.\n\nRemember: measure before you optimize. Profile the actual bottleneck — premature optimization wastes effort on the wrong component. Amdahl's Law applies everywhere.	training/library/topics/change-management/primer.md
change-management/68e54e4e120e	change-management	hard	change-management, standard, automation	What makes a change qualify as a standard change and why is this classification a goal?	A standard change is well-understood (done many times), low-risk (small blast radius, easily reversible), repeatable (same procedure each time), and pre-approved (no per-instance review needed). The goal is to classify as many changes as standard as possible because they can be fully automated via CI/CD without bureaucratic overhead.	training/library/topics/change-management/primer.md
change-management/e1819b39c72f	change-management	hard	change-management, cab, governance	What is a CAB (Change Advisory Board) and how should it be made efficient?	A CAB reviews normal and high-risk changes, meets on a fixed schedule, and includes ops leads, dev leads, security, and service owners. Make it efficient by requiring complete change tickets before the meeting, pre-screening to skip standard changes, time-boxing reviews (5 min normal, 15 min high-risk), and tracking approval-to-execution time.	training/library/topics/change-management/primer.md
change-management/232d3fd713f8	change-management	hard	change-management, rollback, monitoring	What specific metrics should define rollback triggers, and when should they be defined?	Define rollback triggers before the change starts. Triggers should include: error rate exceeding a threshold (e.g., 1% vs 0.05% baseline), p99 latency exceeding limits (e.g., 500ms vs 120ms baseline), any 5xx responses from the changed service, dependent service health check failures, data integrity check failures, and the change author's intuition that something is wrong.\n\nRemember: every change needs a rollback plan. If the rollback plan is 'restore from backup,' that's not a plan — it's a prayer. Test your rollback.	training/library/topics/change-management/primer.md

<!-- wiki:related:start -->
---

## Wiki Navigation

### Related Content

- [Change Management](../../../../library/topics/change-management/index.md) (Topic Pack, L1) — Change Management

<!-- wiki:related:end -->
