Lesson 3: Correct, Roll Back, and Verify

Core path: 42 minutes

Finding the likely cause is only half the job.

A professional technician also has to control the change, preserve recovery options, verify the result, and leave a useful record behind.

Controlled change

Before changing a system, ask:

• Is this action authorized?
• What user/data/service could be affected?
• Is there a backup, restore point, known-good package, exported configuration, snapshot, or other rollback path where appropriate?
• Can I make one change instead of five?
• How will I know the change worked?

A fix with no verification plan is a guess with confidence.

Rollback is part of the repair plan

Rollback can mean different things depending on the layer:

• reseat/remove a newly installed component;
• restore the previous driver;
• revert an application update/configuration;
• restore a known-good network/firewall rule;
• restore a VM snapshot only when that snapshot is an appropriate recovery point;
• restore data from a verified backup;
• reverse an account/policy change through the approved process.

Rollback is not always possible. When it is not, document that before the change.

Verify the required function

Verification should test the user's actual need.

Weak verification:

The error message is gone.

Better verification:

The workstation boots normally, display output is stable at the required resolution, Device Manager shows the approved driver without warning, and the user's application opens and renders correctly.

Scenario A: driver regression

Evidence:

• display worked before an approved driver update;
• external monitor loses output only after Windows loads;
• Safe Mode works;
• no physical monitor/cable fault is present in the scenario.

Controlled action:

Use the approved rollback/recovery method for the driver.

Verification:

• normal Windows startup;
• display detected;
• expected resolution/refresh behavior;
• no device warning;
• user workflow restored.

Scenario B: application update failure

Evidence:

• one application crashes after its plugin update;
• OS and other applications are stable;
• application log identifies plugin load failure;
• known-good previous plugin package/configuration is available.

Do not reinstall the whole OS.

Rollback the smallest implicated change, then verify both the application and the feature the plugin provided.

Scenario C: firewall/service path

Evidence:

• endpoint network is healthy;
• required service is running;
• application connection fails after a firewall-rule change;
• disabling the whole firewall is proposed.

Do not remove the entire control. Restore or correct the specific approved rule and verify the required service path while keeping the firewall enabled.

Scenario D: mobile policy/sync

Evidence:

• mobile device is online;
• account authentication succeeds;
• organization-managed sync is disabled by a recently applied configuration;
• user requests that management be removed entirely.

The technician does not bypass management to make one feature work. Verify the intended policy and correct/escalate the specific configuration through the approved MDM/support path.

Scenario E: approved remote support

Evidence:

• user has an authorized support ticket;
• approved remote-support tool is available;
• technician needs to inspect one configuration setting;
• session requires user awareness/authorization under policy.

Document authorization, connect using the approved method, perform the bounded task, verify the change, close the session, and document the outcome.

Student action

For three scenarios, complete:

approved change:
what could be affected:
rollback/recovery path:
change performed:
verification test:
result:
user-facing explanation:
documentation/escalation note:

Success criteria

You pass when the repair is reversible where practical, proportional to the evidence, verified against the real requirement, and documented clearly.