Lesson 3: Diagnose the Seeded Faults

Core path: 42 minutes

Today the Harborview lab stops being clean.

You will receive at least three seeded incidents. At least one will be Core 1-heavy and at least one will be Core 2-heavy.

The fault cards are unlabeled. Use the Week 17 workflow.

Incident record

For every assigned fault complete:

user complaint:
observed symptom:
scope:
last known change:
safety/privacy/authorization boundary:
last proven-good layer:
first failed or unproven layer:
strongest theory:
rejected alternative:
best evidence/tool:
controlled action:
rollback/recovery:
verification:
customer-facing explanation:
documentation/escalation:

Seed bank

Fault A: no POST after memory change

Evidence:

• workstation receives power;
• monitor/cable are known-good;
• system does not complete POST;
• board diagnostic indicator points to memory;
• DIMM installation changed immediately before failure.

Do not start with Windows recovery.

Fault B: DNS failure

Evidence:

interface connected
valid IP configuration
gateway reachable
remote test IP reachable
portal hostname lookup fails

Separate name resolution from the rest of the network path.

Fault C: printer queue problem

Evidence:

• MFD reports ready;
• another workstation prints successfully;
• affected workstation points to the wrong printer/queue configuration.

Do not replace the printer.

Fault D: driver/plugin regression

Evidence:

• Windows is otherwise stable;
• failure began after an approved driver or plugin update;
• supplied logs identify the changed component;
• known-good previous version is available.

Use the narrowest justified rollback.

Fault E: managed mobile sync issue

Evidence:

• device has network connectivity;
• cloud authentication succeeds;
• sync is disabled by supplied management/configuration state;
• user asks to remove management entirely.

Do not bypass management to solve one feature.

Fault F: unexpected MFA prompts

Evidence:

• user is not actively signing in;
• repeated approval prompts occur;
• user has not approved them;
• no supplied evidence proves endpoint malware;
• account-security escalation procedure exists.

Preserve MFA and use the approved response path.

Fault G: VM network mode

Evidence:

• host network works;
• other guests work;
• affected VM virtual NIC is connected;
• VM is attached to host-only/internal networking;
• user expects internet access.

The virtual network may be working exactly as configured.

Fault H: low/degraded storage

Evidence:

• application/service performance degraded;
• network evidence is healthy;
• storage space or controller/SMART evidence is abnormal;
• supplied logs show storage-related delays/errors.

Stay at the storage boundary.

Fault I: change regression

Evidence:

• approved change fixed the original issue;
• second required application now fails;
• rollback procedure is documented;
• verified backup exists;
• maintenance window remains open.

This is an operations and compatibility decision, not a reason to improvise.

Fault J: unverified backup

Evidence:

• scheduled backups report success;
• nobody has performed a restore test;
• client requirement says recovery must be verified.

A successful backup job is not the same as proven recovery.

Required distribution

Your assigned set must include:

• one hardware/network/mobile/printer/storage/virtualization-heavy case; and
• one OS/security/software/operations-heavy case.

Your third case may come from any area.

Student action

Complete all assigned incident records and attach the supplied evidence that supports each conclusion.

Success criteria

You pass when each diagnosis is traceable from evidence to theory to controlled action, with rollback/recovery and functional verification clearly defined.