Prove what failed. Protect what works.
Unlike a short practice question, this exercise gives you a multi-source incident. The cause isn't guaranteed to live at one layer. You will inspect evidence, distinguish symptoms from explanations, request approvals for narrow corrections, test the original workflows, and document the actual outcome.
Best taken after Phase 04 / Network Operations & Security. You can revisit earlier lessons using the roadmap.
JUMP TO SECTIONChoose a lesson section
The intranet works for some users. Not for everyone.
At 09:14, the service desk records that HQ Finance clients behind access switch SW-B cannot open intranet.northstar.example. Two minutes later, Branch Finance reports a timeout. Initial monitoring suggests the application itself is healthy from an unaffected management network, so a full server outage is not yet established.
Both reports may have different network causes. The services team requires that Guest clients remain unable to reach the internal application. A prior maintenance window changed trunk VLAN allowances, a branch return route and an inbound Finance security rule. Your task is to establish what those changes actually did.
Map the user path before judging the fix.
Trace both affected source networks toward the same intranet server. The HQ client depends on the SW-B trunk to reach its routed gateway. The branch client travels over WAN-A but still needs a viable return path. The application's DNS name and server reachability are additional, independent checkpoints.
User's intranet request fails
Session fails despite healthy server
Must remain blocked
A trunk exclusion can explain one site's users losing their gateway. A stale more-specific branch return route can break another group's sessions. And an early ACL deny can still block Finance HTTPS after Layer 2 connectivity is repaired. Verify each path in order and look for regressions.
What you may change, and what you must preserve.
The exercise deliberately provides fictional, scoped change requests. The simulator grants approvals for specific fixes only after relevant evidence is inspected and the matching cause is recorded. Those buttons represent a training workflow, not actual IT authorization.
Read before touching
Determine who is impacted and what still works. Don't treat an alarm, link light or successful DNS lookup as proof of the full path.
Correlate independent sources
Compare both ends of a trunk, the most-specific installed route and the actual first matching ACL entry.
Get scoped authorization
Identify the specific change, preserve nearby services, and simulate the required approval before editing the model.
Validate positive and negative paths
Retest HQ and branch workflows, verify Guest isolation and prove unaffected VLANs still work.
Unsafe broad access rules, disabling STP, or removing unrelated VLANs/routes are not reasonable workarounds for this incident. The simulator blocks a sample broad-access proposal. It also supports rollback so you can observe that restoring a baseline may protect users even if the requested change remains unresolved.
A repeatable process, not a guessing game.
Review scope, switching, routing, ACL and application evidence. Note what each proves and what it cannot prove.
Pick an explanation for each fault domain. Incorrect interpretations are challenged, not silently accepted.
Request simulated approval, then apply only the narrowly scoped correction to that device/domain.
Test both affected groups, confirm the intended security deny and verify adjacent unaffected services.
All simulation state exists only in this page session and resets on a reload. This avoids an account requirement and prevents accidental assumptions about real changes or saved progress.
Investigate Northstar's network incident.
Start by opening the incident scope and application baseline, then collect the switching, routing and ACL observations. Choose supported hypotheses, request narrowly scoped simulated approval and apply changes. Run validations at any stage to see which faults remain—and rerun everything after your last change.
One reported outage. Three interacting faults.
Diagnose a fictional HQ/branch outage. The entire simulation runs locally in your browser: no accounts, real devices, server requests, or persistent progress.
Inspect the system before changing it.
Five independent evidence sources are available. Some evidence confirms what is working; none should be treated as permission for a blind change.
Select this source to inspect its fictional logs and observations.
Choose causes supported by evidence.
Each proposed correction requires the affected system's evidence, the incident scope and healthy-service baseline. Simulated approvals authorize only the narrow changes written in the ticket.
Simulated change scope: CHG-2041 / Add VLAN 20 only to SW-B Gi1/0/48 allowed list; preserve existing VLANs 10,30,40.
Inspect the campus vlan path evidence, incident scope and healthy service baseline to unlock this decision.
Simulated change scope: CHG-2042 / Correct the single 10.70.20.128/25 static next hop to approved WAN-A 10.1.0.2; retain other routes.
Inspect the branch return path evidence, incident scope and healthy service baseline to unlock this decision.
Simulated change scope: CHG-2043 / Put the existing Finance-to-intranet TCP/443 permit before its conflicting deny; preserve Guest denial and other restrictions.
Inspect the finance https policy evidence, incident scope and healthy service baseline to unlock this decision.
Production teams sometimes feel pressure to make a broad, risky change when a business app fails. Test the judgment—not the actual command—in this scenario.
Prove recovery without breaking protections.
Run each service check at any time. Failed checks reveal remaining faults. Each new repair clears previous check results, so you must verify the actual final state.
10.50.20.11 → intranet.northstar.example:443
10.70.20.180 → 10.50.40.25:443, including return path
Guest VLAN 30 → intranet 10.50.40.25:443 must be blocked
VLAN 10, VLAN 30 and management service health
Keep the ticket open until the service is proven.
A plausible diagnosis is not the same as a verified recovery. Complete the evidence, scoped corrections and non-regression checks.
Northstar campus + branch / educational capstone Evidence inspected: 0/5 Supported causes: 0/3 Simulated approvals and changes: 0/3 Verification passed: 0/4 Unsafe changes blocked: 0 Campus VLAN path: not established Branch return path: not established Finance HTTPS policy: not established HQ Finance user workflow: NOT YET TESTED Branch application session: NOT YET TESTED Negative security test: NOT YET TESTED Non-regression check: NOT YET TESTED Outcome: Not closed. Additional evidence, approved corrections or checks required.
What did the investigation really demonstrate?
When the simulated incident reports resolution, explain why the trunk fault affected HQ Finance, why the branch's /25 route outranked the working /16 aggregate, and why the ACL denied TCP/443 even with an otherwise valid route. Note the evidence you would capture before and after a real approved change.
Compare both allowed trunk VLAN lists, connected endpoints and where MAC learning should occur.
Trace the branch's return destination to the most specific route—not merely the default or the easiest-to-read line.
Record policy direction and first-match order. Confirm a necessary permit without defeating Guest isolation.
Document approval, scoped edit, rollback plan, both user workflows, negative security checks and non-regression.
Keep the fundamentals accessible.
You can revisit every preceding phase whenever a hypothesis is unfamiliar. Existing Practice and Labs extend the learning, but this capstone itself is a safe, browser-local simulation rather than a real equipment exercise.
Complete the integrated incident first, then revisit specific skills in Practice or work through another Troubleshooter investigation.