5 exercises — practice "maintenance window," "off-peak hours," blue-green deployment, and how to write professional deployment notices.
0 / 5 completed
Key deployment timing vocabulary
"Maintenance window: a pre-agreed period when downtime is expected and acceptable."
"Off-peak means lowest traffic — verify with actual data; it varies by service."
"Deployment notice: include exact UTC time, what's affected, data safety, and when to escalate."
"Never push on Fridays — issues surface over weekend with skeleton on-call."
"Blue-green: run old + new simultaneously; switch traffic; instant rollback if needed."
1 / 5
The team wants to release a database migration. A senior engineer says "we should schedule this for the maintenance window." What does this mean?
Option B correctly explains "maintenance window." Key aspects: (1) pre-agreed — the window is defined in SLAs and communicated to users in advance; it's not improvised, (2) low-traffic period — typically nights (e.g., 02:00–04:00 UTC), weekends, or public holidays, (3) expectation management — stakeholders and users know degraded service is possible during this window; SLA calculations often exclude it, (4) risk reduction — risky operations (schema changes, config updates, dependency upgrades) are planned for maintenance windows to contain blast radius. Common phrasing: "scheduled for Thursday's maintenance window", "we'll do the cut-over during the weekend window", "the window runs 00:00–04:00 UTC Saturday."
2 / 5
A colleague says "we'll deploy to production off-peak." What period does this typically mean, and why does it matter?
Option A is correct. "Off-peak" means the period of lowest user traffic — but this varies enormously by service: (1) consumer apps: off-peak might be 03:00–05:00 local time in the primary market, (2) B2B / business tools: off-peak might be weekends when no employees are working, (3) global services: there may be no true off-peak if traffic comes from all time zones simultaneously, (4) seasonal: for retail services, off-peak in summer might be peak in November. The key professional skill is checking the actual traffic data before assuming any time is "off-peak." Tools: Cloudwatch, Datadog, Google Analytics — look at requests/hour over 30 days to identify the actual low-traffic window. Never deploy to production "off-peak" without verifying what that means for your specific service.
3 / 5
You need to announce a deployment to stakeholders. Which message is most professional?
Option C is the professional deployment notice. It includes all required elements: (1) exact time window with timezone — "2026-06-12 02:00–04:00 UTC" leaves no ambiguity; UTC anchors international stakeholders, (2) what will be affected — "payment service will be in read-only mode" specifies exactly which functionality is impacted and how, (3) data safety assurance — "no orders will be lost" addresses the first question stakeholders will have, (4) when normal service resumes — "04:00 UTC" sets expectations for recovery, (5) escalation path — "#ops-channel" tells people where to report post-window issues. Option A is too vague (which system? how long?). Option B is alarming without structure. Option D is unprofessional ("fingers crossed" suggests low confidence).
4 / 5
An engineer says "we'll do a blue-green deployment scheduled for Thursday." Which statement about this deployment type is accurate?
Option B correctly describes blue-green deployment. Key concepts: (1) two identical environments — blue (current production) and green (new version) run simultaneously; this requires double the infrastructure temporarily, (2) traffic switch — when green passes validation (smoke tests, health checks), a load balancer or DNS switch routes all traffic from blue to green, (3) instant rollback — if green has issues, switch traffic back to blue; recovery is measured in seconds, not minutes, (4) zero-downtime — users may not notice the switch at all. Difference from canary: blue-green switches 100% of traffic at once; canary gradually shifts traffic (5% → 25% → 100%). Option A is wrong — the point of blue-green is zero downtime. Option C is wrong. Option D is wrong.
5 / 5
The CTO asks "are we doing the deployment on Thursday or Friday?" The senior engineer responds: "Thursday is better — we have full team coverage on Friday afternoon if anything goes wrong, and we'd have two business days to fix issues before the weekend." What scheduling principle does this illustrate?
Option C identifies the key principle: deployment timing should align production exposure with engineering availability. The engineer's reasoning: (1) Thursday deploy → issues surface Thursday/Friday while full team is available to respond, (2) Friday deploy → issues might only appear Friday afternoon or evening; if critical, the team faces a weekend incident response with skeleton crew, (3) the industry phrase: "never push on Fridays" reflects exactly this — a Friday deploy means a Friday evening production issue with no one available. This is why many engineering teams have explicit "freeze windows" (e.g., no deploys Friday 14:00 onwards). The right window considers: traffic patterns, team availability, holiday proximity, and time to observe before coverage drops. Option A is too rigid. Option B is wrong — user volume isn't the only factor. Option D excludes all business-hours deploys which are often perfectly safe with proper CI/CD.