Lesson 4: Mixed Incident Lab

A real support queue does not label tickets hardware, networking, security, or Windows before you open them.

It gives you a complaint, a machine, some history, and whatever evidence survived.

Today the categories disappear.

The only useful question is:

Where is the first boundary that no longer behaves the way the system requires?

Five incidents follow. Each one crosses more than one topic from the course. The point is not to guess the certification domain. The point is to keep the system visible while the symptom tries to distract you.

Station 1: power is present, Windows never enters the story

User report:

The desktop turns on, but Windows never appears.

Supplied evidence:

power LED: on
fans: spinning
monitor/cable: known-good on another system
normal POST completion: not observed
motherboard diagnostic indicator: DRAM
recent change: second DIMM installed
OS/software changes: none

Start with what survived.

Power reaches enough of the system to light LEDs and spin fans.

That does not prove CPU, memory, or every rail is healthy.

The system has not completed POST, so Windows is not yet the first useful boundary.

The diagnostic indicator and recent memory change make the memory configuration a strong starting point.

A defensible path

confirm safe power-off
→ verify new DIMM type/compatibility
→ inspect seating and recommended slot population
→ restore last known-good memory configuration if appropriate
→ attempt POST
→ verify full detected memory after POST returns

Why not reinstall Windows?

Because the system has not reached the operating-system boundary.

Why not replace the motherboard immediately?

Because the strongest evidence points toward the recently changed memory path, and the previous memory configuration gives you a known-good baseline.

Verification

A successful result is not simply screen lights up.

Verify:

• normal POST completes;
• firmware detects the intended memory amount;
• no memory diagnostic indicator remains;
• Windows boots normally;
• basic workload remains stable.

Station 2: “the internet works” and the portal still does not

User report:

Everything else works, but the class portal won't open.

Evidence:

interface: connected
IP configuration: valid
gateway: reachable
remote documentation IP: reachable
portal hostname lookup: fails
portal IP, when supplied directly: reachable

The physical network has already proved a lot.

Replacing the cable would throw away that evidence.

The first failed responsibility is name resolution.

Strong question

Is the client asking the intended DNS service, and does that service return the expected record?

Useful evidence:

• configured DNS server;
• supplied DNS query result;
• local hosts-file/static override state where applicable;
• expected portal record.

Weak detour

Run a cable tester because networking is involved.

No.

Remote IP traffic already works. The cable path is functioning well enough for routed communication.

Verification

After the approved DNS correction:

1. resolve the portal hostname to the expected address;
2. open the portal by name;
3. verify the required application function.

A successful DNS query alone is not the user's actual requirement.

Station 3: one application fails after one application change

User report:

My laptop crashes whenever I open the graphics program.

Evidence:

Windows boot: normal
other applications: normal
system stability outside target app: normal
recent change: application plugin update
application log: plugin load failure
previous approved plugin: available

This is where scope saves time.

If the operating system and unrelated applications are healthy, a whole-OS reinstall is much larger than the evidence supports.

The failure is concentrated around the application/plugin boundary.

Controlled action

• preserve current application/plugin version state;
• roll back the implicated plugin using the approved package/configuration;
• relaunch the application;
• test the feature the plugin actually provides.

What would weaken the plugin theory?

If the application still crashes identically after the known-good plugin is restored, the plugin-only theory becomes weaker.

Then you move to the next boundary instead of pretending the failed correction worked.

That is what evidence-first troubleshooting looks like when the first theory loses.

Station 4: the security control is annoying because it is detecting something

User report:

I keep getting sign-in approval prompts. Can you turn MFA off?

Evidence:

user is not intentionally signing in
multiple unexpected MFA prompts occurred
user did not approve any prompt
endpoint protection: enabled/current
no supplied evidence proves device malware
organization account-security escalation: available

The most important fact is not that MFA is inconvenient.

The user is receiving authentication requests they did not initiate.

Disabling MFA would remove a control that is currently preventing those requests from becoming approved sessions.

What is proven?

• authentication attempts reached an MFA approval stage;
• the user did not initiate the expected sign-in;
• the user correctly denied/ignored the prompts.

What is not proven?

• malware exists on the endpoint;
• the password is definitely compromised;
• the identity provider is compromised;
• the prompts came from one specific attacker.

Safe response

Follow the organization's account-security path:

• preserve timing/alert evidence;
• review authorized account/session evidence;
• revoke or protect sessions/credentials as policy directs;
• reset credentials if the incident owner requires it;
• verify MFA remains enabled and expected sign-in works afterward;
• document and escalate.

Do not blame the user.

They did exactly what the control needed them to do: they did not approve an unexpected request.

Station 5: the update fixed one problem and created another

User report:

The update fixed the original issue, but our main application is broken now. We need to go back.

Evidence:

approved change ticket: exists
update purpose: documented
original problem: resolved
business-critical application: now incompatible
rollback package/configuration: available
verified backup: completed before change
maintenance window: still open

This is not a troubleshooting failure.

It is exactly why change management includes rollback.

The new state does not satisfy the full business requirement.

Decision

Use the approved rollback path while the maintenance window and recovery conditions remain valid.

Then verify both sides:

• business-critical application works again;
• system returns to the approved baseline;
• original issue is understood as reopened/unresolved rather than silently ignored.

The rollback restores service. It does not magically solve the original defect.

That distinction belongs in the ticket.

The common structure across all five incidents

The technologies are different.

The reasoning is the same:

complaint
   ↓
scope
   ↓
recent change
   ↓
known-good boundaries
   ↓
first failed / uncertain boundary
   ↓
question-driven evidence
   ↓
controlled action
   ↓
rollback / recovery
   ↓
verification
   ↓
communication / documentation

That is the course model in one page.

Build the service records

For every station, preserve:

user complaint:
observable symptom:
scope:
last known change:
known-good boundaries:
first failed or unproven boundary:
strongest theory:
competing theory:
best evidence source:
irrelevant tool/action rejected:
safety/privacy/authorization boundary:
controlled action:
rollback/recovery:
verification of real requirement:
customer-facing explanation:
documentation/escalation:
remaining uncertainty:

Do not write the objective number.

The system does not care which exam domain owns the symptom.

Peer review should attack the reasoning, not the person

When reviewing another technician record, ask:

• Does the evidence actually support the theory?
• Which claim is too large for the evidence?
• Is a safer or smaller test available?
• Does the correction preserve recovery?
• Does verification test the user's actual requirement?
• Is a security control being removed merely because it became inconvenient?
• Did the technician preserve data, privacy, and authorization boundaries?

A useful peer review finds the weak link in the reasoning chain.

It is not a hunt for formatting mistakes.

Before you move on

If these five incidents feel like five unrelated topics, look again.

They all reduce to one technician skill:

Keep the boundaries visible, let surviving function eliminate bad theories, and change only what the evidence has earned.

Next you defend that process without the worksheet scaffolding.