Cheat sheet & self-check

Pick an answer to see if you got it, and why.

1. Q1. What's the main economic argument for ZTP at the edge?

   1. ACheaper servers
   2. BAvoiding truck rolls: sending skilled engineers to hundreds of remote sites is slow, expensive and error-prone; automation makes every site the same
   3. CFaster CPUs
   4. DNo need for networks
   Show answer

   B. The site needs only someone who can rack and cable; everything else is remote, repeatable and auditable.

   From lesson 01 · Why ZTP for edge

2. Q2. Which statement best describes 'zero-touch'?

   1. ANobody ever touches the hardware
   2. BAfter physical installation (rack, cable, power), provisioning from firmware to running workloads happens without manual steps on site
   3. CNo monitoring is needed
   4. DClusters never need upgrades
   Show answer

   B. Hands still install hardware; zero-touch covers everything after that.

   From lesson 01 · Why ZTP for edge

3. Q3. Why must a site be described declaratively (in Git)?

   1. AFor fun
   2. BSo any site can be recreated or repaired identically from its definition, changes are reviewed, and drift is detectable
   3. CGit is faster than SSH
   4. DKubernetes requires Git
   Show answer

   B. The site definition is the source of truth for day 1 and every day-2 rebuild.

   From lesson 01 · Why ZTP for edge

4. Q4. Why can't a central data-centre provisioner simply PXE-boot servers at every remote site?

   1. APXE is too new
   2. BPXE relies on DHCP broadcasts on the local layer-2 network; across a WAN you need DHCP relay (and reliable TFTP/HTTP paths) or a provisioning component at the site, or virtual-media boot via the BMC
   3. CRemote sites have no electricity
   4. DKubernetes forbids it
   Show answer

   B. Boot protocols are local by nature. Designs either extend them carefully (relay) or place a small provisioner at the site, or use BMC virtual media.

   From lesson 02 · Architecture for edge ZTP

5. Q5. Why should sites connect outbound to the centre rather than accept inbound connections?

   1. AInbound is slower
   2. BSites often sit behind NAT/firewalls, and outbound-only reduces the attack surface: nothing on the site listens to the internet
   3. CGit requires it
   4. DCertificates need it
   Show answer

   B. Pull-based GitOps and agents that dial home fit this model.

   From lesson 02 · Architecture for edge ZTP

6. Q6. What limits the blast radius if one edge site is physically compromised?

   1. ANothing
   2. BPer-site credentials with minimal scope (read-only to its own config and images), no shared admin keys, and no network path from sites to other sites
   3. CA bigger firewall at the centre only
   4. DUsing the same password everywhere
   Show answer

   B. Assume some site will be compromised; design so that it can't be used to reach the fleet.

   From lesson 02 · Architecture for edge ZTP

7. Q7. Why is a two-node cluster a poor HA choice?

   1. ATwo nodes can't run pods
   2. Betcd needs a majority: with 2 members, quorum is 2, so losing either node stops the control plane; it's no more available than one node (and more complex)
   3. CKubernetes doesn't support 2 nodes
   4. DIt uses too much power
   Show answer

   B. Use 1 node (simple), 3 nodes (tolerates 1 failure), or a 2-node design with an external witness/arbiter where the platform supports it.

   From lesson 03 · Cluster sizing for edge

8. Q8. In a 3-node compact cluster, what must you plan for during a rolling upgrade?

   1. ANothing
   2. BWhile one node is drained or replaced, the remaining two must hold all workloads (and quorum), so plan capacity for N-1 and avoid upgrades during a node failure
   3. CAdding a 4th node permanently
   4. DDeleting all pods
   Show answer

   B. Upgrades temporarily reduce capacity like a failure does. Size for N-1 or use in-place upgrades where supported.

   From lesson 03 · Cluster sizing for edge

9. Q9. Why set systemReserved and kubeReserved on small edge nodes?

   1. AFor logging
   2. BTo keep CPU/memory for the OS, container runtime and kubelet, so workloads can't starve them and destabilise the node
   3. CTo speed up scheduling
   4. DOnly for GPUs
   Show answer

   B. On small machines, a starved kubelet or runtime turns a busy node into a NotReady node.

   From lesson 03 · Cluster sizing for edge