Free Change Management practice questions

The CAB reviews changes above a set risk level, weighing the business reason, risk, test results, backout plan and schedule, then approves, defers or rejects them. It approves rather than implements, and accountability for an individual change from request to closure belongs to that change's owner.

A standard change is low risk, repeatable and pre-approved, and a written SOP is what makes it safe to pre-approve. A normal change is assessed and approved individually, an emergency change is one that can't wait for the normal cycle, and this change was authorized in advance.

A backout plan is written and reviewed during assessment, before approval, so a request without one should be deferred until it is provided. Drafting it during the window is exactly what the plan exists to avoid, and passing tests don't replace a way back. Rejecting outright is excessive when the missing piece can simply be added.

Change records separate expected changes from suspicious ones, so the first step is to see whether an approved change covered that router in that window. If none did, it becomes a security incident, and containment is then carried out in a way that preserves evidence. Restoring, disabling accounts or declaring an intrusion before checking skips that step.

The SOC needs to know about expected activity so it doesn't chase an approved change as an attack, which makes it a stakeholder to notify before the window. The change was already approved and scheduled, and a backout plan helps only after a change fails, not with a team that never heard about the work.

A freeze allows only emergency changes, and the emergency process is meant for urgent cases such as a flaw attackers are actively exploiting; a routine patch with no known exploitation should wait for the window. Security patches aren't automatically exempt, and a pilot deployment is still a change made during the freeze.

A staged rollout sends the change to a pilot group, such as the IT department or one branch office, and then to progressively larger groups, so a problem staging missed reaches dozens of machines instead of thousands. Deploying everywhere at once, overnight or not, exposes every machine to the same defect, and starting with critical machines puts the worst-case damage first.

Backing out fits when the cause is unknown, the impact is wide, the old state was stable and the tested backout fits the window, and all four are true here. Failing forward needs an understood fault and a small fix; open-ended troubleshooting, waiting on the vendor or extending the window turns a planned change into an unplanned outage.

A useful impact analysis includes the cost of doing nothing, because postponing a patch for an internet-facing flaw can be far riskier than a short outage, and approvers need both sides to compare them. Impact analysis covers business effects such as downtime as well as security, and changes that cause downtime are approved all the time.

A change scheduled into a window has to fit inside it including the time needed to back out, and 2.5 hours plus 2 hours exceeds the four-hour window. The change fitting on its own is the tempting answer, but if it failed late, the system would still be broken at 05:00. Nothing here makes it an emergency or a pre-approved standard change.