Field Guide Collection · Reference
Active recall for the whole collection. Each question below has a visible answer and a pointer to the guide that develops it — cover the answer line, say your own, then check. The answers are deliberately conceptual: they test whether you hold the reflex, not whether you've memorised a number. For the exact figures, follow the pointer.
These aren't trivia. Every question targets a reflex the collection tries to build — reading a signal for exactly what it proves, suspecting change, halving a problem, naming a threat before calling something safe. If you can answer in your own words and say why, you hold the idea; if you can only recite the answer, open the guide the pointer names.
1 A system that worked yesterday is broken today. What's the first question, and why that one?
answer "What changed?" Most incidents trace to a recent change — a config push, patch, deploy, expired cert, lapsed lease — so start at the change log, not the packet capture. → Network Sage-Advice — change is the prime suspect
2 Why bisect the path instead of testing candidates one at a time?
answer A test at the midpoint eliminates half the remaining possibilities, so a long path collapses in a handful of steps rather than a linear crawl. Each test is chosen to be maximally informative. → Network Sage-Advice — bisect, don't guess / Diagnostic Command Card
3 A middle traceroute hop shows 180 ms but the destination responds fine. Is that hop the problem?
answer No. Routers deprioritise ICMP aimed at their own control plane, so a middle-hop spike is often an artefact. Only loss or latency that persists to the final hop is real. → Networking Misconceptions
4 A config change was made ten minutes before the incident. Is that proof of cause?
answer No — temporal proximity is a strong lead, not proof. Confirm the mechanism (would change X actually produce symptom Y?); a coincidental event can sit near the change and be the real cause. → Network Sage-Advice — proximity is a lead, not proof
5 What does rebooting to "clear" an intermittent fault cost you?
answer It removes the symptom by destroying the evidence, guaranteeing a repeat with no more information than before. Instrument it and capture a baseline first. → Network Sage-Advice — protect the evidence before it disappears
6 Which destination address changes at every router hop, and which stays constant end to end?
answer The L2 destination MAC is rewritten at each hop (it names only the next link); the L3 destination IP is chosen once and rides unchanged end to end. → Networking / Visual Reference
7 What single decision does the subnet mask drive?
answer It splits an address into network and host parts, which answers "is the destination on my link?" — if yes, resolve its MAC and send direct; if no, hand it to the gateway. → Subnetting & CIDR
8 In what order does a router break ties between candidate routes?
answer Longest prefix match first, then administrative distance (trust between route sources), then metric (cost within one protocol). → IP Routing & Route Tables
9 Does putting a host on a 10.x or 192.168.x address protect it?
answer No — private (RFC 1918) ranges are an addressing scope, not a security boundary. Traffic still reaches them via routing, VPNs, and compromised internal hosts. → Subnetting & CIDR / Networking Misconceptions
10 A packet reached the server, so it was allowed — right?
answer No. Routing decides reachability; authorization is a separate question answered by the firewall and access policy. Reachable is not permitted. → IP Routing & Route Tables / Zero Trust
11 "We're waiting for DNS to propagate." What's wrong with that framing?
answer There is no propagation. The authoritative change is immediate; the delay is caches holding the old answer until their TTL expires. Lower the TTL ahead of a change and query the authoritative server to confirm. → DNS
12 Does DNSSEC keep your queries private?
answer No — DNSSEC provides authenticity and integrity of the answer. Confidentiality of the query comes from encrypted transport (DoT / DoH). They solve different problems and are complementary. → DNS
13 A browser reports the certificate expired, but you believe it's current. What do you check first?
answer The client's clock. Time skew fakes an "expired" or "not-yet-valid" error on a perfectly good certificate before you suspect the cert itself. → TLS & Certificates
14 What does a valid TLS padlock actually attest?
answer That you have an encrypted channel to the name you requested. It says nothing about the site's intent or safety — phishing sites serve valid TLS too. → TLS & Certificates / Networking Misconceptions
15 A TLS connection fails before any application data, versus after a clean handshake. What does each implicate?
answer Before app data → version, cipher, or certificate negotiation. After a good handshake → an application-layer problem, not TLS. The failure point localises the fault. → TLS & Certificates
16 On a stateful firewall, do you write an explicit return rule?
answer No. Permit the forward direction once; connection tracking matches replies as "established" and reverses any NAT automatically. An extra reverse rule is redundant at best and, if broader than the flow, a hole. → Firewall & Rule Creation
17 A public IP is DNAT'd to an internal host. Which address must your filter rule permit?
answer The internal, post-DNAT destination — because translation happens before the filter runs, so a rule written against the public IP silently never matches. → Firewall & Rule Creation
18 "Allow the /8, then deny one bad host" fails to block the host. Why?
answer First-match-wins: the broad allow above the deny matches first and stops evaluation, so the specific deny is shadowed. Put specific and deny rules above broad allows. → Firewall & Rule Creation
19 Behind a load balancer or proxy, what source IP does the backend see?
answer The intermediary's, not the client's. The real client survives only in X-Forwarded-For or the PROXY protocol, and only if the backend is configured to trust it — so enforce per-client policy where the client is still visible. → Firewall & Rule Creation
20 Why is blanket-blocking ICMP a mistake?
answer Path MTU Discovery relies on the ICMP "fragmentation-needed" / ICMPv6 "packet-too-big" message; drop it and large packets vanish while small ones pass (an MTU black hole). ICMPv6 also carries Neighbor Discovery, so blocking it breaks IPv6. → Firewall & Rule Creation / Diagnostic Command Card
21 A packet isn't in your capture. Does that prove it was never sent?
answer No. A capture sees only what crossed that vantage point; a SPAN port drops under load, a small snaplen truncates, a full buffer loses frames. Absence means it didn't cross your capture point — nothing more. → Packet Capture / Network Sage-Advice — a signal proves only what it proves
22 State the core stance of Zero Trust in one line.
answer Never grant trust based on network location; verify identity, device, and context on every request. Being on the "inside" earns nothing, and reachability is not authorization. → Zero Trust
23 On the Pyramid of Pain, why target an adversary's TTPs over their file hashes and IP addresses?
answer Hashes and IPs are trivial for them to change, so blocking those barely inconveniences them. TTPs — how they operate — are costly to change, so denying those imposes real, lasting pain. → Attack Taxonomy & Attribution
24 MFA — what threat does it address, and what residual risk remains?
answer It addresses stolen or reused passwords. The residual is phishable factors — push-fatigue approval, SIM-swap, real-time relay — which is why phishing-resistant methods are preferred where they matter. → Identity & Authentication
25 What makes a security control something you can actually evaluate?
answer A named threat model. "Is it secure?" is unanswerable; "does it stop this adversary?" can be answered — and every control should be stated with the residual risk it leaves and the threats it doesn't cover. → Network Sage-Advice — name the threat model / Zero Trust
A passed ping, a listening port, a valid padlock, a private address, a reachable host — each proves one narrow thing. Stacking narrow "yes" answers into a broad conclusion is how confident people get it wrong fast.
Ask what changed first, halve the problem instead of guessing, and believe the measurement over the mental model — from the real vantage, not the jump box.
Nothing is "secure" in the abstract. Pair every control with the adversary it addresses and the residual risk it leaves — a padlock, a NAT, a firewall rule are mechanisms, not verdicts.
These are active-recall prompts over material developed — and, where version-specific, verified — in the guides named after each answer. The answers are kept conceptual on purpose: for exact figures such as administrative-distance values, TLS versions and certificate lifetimes, port numbers, or RFC and standards identifiers, follow the pointer to the guide, which carries the checked specifics rather than a figure recalled here. Nothing on this sheet is a security assurance; several questions exist precisely to reject unqualified ones — a padlock, a private address, a reachable port, and a passed ping are signals, not verdicts. Cover the answer line and say your own before checking. Terms are in the Glossary; 00 · Start Here indexes the full set.