Module E1 of 3 · Exam and certification

Course revision guide

45 min 4 stages distilled 6 figures

The whole course in one place, arranged for revision. Each stage below gives you its figure, the distinctions worth holding in your head, the traps that stage warns against, and the fastest routes back into the full material. Skim the figures first, then test yourself against the distinctions: anything you cannot explain from memory points at the stage to revisit.

Two habits carry most of the marks in this subject. Answer every question by naming three things, the layer whose responsibility is in doubt, the identifier in play at that point in the path, and the check that would produce evidence rather than an opinion. And read every claim as a citation: which document says it, whether that document is published or still a draft, and which observatory measured the number on which date.

Four stages carry a learner from vocabulary to frontier judgement

Foundations, Applied and Practice run along the top row and Frontiers returns to the exam terminus, and each connector names what the stage before it hands on, so a stage taken out of order arrives without the language the next one assumes.

The course is one request path learned four times over, each pass deeper than the last, then examined: vocabulary, protocol behaviour, operational judgement, frontier readiness, two papers. Source: blueprint sections 1 and 4.

Four stages carry a learner from vocabulary to frontier judgement A serpentine map of five stage cards, module chips in brackets. Row one, left to right: Stage 1 Foundations, vocabulary of the path (IPv6, Wi-Fi, URL to first byte); Stage 2 Applied, the living protocols (TCP and congestion, DNS, TLS); Stage 3 Practice, securing and observing the path (zero trust, cloud, DDoS). The chain turns down the right into row two, read right to left: Stage 4 Frontiers, where the path is going (post-quantum, automation, measurement); then the Stage 5 exam and certification terminus, tinted red (revision guide, exam practice, mock exams). Connectors read shared vocabulary, protocol behaviour, operational judgement, frontier readiness, two papers one certificate. Stage 1Foundationsthe vocabulary of the pathIPv6Wi-FiURL to first byte Stage 2Appliedthe living protocolsTCP and congestionDNSTLS Stage 3Practicesecuring and observing thepathzero trustcloudDDoS Stage 4Frontierswhere the path is goingpost-quantumautomationmeasurement Stage 5Exam andcertificationFoundation andPractitioner papersrevision guideexam practicemock exams sharedvocabulary protocolbehaviour operationaljudgement frontier readinesstwo papers, one certificate

Stage 1: The layers, identifiers and checks that turn a symptom into a place to look

OSI is a reference model; TCP/IP is the operational stack

The diagram takes a symptom named in OSI vocabulary, follows the translate to arrow into the stack that captures and routing tools actually show, then follows choose test to the least disruptive test available there.

The model earns its keep when it helps a team agree where the evidence belongs.

OSI is a reference model; TCP/IP is the operational stack The visual compares OSI and TCP/IP. OSI is shown as a responsibility vocabulary with seven named layers. TCP/IP is shown as the implemented Internet architecture with application, transport, internet, and link responsibilities. A bridge note warns against treating OSI as the literal running stack. ISO/IEC 7498-1OSI reference modelSeven responsibilitynamesGood for clear faultlanguageNot the softwarestack on the wire RFC 1122 / 1123TCP/IP operationalstackApplication,transport, internet,linkMatches deployed hostbehaviourUsed by captures androuting tools TEACHER'S BRIDGEPractical bridgeTranslate the symptomPick the observableboundaryRun the leastdisruptive test translate to choose test

Hold these distinctions

  • A model is not an implementation: ISO/IEC 7498-1 is a reference model written to coordinate standards work, while RFC 1122 describes the architecture that is actually implemented and deployed
  • Frame versus packet versus segment: a frame carries a packet and a packet carries a segment; the frame header is rewritten at every hop, the IP header survives end to end, and the transport header is read only by the two endpoints
  • Local versus remote delivery: when the mask says the destination shares the network, the host resolves the neighbour's link address and delivers directly; when it does not, the host hands the frame to its default gateway and the IP addresses in the packet stay the same
  • SLAAC versus DHCPv6: SLAAC (RFC 4862) lets a host build its own address from a router advertisement and is the IPv6 default; DHCPv6 (RFC 8415) is chosen where the network wants to record and control what each host receives
  • SSID versus BSSID: the SSID is the network name a user selects and many radios can share it; the BSSID is one access point radio's own address, and roaming means moving between BSSIDs while the SSID never changes
  • Latency versus bandwidth: latency is how long a round trip takes and bandwidth is how much a path can carry per second; adding bandwidth does not shorten a round trip, which is why a distant server still feels slow on a fast link
  • A name is not an address and an address is not a route: DNS turns a domain name into an IP address, and only after that does forwarding decide which path the packet takes
  • A MAC address is a local link identifier whose meaning ends at the segment, while an IP address is an end-to-end identifier; modern clients may present a locally administered randomised link address, so it is not a durable identity
  • IPv4 host counting versus IPv6 prefix planning: an IPv4 subnet is sized by host bits minus the network and broadcast addresses, while an IPv6 segment is a /64 allocated from a /48 and is not sized by counting hosts at all

Traps this stage warns against

  • Treating the OSI model as an implementation, and expecting to find seven layers in the software running on a real machine.

    Instead: OSI is a reference model. ISO/IEC 7498-1 states in clause 1 that its purpose is to give a common basis for coordinating standards development. RFC 1122 is the document that describes what is actually implemented, and it treats the Internet application layer as essentially combining the functions of the top two OSI layers, Presentation and Application.

  • Saying IPv6 is the future and scheduling it as a project for later.

    Instead: IPv6 is the present. Google measured 50.10 percent of its worldwide users reaching it over IPv6 on 28 March 2026, and APNIC Labs puts India and France above 70 percent capability. Every IPv4 plan you draw already has an IPv6 twin on the same segment, so treat them as one addressing plan rather than as an upgrade.

  • Calling every unit on the wire a packet, then wondering why a capture does not match the description.

    Instead: Use segment, packet and frame for what they are. The frame header is rewritten at every hop, so its addresses describe the last link only; the IP header survives end to end, so it is what you match when correlating captures at two points; the transport header is read by the two endpoints alone.

  • Treating a subnet boundary as a security boundary because traffic looks separated.

    Instead: Two subnets joined by a router with no access control reach each other by design. The mask decides delivery, not permission. Segmentation is a control you configure and verify, and the arithmetic still has to be right: a /26 leaves 62 usable addresses once the network and broadcast addresses are set aside.

  • Quoting a QUIC or HTTP/3 adoption figure as a single settled number.

    Instead: State the source, the method and the date. Cloudflare Radar put QUIC at roughly 21 to 35 percent of traffic depending on the window and method, and W3Techs put HTTP/3 support at about 39 percent of websites, both measured on 13 July 2026. A share of traffic and a share of websites are two different measurements and they will not agree.

  • Reading a Wi-Fi generation number as a speed number, and treating a roaming complaint as a bandwidth shortage.

    Instead: Wi-Fi 7 was certified in January 2024 and its features are Multi-Link Operation, 320 MHz channels and 4096-QAM; Wi-Fi 8, as 802.11bn Ultra High Reliability, targets roughly 25 percent gains in effective throughput, tail latency and roaming loss with certification planned for late 2027. Roaming stickiness, airtime saturation and interference explain most access-layer complaints, and a faster headline rate fixes none of them.

  • Citing Happy Eyeballs v3, BBRv3 or Multipath QUIC as RFCs because they have identifiers and read like finished specifications.

    Instead: All three were Internet-Drafts as of 13 July 2026, as draft-ietf-happy-happyeyeballs-v3, draft-ietf-ccwg-bbr and draft-ietf-quic-multipath. Say draft when it is a draft. Happy Eyeballs itself is RFC 8305, and version 3 is the revision in progress rather than a published replacement.

Stage 2: The living protocols, from a transport window to a forwarding decision to a name lookup

A repeatable diagnostic routine prevents random fixes

The loop can only close on a pass, and a fail leaves it standing at the named fault: keep to one change and one test per lap and the reading at nine o'clock belongs to the thing you altered rather than to the last three.

Diagnosis is a loop, not a guess. Find the first function that did not succeed, test it, read the result, then act. Never change two things at once.

Diagnose by loop, not by guess A four-node clock-face loop. 12 o'clock OBSERVE (emphasis) names the symptom (who, where, when). 3 o'clock PICK the first unproven function (DNS, IP, TCP, TLS, HTTP, in order). 6 o'clock TEST runs one safe command. 9 o'clock READ interprets the result. Four red arcs close the loop with labels narrows, evidence, reading, and 'fail leads to fault, pass returns to loop'. A central red card holds the rule: One change. One test. 1 · OBSERVE Symptom Who, where, when, what they saw. EXAMPLE POST /orders, no response after 30 s, prod app server only 2 · PICK First unproven function Walk DNS, IP, TCP, TLS, HTTP in order. EXAMPLE DNS resolves OK; ping OK; pick TCP next 3 · TEST Run one safe test Change one variable; record output verbatim. EXAMPLE curl --connect-timeout 5 https://api.host:443 4 · READ Read the result Pass moves up the chain; fail names the layer. EXAMPLE Connection timed out → Layer 4 firewall path narrows evidence reading fail → fault; pass → loop RULE OF THE LOOP One change. One test.

Hold these distinctions

  • Flow control versus congestion control: flow control is the receiver protecting itself and travels in every acknowledgement; congestion control is the sender inferring the limit of a path that never advertises one
  • The receive window is the receiver's stated capacity and the congestion window is the sender's own estimate of the path; the effective sending rate is the smaller of the two
  • Routing versus forwarding: routing is the control plane building a table from protocol metrics and policy; forwarding is the data plane doing one longest-prefix-match lookup per packet, with no fresh calculation
  • DNS over TLS on TCP 853 and DNS over QUIC on UDP 853 sit on a dedicated port a network can see and block as a category; DNS over HTTPS shares port 443 with the web, which is why it survives restrictive egress rules
  • A Valid route origin state means a signed ROA covers the prefix and authorises the announcing AS; NotFound means no ROA covers it at all, which is the honest answer for unsigned space and is accepted rather than dropped
  • NAT64 is translation performed in the network for hosts with no IPv4 at all; 464XLAT adds a CLAT on the host so an application that insists on IPv4, including one carrying an IPv4 literal, keeps working over that same NAT64
  • CUBIC infers congestion from loss; BBR estimates bottleneck bandwidth and round-trip time and paces against that model, and BBRv3 is an Internet-Draft rather than a published RFC
  • TLS over TCP is a second handshake on a connection that is already up; inside QUIC the transport and cryptographic handshakes are one exchange, which changes what a packet capture can still show you
  • A protocol downgrade is a finding and a fault is a conclusion: h2 where h3 was expected names one hypothesis about UDP 443 and nothing more until a capture confirms it

Traps this stage warns against

  • Reaching for UDP because it is faster than TCP.

    Instead: Both put bits on the wire at the same rate; the link, the queues and the distance decide that. What differs is what each transport makes you wait for: a handshake before data, a slowdown after loss, and one ordered stream that stalls behind a single missing segment. Choose by requirement, and note that QUIC (RFC 9000) removed most of the waiting without giving up reliability or congestion control.

  • Calling NAT the site's firewall because unsolicited inbound traffic does not get through.

    Instead: NAT is address sharing. Unsolicited traffic is dropped because no translation state matches it, which is a side effect of keeping state rather than a policy. RFC 4787 specifies that behaviour, not protection, and states that its mapping choices do not determine the security properties of the device. An IPv6 network reaches the same default-deny position with a stateful firewall and no translation.

  • Reading a firewall rule that permits 443 as covering all HTTPS traffic.

    Instead: Port numbers are per protocol and 443 exists over both. HTTP/1.1 and HTTP/2 use TCP 443; HTTP/3 carries HTTP over QUIC on UDP 443 (RFC 9114). A TCP-only allow does not fail loudly: the QUIC attempt goes unanswered, the client falls back, and the page still loads. Record which protocol was negotiated before comparing two networks.

  • Putting certificate renewal in the calendar once a year and giving it to a named owner.

    Instead: CA/Browser Forum ballot SC-081v3, approved on 11 April 2025, cuts the maximum validity of a publicly trusted TLS certificate to 200 days from 15 March 2026, 100 days from March 2027 and 47 days from March 2029. Automate issuance and installation with ACME, and inventory which certificates are publicly trusted, because private internal CAs sit outside the schedule.

  • Treating a handful of lost packets in a capture as proof of a fault.

    Instead: Loss, or an explicit ECN mark, is the congestion signal loss-based control depends on to find the right sending rate, so a small amount of it is evidence of a working transport. Compare idle latency with latency under load: if idle is fine and loaded is not, the problem is a full buffer and more bandwidth will not empty it (RFC 9330).

  • Telling a user that encrypted DNS makes their browsing private.

    Instead: DoT, DoH and DoQ protect query confidentiality against the network between the client and the resolver, and hand the resolver an attributable log of every name asked for. The destination IP address is still in the clear, and without Encrypted Client Hello the SNI field names the site during the TLS handshake. RFC 9849 closes that gap only where client, DNS and server deployment all support it, and only down to the fronting deployment.

  • Citing BBRv3 or Multipath QUIC as though they were published RFCs.

    Instead: Both are Internet-Drafts, draft-ietf-ccwg-bbr and draft-ietf-quic-multipath, and describing them as standards misstates what an operator can rely on. RFC 9743, published in March 2025, is the document that sets out what any new congestion control algorithm must demonstrate before it becomes one.

Stage 3: Placing controls, segmenting the estate and collecting evidence that holds up

A VPN grants a network; ZTNA grants one application

Both lanes start with the same user and the same three systems, but the VPN lane opens the finance database and build server nobody asked for while the ZTNA lane draws them denied, so authorisation is where blast radius is decided.

A VPN authenticates once and hands over a subnet; ZTNA authorises one application for one request, which is the implicit trust NIST SP 800-207 removes.

A VPN grants a network; ZTNA grants one application Two lanes side by side, each running four steps down the panel with labelled connectors. The left lane, VPN: reachability by location, authenticates a remote user once at the tunnel, puts that user on the internal subnet, makes everything on the subnet reachable including the finance database and build server the user never needed, and closes by stating that the blast radius is the subnet. The right lane, ZTNA: authorisation per request, evaluates the same user each request, has an identity-aware proxy decide per application, authorises only the HR portal, and shows a dashed denied connector to the other two systems. A callout states that NIST SP 800-207 removes implicit trust. VPN: reachability by location Remote user Authenticated once, at the tunnel, and then trusted. VPN concentrator Puts the user on the internal subnet and steps out of the way. Everything on that subnet HR portal: the one application the user actually needed. Finance database and build server: reachable anyway. Blast radius is the subnet One stolen session inherits every route the subnet has. tunnel up: the user is on the network an address inside the subnet, no app check lateral movement needs no new decision ZTNA: authorisation per request Remote user Evaluated again on every single request, never once. Identity-aware proxy Decides per application and per request (NIST SP 800-207). HR portal The one application this session is authorised to reach. Every later request is checked again on its own evidence. Finance database, build server Never routed to, never reachable, never even discovered. identity, device posture, request context authorised for this application only denied: no policy grants this request The difference in one sentence NIST SP 800-207 removes implicit trust: a request is authorised on its own evidence, not on where it came from. A VPN can only answer the question it was asked once, at the door.

Hold these distinctions

  • ZTNA is not a VPN: a VPN authenticates once and grants subnet reachability, while ZTNA authorises a single application on every request through an identity-aware proxy
  • SASE versus SSE: SASE is the networking half, meaning SD-WAN, combined with the security service edge, while SSE is that security half bought on its own
  • VXLAN is not a VLAN: a VLAN separates traffic inside one switched network, while VXLAN wraps the tenant frame inside a UDP envelope so the segment can cross a shared underlay
  • A flow is not a trace: a flow record says which endpoints talked, how much and for how long, while a distributed trace says where the time went inside one request across services
  • A capture filter is not a display filter: a capture filter decides what is written to disk and permanently discards the rest, while a display filter only narrows what you are looking at in a capture you already hold
  • Requests per second versus bits per second: a request flood exhausts server work and a volumetric flood exhausts link capacity, so the two numbers describe different attacks and cannot be compared
  • North-south versus east-west traffic: north-south crosses the perimeter and is what a traditional firewall inspects, while east-west moves between internal workloads and is where blast radius is actually decided
  • Zero trust is not a product: it is a property of how access decisions are made, which is why a maturity model describes decisions rather than purchases
  • A cache hit is not an origin request: a hit terminates at the point of presence and never reaches you, while a miss travels on through the origin shield to the origin, which is why origin logs and user reports can disagree without either being wrong
  • Reachability is not authorisation: reachability says a packet can arrive, authorisation says this identity may perform this action on this request, and confusing them is what made lateral movement cheap

Traps this stage warns against

  • Rolling out a VPN to all remote staff and reporting that the organisation has moved to zero trust.

    Instead: A VPN authenticates once and then grants network-level reachability, which is precisely the implicit trust NIST SP 800-207 removes. ZTNA authorises per application and per request through an identity-aware proxy. A tunnel with a new name still hands over the subnet.

  • Debugging a Kubernetes Service by reading iptables chains, because that is how kube-proxy has always worked.

    Instead: eBPF datapaths, Cilium being the canonical example, have displaced kube-proxy and iptables in most new production clusters, so the rules you are reading may not be on the path at all. Establish which CNI and which datapath the cluster runs before choosing the tool.

  • Treating the padlock in the address bar as evidence that a site is safe, and teaching users to check for it.

    Instead: TLS authenticates the server name and encrypts the channel. It says nothing about the intent behind that name, and phishing sites hold perfectly valid certificates. Teach users to read the name, not the padlock.

  • Escalating to the network team every time a capture or a graph shows packet loss.

    Instead: Loss, or ECN marking where it is available, is the congestion signal that loss-based control depends on, so a healthy path under load is expected to show some. L4S and BBR decouple low latency from loss, and adding bandwidth does not fix bufferbloat. Ask what the loss is signalling before calling it a fault.

  • Reading the segmentation diagram as a description of the current network.

    Instead: The diagram is the design; the live firewall rule base is the state. Allow rules accumulate one exception at a time until a boundary nobody re-checks has drifted back towards flat. Re-derive reachability from the running rules before claiming any blast radius, and remember that drift widens audit scope as well as risk.

  • Comparing denial-of-service attacks by their headline number without checking the unit.

    Instead: Requests per second, bits per second and packets per second exhaust different resources and are not interchangeable. Rapid Reset was a request flood: Google mitigated 398 million requests per second, Cloudflare 201 million and AWS 155 million. Those figures say nothing about link capacity.

  • Taking a capture on the wire and expecting to see the handshake, the server name and the request.

    Instead: A QUIC capture exposes little above the UDP header beyond connection identifiers and lengths, and Encrypted Client Hello removes the server name as well. Move the capture point to the host, the proxy, the resolver or the edge, and decide in advance what that point can still prove.

Stage 4: The migrations already under way, and how to cite them without overclaiming

The post-quantum migration runs to published dates

The browser default arrived before the NIST standards were finalised and the disallowance date is already published, so what remains open on this timeline is signatures, which the closing note records as not yet migrated.

The post-quantum migration runs to published dates: Chrome 124 in April 2024, FIPS 203, 204 and 205 in August 2024, and NIST IR 8547 disallowing classical public-key cryptography after 2035.

The post-quantum migration runs to published dates A vertical timeline. Each row pairs a date card on the left with the event card beside it, and a labelled arrow runs down the left spine from one date to the next. April 2024: Chrome 124 turns hybrid key exchange on by default. August 2024: NIST finalises FIPS 203, ML-KEM, together with FIPS 204 and FIPS 205 for signatures. Early 2026: above 30 percent of TLS 1.3 handshakes at Cloudflare's edge are post-quantum. After 2030: NIST IR 8547 deprecates classical public-key cryptography. After 2035, emphasised: it is disallowed. A closing note states that signatures have not migrated and that the hybrid group is an IETF draft, not an RFC. April 2024 shipped BROWSER DEFAULT Chrome 124 turns hybrid key exchange on by default Post-quantum key exchange starts appearing in ordinary handshakes, onconnections nobody configured for it. August 2024 standardised NIST STANDARDS FIPS 203, 204 and 205 are finalised FIPS 203 is ML-KEM, the key encapsulation used in hybrid key exchange.FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) are the signature standards. Early 2026 measured MEASURED SHARE Above 30 percent of TLS 1.3 handshakes are post-quantum Measured at Cloudflare's edge. Quote the source, the method and thewindow every time this number is used. After 2030 deadline NIST IR 8547 Classical public-key cryptography is deprecated Deprecated means still permitted but no longer recommended, which isthe point at which procurement questions start. After 2035 deadline NIST IR 8547 Classical public-key cryptography is disallowed Anything recorded today that is still sensitive then had to beprotected by a post-quantum key exchange from the start. the default shipped before the standard was final then the deployed share becomes measurable from what is measured now to the published deadlines deprecated becomes disallowed what the published dates leave out READ THE TIMELINE HONESTLY Key exchange migrated first, and signatures have not Certificates are not on this timeline: signature migration is only beginning, and thehybrid group X25519MLKEM768 is specified in an IETF draft, not in an RFC.

Hold these distinctions

  • ML-KEM (FIPS 203) encapsulates keys and is what migrated first; ML-DSA (FIPS 204) signs, and signature migration is only beginning, which is why the certificate chain your browser validates is still classical
  • Hybrid key exchange defends confidentiality against decryption years from now; post-quantum certificates defend authentication only at the moment the handshake happens, so a signature cannot be attacked retrospectively and the migration order follows
  • Matter is the application standard the devices speak; Thread is one of the link layers it can run over, alongside Wi-Fi and Ethernet, and the Thread border router is what joins the IPv6 mesh to the LAN
  • A zone groups assets that share a security requirement; a conduit is the controlled crossing between zones, and the policy lives on the conduit, not inside the zone
  • Purdue levels are a conceptual map of a plant; IEC 62443 zones and conduits are the design instrument, and cloud and IIoT paths cross the levels by design
  • NETCONF (RFC 6241) is the transaction protocol on its own session; RESTCONF (RFC 8040) is the HTTP face of the same YANG models, so the schema is shared and the transport differs
  • YANG (RFC 7950) is the schema language; OpenConfig is a vendor-neutral set of models written in it, and gNMI carries telemetry back rather than pushing configuration out
  • An RFC is published and citable as settled; an Internet-Draft such as draft-ietf-quic-multipath or draft-ietf-ccwg-bbr is work in progress, and being default in a shipping browser does not promote it
  • Cloudflare Radar measures traffic share across one very large network; W3Techs measures how many sites advertise support, so 21 to 35 percent of QUIC traffic and about 39 percent of sites advertising HTTP/3 are two different measurements rather than a contradiction
  • APNIC Labs measures end-user IPv6 capability at about 42 to 43 percent worldwide; Google measured 50.10 percent of its own users on IPv6 on 28 March 2026, and the gap is population, not error

Traps this stage warns against

  • Saying that post-quantum TLS means the site now has a post-quantum certificate.

    Instead: What deployed is hybrid key exchange: X25519MLKEM768, a draft, combining a classical X25519 share with an ML-KEM share, default in Chrome since version 124 in April 2024 and in Firefox 132, and above 30 percent of TLS 1.3 handshakes at Cloudflare's edge in early 2026. Certificates are still classical, and ML-DSA signatures only began appearing on origin-facing connections in mid 2026.

  • Handing an engineer a Purdue level diagram and calling it the segmentation design for an OT network.

    Instead: Purdue is a conceptual map. The design instrument is IEC 62443 zones and conduits, engineered against NIST SP 800-82r3, with NIS2 as the European regulatory floor. Cloud and IIoT data paths cross the Purdue levels by design, so a plan that assumes strict level ordering is describing a plant that no longer exists.

  • Citing Multipath QUIC, BBRv3, Happy Eyeballs v3 or X25519MLKEM768 as an RFC because a browser or kernel already ships it.

    Instead: All four are Internet-Drafts. Shipping is an implementation decision, not publication. Cite the working group document (draft-ietf-quic-multipath, draft-ietf-ccwg-bbr, draft-ietf-happy-happyeyeballs-v3, draft-ietf-tls-ecdhe-mlkem), call it a draft, and keep the claim inside what a draft can support.

  • Treating network automation as a specialist elective that the team can adopt when there is spare capacity.

    Instead: Industry surveys report automation rising from roughly 44 percent of organisations in 2024 towards two thirds by early 2026, and the syllabus bodies have ratified the shift: CCNA 200-301 v1.1 in August 2024 added Ansible, Terraform, cloud management and generative AI, and Network+ N10-009 in June 2024 added SDN, SD-WAN, infrastructure as code and VXLAN, with N10-008 retired in December 2024.

  • Quoting a single adoption percentage for QUIC, HTTP/3 or IPv6 with no observatory, method or date attached.

    Instead: Name all four parts. QUIC ran at roughly 21 to 35 percent of traffic on Cloudflare Radar depending on window and method, about 39 percent of websites advertised HTTP/3 on W3Techs, both measured 13 July 2026; APNIC Labs put IPv6 capability at about 42 to 43 percent while Google measured 50.10 percent of its own users on 28 March 2026. Different populations, different methods, both true.

  • Reading Salt Typhoon as an attack on customer traffic and responding by hardening the data path.

    Instead: The management plane was the target. A PRC state actor was inside major US telecoms from October 2024, CISA published hardening guidance in December 2024 and joint advisory AA25-239A in August 2025, and CISA now advises high-risk users to prefer end-to-end encrypted messaging. Harden the devices that configure and monitor the network first.

Exam technique for the two papers

The two certifying papers compared: format, time, materials, scoring and pass mark
PaperFoundationPractitioner
Sitting40 single-answer questions8 workplace scenarios
Time60 minutes90 minutes
MaterialsClosed bookOpen book
ScoringOne point per correct answerFive, three, one or zero per scenario
Pass mark24 of 40 points, 60 percent24 of 40 points, 60 percent

The Foundation paper gives you 90 seconds a question, so answer in one pass and flag rather than stall. Revise the definitions, the identifier that changes at a router boundary and the one that does not, and which documents are published rather than in progress. In the sitting, strike out the two options that overclaim or say nothing, then choose between what is left. The precise option beats the sweeping one, and picking the longest answer is exactly the habit this bank is written to punish.

Citation discipline is where this paper separates candidates. Multipath QUIC, BBRv3, Happy Eyeballs v3 and X25519MLKEM768 are , and a browser shipping one by default does not promote it to an RFC. A number needs an observatory, a method and a date attached to it, which is why a share of traffic and a share of websites never agree and neither is wrong. And a schedule is a fact you can be asked for directly: CA/Browser Forum ballot SC-081v3 cuts publicly trusted certificate validity to 200 days from 15 March 2026, 100 days from March 2027 and 47 days from March 2029, which is what makes automation the answer rather than a calendar reminder.

The Practitioner paper is 8 scenarios in 90 minutes, about 11 minutes each, scored five, three, one and zero to 40 points. Rank the four courses of action rather than hunting for one right answer. The strongest option names the layer in doubt, the identifier in play and the check that would settle it, then acts inside what that check can actually prove. The weakest confuses reachability with authorisation, reads a segmentation diagram as though it described the live rule base, treats ordinary congestion loss as a fault to escalate, or takes a capture at a point that cannot see what the question is about.

Nearly every scenario walks the same route: name the layer, name the identifier, name the check, then decide. When you are torn between two options, place each on that route. The one that reaches a named check and stays within its evidence, rather than stopping at a good intention, is usually the five-point answer. Open book means using the panel to confirm a date or a document number, not to read.

The scenario decision map for the whole troubleshooting course

The map gives each symptom the owner to call and the one safe test to run first, hands the opening three minutes a decision already made, and leaves a symptom with no row to be written on afterwards.

Each symptom has a first three minutes. Look it up; do not guess. The first action determines whether the next hour is investigation or recovery.

First three minutes by symptom · the on-call cheatsheet A six-row, four-column decision matrix. Columns: SYMPTOM (what users report) plus detail, WHO TO CALL (primary plus secondary), CHECK FIRST (specific safe test), REVISIT MODULE. Rows cover the most common symptoms (domain does not load, browser cert warning, slow only for one region (emphasis), 503 spikes, long-idle SSH drops, dashboards green users red). Each row names a single concrete first action. SYMPTOM (what users report) WHO TO CALL CHECK FIRST REVISIT MODULE Domain does not load anywhere users see 'this site can't be reached' DNS owner + platform dig +trace from a clean resolver; verify NS records MODULE 10 Browser warns 'not secure' cert error red bar in chrome TLS owner + security openssl s_client to see full chain; check SAN, expiry MODULE 14 Slow only for one region EU OK, US slow today network + edge / CDN real-user metrics sliced by region; mtr from affected MODULE 21 503 service unavailable spikes 30% of checkouts failing app on-call + platform app logs for upstream errors; security-group recent changes MODULE 16 + 20 Long-idle SSH or TCP drops session 'hangs' after 30 min yourself + network NAT mapping expiry; enable TCP keepalives MODULE 13 Dashboards green, users red internal checks pass, external probes fail comms + network external synthetic + BGP monitors (Module 18 lesson) MODULE 18 + 21 If the symptom does not match a row, write it on this poster after the incident. Future-you will thank present-you.

What each paper samples

Both sittings are sampled to a fixed blueprint, so a sitting always spans the course rather than clustering on one stage. These are the counts the sampler uses.

  • 12Foundations: models, addressing and the request path
  • 13Applied: the living protocols
  • 10Practice: securing and observing the path
  • 5Frontiers: where the path is going

The Practitioner paper takes one scenario from each of 8 domains: addressing and the ipv6 transition; the access layer and the request path; transport behaviour and congestion; name resolution and its trust boundaries; routing, forwarding and inter-domain trust; access architecture and segmentation; evidence, observability and incident response; frontier migrations and measurement literacy.

The primary sources behind the course

Every version-sensitive claim in the course anchors to a dated primary source, and each stage summary cites the specific document it draws on. The list below is collected from those stage summaries, so it is the same set of documents the teaching stands on. Bookmark the observatories in particular: is examinable in its own right, and a figure you quote should come with the source that published it.

When the distinctions hold from memory and the figures feel obvious, you are ready to drill the papers and then sit the mocks.