Three Changes and a Year-End Freeze
Today is 21 December. The change freeze runs 20 December through 3 January. Three requests are on the table: (1) the routine monthly security patch for 200 Windows servers, already defined as a standard change template and executed on the same schedule every month; (2) an urgent fix to a load balancer causing intermittent 502 errors on 8% of checkout requests; (3) a database index rebuild to speed up a finance report, medium risk, no expected outage, wanted before January reporting. The CAB meets Thursdays and the next meeting is 28 December. The load balancer team estimates waiting two days costs roughly $40,000 in lost orders.
1. Classify each of the three changes as standard, normal, or emergency, and justify each classification.
Read the worked answer
(1) Standard. It is pre-approved, repeatable, low risk, and already modelled as a standard change template with a known procedure and schedule. Standard changes do not go to CAB - they are authorised by the template. But check the template's freeze handling: a freeze policy can still block a standard change's execution window, so the correct move is to confirm with the change manager whether this template is exempt, not to assume 'standard' means 'any time'.
(2) Emergency. Unplanned, high business impact, active revenue loss, cannot wait for the 28 December CAB. It goes through the emergency change process and ECAB, not the normal CAB cycle.
(3) Normal. Medium risk, no outage expected, but no pre-approval and no urgency that justifies bypassing governance. It goes to CAB - which, given the freeze, means the January CAB, not the 28 December one.
The classification decides the approval path, so getting it wrong either stalls a revenue fix or lets an unreviewed change through.
2. The load balancer fix must happen tonight. What approvals, records, and safeguards are required during a freeze?
Read the worked answer
Emergency does not mean unrecorded. Required:
- Emergency change record raised before implementation (or immediately after, if the outage genuinely prevents it) with affected CIs, business justification, risk, and back-out plan.
- ECAB approval - a defined subset of CAB empowered to approve out-of-band. Document who approved and when; 'the manager said go' in a chat channel is not an approval.
- Freeze exception - the freeze is a policy, so the exception must be explicit and logged with the reason ($40,000 estimated loss and 8% checkout failure is a defensible justification).
- Back-out plan tested and ready, plus a named implementer and a verification step measuring 502 rate after the change.
- Post-implementation review within a defined window, feeding the next CAB.
What is not acceptable: waiting until 28 December, or making the change silently and backfilling paperwork later. Both convert a managed risk into an unauthorised change.
3. Finance asks to squeeze the index rebuild in on 23 December since it is low risk. What is your response?
Read the worked answer
Decline the date, not the change. 'Medium risk' and 'no expected outage' do not create a freeze exemption - the freeze exists precisely to protect a period when staffing, escalation paths, and vendor support are thin.
Constructive answer:
- Keep it as a normal change, scheduled for the first CAB after the freeze lifts.
- If finance's reporting deadline genuinely cannot move, test the option of running the rebuild against a reporting replica outside production, which delivers the outcome without touching the frozen estate.
- If they insist on production, escalate to the change manager for an explicit freeze exception decision - and make clear that a medium-risk change with no emergency justification is unlikely to be granted one.
Also check collision detection against the freeze window and any other scheduled maintenance before committing a date, so the rebuild does not silently land on top of another team's work.