1. What is the PRIMARY goal of a formal change management process?
Correct: B — Change management controls how changes occur to maintain stability and minimize risk, not to prevent all change.
2. The HR department requests a software upgrade. Who is the OWNER of the change management process?
Correct: C — The owner is the department that needs the change. They manage the process and perform acceptance testing. IT implements; HR owns.
3. A retail company wants to upgrade its e-commerce platform in November. The CCB denies the request until January. What concept BEST explains this decision?
Correct: C — Change freezes prevent all non-emergency changes during high-risk business periods. Retail change freezes typically cover Thanksgiving through New Year.
4. What is the PRIMARY purpose of testing a change in a sandbox environment BEFORE deployment to production?
Correct: B — The sandbox is a safe space to verify the change works AND to test the rollback procedure — both without any risk to live systems.
5. Which of the following MUST be included in every change request, regardless of how minor the change appears?
Correct: A — Every change needs a backout plan. The "minor change" assumption is the most dangerous — you must always be able to revert.
6. Matching — Match each change management concept to its description.
CONCEPT
Sandbox
Backout Plan
CCB
Maintenance Window
DESCRIPTION
Scheduled time period for implementing changes with minimal user impact
Isolated environment for testing changes safely before production
Committee that reviews and approves or denies change requests
Documented procedure to revert systems if a change fails
7. Analysis: An organization's firewall has a known vulnerability. The security team wants to apply the vendor patch immediately, but the CCB says the maintenance window isn't for two weeks. Analyze the tension here and what factors the CCB should weigh.
Model Answer: The CCB must weigh two competing risks: (1) the risk of deploying the patch now — potentially destabilizing production during a busy period — vs. (2) the risk of NOT patching — leaving an active vulnerability exposed for two weeks.
For a critical security vulnerability (especially if actively being exploited), most change management frameworks include an emergency change procedure that allows expedited approval. The CCB would likely approve an emergency maintenance window — possibly same-day — with the security team providing evidence of the severity. A "two weeks later" response is appropriate for low-severity patches but potentially negligent for critical vulnerabilities.
For a critical security vulnerability (especially if actively being exploited), most change management frameworks include an emergency change procedure that allows expedited approval. The CCB would likely approve an emergency maintenance window — possibly same-day — with the security team providing evidence of the severity. A "two weeks later" response is appropriate for low-severity patches but potentially negligent for critical vulnerabilities.
8. Evaluation: A developer argues that small, routine patches should be exempt from the change management process to save time. Evaluate this position.
Model Answer: This position is dangerous and incorrect. The premise assumes size predicts impact — it does not. Many of the most damaging outages in IT history were caused by "minor" patches or configuration changes that had unexpected dependencies.
Change management exists because human perception of "minor" is unreliable. What appears simple to the developer often has ripple effects to accounting, logistics, or other integrated systems that the developer has no visibility into.
A practical middle ground: many organizations have a "standard change" category for pre-approved, well-understood, low-risk changes (e.g., applying a monthly OS patch to a specific class of servers). These still go through a lightweight process — documentation and notification — but don't require full CCB review. This balances speed with accountability without abandoning process entirely.
Change management exists because human perception of "minor" is unreliable. What appears simple to the developer often has ripple effects to accounting, logistics, or other integrated systems that the developer has no visibility into.
A practical middle ground: many organizations have a "standard change" category for pre-approved, well-understood, low-risk changes (e.g., applying a monthly OS patch to a specific class of servers). These still go through a lightweight process — documentation and notification — but don't require full CCB review. This balances speed with accountability without abandoning process entirely.