Lesson 5: Technician Review Board

A technician should be able to explain a repair without hiding behind the tool they used.

That is the standard for this review board.

You are not being graded on whether you can say hardware, networking, security, or Windows quickly enough.

You are being graded on whether another technician can follow your reasoning and reach the same conclusion from the same evidence.

A technical defense begins with the symptom, not the answer

Start with what the user experienced.

Then separate it from what the system actually proved.

Example:

The user reported that the class portal was down.

That is the complaint.

Evidence:

Wi-Fi: associated
IP configuration: valid
gateway: reachable
remote IP: reachable
portal hostname: fails to resolve

Now the complaint has been narrowed.

The network is not simply “down.”

The first failed responsibility is name resolution for the required host.

That is the difference between repeating the user report and diagnosing the system.

1. State the scope before the cause

Every defense should answer:

• one user or many?
• one device or many?
• one application or whole system?
• local or remote?
• wired or wireless?
• before or after a known change?
• constant or intermittent?

Scope removes bad theories quickly.

If one browser profile redirects while every other application and profile behaves normally, a whole-network compromise is not the strongest first explanation.

If every VM becomes slow at the same moment while the host begins paging heavily, one guest application is not the strongest shared cause.

2. Name the strongest evidence

Do not say:

I checked everything.

Name the evidence that changed the model.

Examples:

• UEFI does not detect the SSD;
• the DRAM diagnostic LED remains active after a memory change;
• remote IP works while DNS lookup fails;
• Safe Mode works after a driver update while normal mode does not;
• the app log identifies a plugin load failure;
• unexpected MFA prompts occur while the user is not signing in;
• a change record shows the failure began immediately after a firewall rule change;
• the RAID controller reports degraded state and a member health warning.

Strong evidence does not have to look dramatic.

It has to separate theories.

3. Keep the theory bounded

Weak theory:

The motherboard is bad.

Stronger theory:

The system stopped completing POST immediately after a second DIMM was installed, and the motherboard's DRAM diagnostic indicator remains active, so the changed memory configuration is the strongest current failure boundary.

The stronger version tells another technician what to test.

It also leaves room for the theory to be wrong.

That is a feature, not a weakness.

4. Defend one rejected alternative

A good diagnosis should survive a reasonable competing explanation.

Example:

Theory A:

DNS configuration is failing.

Alternative:

Ethernet cable is bad.

Why is the cable theory weaker?

Because the endpoint already reaches the gateway and a remote IP address over that path.

The cable is not proven perfect under every condition, but it is working well enough for the tested routed traffic.

The surviving layer makes the alternative weaker.

5. Explain why the chosen action is proportional

The correction should fit the evidence.

Examples:

• reseat or revert the changed DIMM configuration;
• correct the specific DNS state;
• roll back the implicated plugin;
• restore one firewall rule;
• correct one mapped drive;
• escalate one policy mismatch;
• isolate a suspicious endpoint instead of exploring it;
• execute the documented change rollback.

If your first answer is reset everything, reinstall, format, disable security, or make everyone admin, expect the review board to ask why a smaller action was not justified first.

You should have an answer.

Usually, you will not.

6. Safety, privacy, and authority can stop a technically possible action

A technician can know how to perform an action and still be wrong to perform it.

Examples:

• swollen battery → stop normal service;
• burning smell → stop powered testing;
• possible incident evidence → do not casually reboot or wipe;
• managed MDM policy → do not remove management to satisfy one user request;
• unexpected MFA prompts → do not disable MFA;
• remote-support session → verify authorization before connecting;
• sensitive data → do not copy to personal storage or unapproved AI tools.

Technical capability is not authorization.

Include the boundary in the defense.

7. Rollback shows whether you understood the risk of your own fix

Ask:

If my correction is wrong, what happens next?

A rollback may involve:

• restore previous driver;
• restore previous plugin;
• reinstall known-good memory configuration;
• restore approved firewall rule;
• recover from backup;
• revert a virtual configuration;
• use the documented change rollback package.

Sometimes no clean rollback exists.

Then the correct answer is not to invent one.

State the risk and identify the required backup, approval, or escalation before proceeding.

8. Verification returns to the original requirement

Suppose you corrected DNS.

Verification is not complete because nslookup returns an address.

The user needed the portal.

So test the portal.

Suppose you rolled back a display driver.

Verification is not complete because Device Manager looks clean.

The user needed stable display output and the graphics workflow.

Test those.

Suppose you corrected guest-network segmentation.

Verification includes:

guest → internet: allowed
guest → staff server: denied

The denied path is part of the requirement.

9. Explain the result in language the user can use

Technical accuracy does not require technical clutter.

Internal note:

DNS resolution failed because the client was querying an incorrect resolver state.

User explanation:

Your computer could reach the network, but it could not translate the portal name into the address it needed. We corrected that setting and verified the portal opens normally again.

The second version is not less technical.

It is better communication.

10. Document what the fix did not solve

A repair record should preserve remaining uncertainty.

Examples:

• the DNS issue is fixed, but the original reason the setting changed is still under review;
• the rollback restored the business application, but the original update problem remains open;
• the memory configuration restored POST, but the new DIMM has not yet been proven defective versus incompatible;
• the account was secured, but no evidence currently proves whether credentials were exposed;
• the provider outage is confirmed, but local technicians do not control restoration timing.

This keeps the next technician from assuming the entire world is healthy because one symptom disappeared.

Review-board challenge questions

Be ready for questions such as:

What evidence would make you abandon your theory?

Which boundary did you prove healthy before moving higher?

Why did you reject the more destructive repair?

Which user data was at risk during your change?

What happens if your correction fails?

Which part of this incident is outside your authority?

What negative test proves the security boundary still exists?

Which earlier week gave you the mechanism you used here?

These are not trick questions.

They test whether the reasoning survives pressure.

Your three defenses

Choose three incidents from Week 17.

Use:

• at least one Core 1-heavy incident;
• at least one Core 2-heavy incident;
• at least one incident crossing multiple layers.

For each, submit:

incident title:
user complaint:
scope:
last known change:
known-good boundaries:
strongest evidence:
first failed / uncertain boundary:
theory:
competing theory:
why the competing theory is weaker:
controlled action:
safety / privacy / authorization boundary:
rollback / recovery:
verification of real requirement:
plain-language user explanation:
documentation / escalation:
remaining uncertainty:

Then defend one incident aloud or in a short written technical defense.

What changed since Week 1?

In Week 1, the central lesson was that “the computer is dead” is not evidence.

Seventeen weeks later, the same rule applies to much larger systems:

“the internet is down”
“Windows is broken”
“the cloud is down”
“the drive is dead”
“the phone is hacked”
“security is blocking me”

Every one of those statements begins the investigation.

None of them should end it.

Week 17 checkpoint

You are ready for the final week when you can move through this chain without being told the answer category:

System process animation

The technician diagnostic loop

Move from intake to evidence, theory, controlled test, correction, verification, and documentation.

RestartPreviousPlay sequenceNext

1. 1IntakeRestate function, scope, impact, and change.
2. 2BaselineRecord state before modifying it.
3. 3EvidenceCollect observations that separate layers.
4. 4TheoryName one explanation that predicts evidence.
5. 5Controlled testTest one variable with an expected result.
6. 6CorrectApply the least-disruptive authorized fix.
7. 7VerifyRetest original function and dependencies.
8. 8DocumentRecord evidence, outcome, risk, and follow-up.

Technician question: Where does the loop return when a prediction is disproved?

Week 18 will ask you to use that process across one complete client service challenge from intake to final handoff.