TRIFECTAPP — SYNTHETIC FOUNDATION EVIDENCE
All examples are fictional teaching inputs, not production logs.

CASE 1: The destination is on another subnet
A fictional workstation needs to reach an application server. Its IPv4 configuration is correct, and there is no more-specific route to the server network.

Workstation: 192.0.2.25/24
Local subnet: 192.0.2.0/24
Default gateway: 192.0.2.1
Application server: 198.51.100.20

CASE 2: The name points to the wrong server
An application has moved to a new IPv4 address. The approved configuration names one destination, but the workstation receives an old DNS answer. The required TCP/443 path to the approved destination is already allowed.

Hostname: portal.study.example
Approved A record: 198.51.100.20
Observed DNS answer: 198.51.100.99
198.51.100.99 is the retired destination

CASE 3: A working connection is only one check
A fictional firewall policy permits staff to use the application server over TCP/443. Guests must be blocked from that service, and staff must not reach its TCP/22 listener. Routing and both server listeners are known to work in this lab.

Staff test host: 192.0.2.10
Guest test host: 203.0.113.10
Application server: 198.51.100.20
Observed so far: staff TCP/443 connection succeeds

CASE 4: Sign-in succeeds, but a file is denied
A user signs in successfully as a help-desk analyst. The same session can open general support documents but cannot open a payroll file. The documented policy allows only the payroll role to read that file.

Identity check: successful
Assigned role: Help Desk
General support document: allowed
Payroll file: denied
Payroll read permission: Payroll role only

CASE 5: A service fails after an update
A service in an isolated training environment stops responding shortly after an approved update. A timeline is available, but nobody has yet compared the service logs, dependencies or changed configuration.

07:55 — service health check passes
08:00 — approved update begins
08:03 — installer reports completion
08:04 — service health check fails
Cause has not been established

CASE 6: The certificate names another service
A fictional sign-in page presents a certificate from a trusted issuer and within its validity dates. However, the certificate does not cover the hostname requested by the learner. No wildcard or other matching name is present.

Requested hostname: portal.study.example
Certificate DNS name: files.study.example
Trust-chain check: passed
Validity-date check: passed
Hostname match: failed