Cheat sheet & self-check

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

1. Q1. What happens on the admin machine during `eksctl anywhere create cluster` for bare metal?

   1. ANothing, it's all remote
   2. BA temporary bootstrap (kind) cluster runs the Tinkerbell stack and Cluster API controllers, provisions the servers, then moves (pivots) management into the new cluster
   3. CIt installs Windows
   4. DIt copies etcd from AWS
   Show answer

   B. The admin machine needs Docker and L2 reachability to the servers' network during creation.

   From lesson 08 · EKS Anywhere on bare metal

2. Q2. Why does a rolling upgrade on bare metal usually need spare hardware?

   1. AIt doesn't
   2. BRolling replacement provisions a new machine with the new version before removing an old one, so an extra, unused server matching the hardware selector must be available (unless in-place upgrades are used)
   3. CTo store backups
   4. DBecause of licensing
   Show answer

   B. On VMs you create a new VM; on bare metal the 'new VM' is a physical spare. Recent versions offer in-place upgrades to avoid this.

   From lesson 08 · EKS Anywhere on bare metal

3. Q3. How does EKS Anywhere pick which physical server becomes a control-plane node?

   1. ARandomly
   2. BTinkerbellMachineConfig hardwareSelector labels (e.g. type: cp) are matched against labels on Hardware records from the CSV
   3. CBy IP order
   4. DThe largest server always
   Show answer

   B. Labels in the inventory decide roles, so hardware placement is declarative and reviewable.

   From lesson 08 · EKS Anywhere on bare metal

4. Q4. What does RKE2's CIS profile setting do?

   1. AInstalls Rancher
   2. BApplies hardened defaults aligned with the CIS Kubernetes Benchmark (e.g. Pod Security, restrictive settings), and requires some host preparation such as an etcd user and kernel parameters
   3. CDisables TLS
   4. DOnly changes the logo
   Show answer

   B. RKE2 is designed for security-focused environments; the profile makes the hardened configuration the default.

   From lesson 09 · Rancher + RKE2 provisioning

5. Q5. How do additional nodes join an RKE2 cluster?

   1. AVia SSH from the first node
   2. BThey start with a config.yaml containing the cluster token and `server: https://<address>:9345` (the supervisor port), as servers (control plane + etcd) or agents (workers)
   3. CThey copy etcd files
   4. DThey can't join after creation
   Show answer

   B. Use a stable address (VIP or DNS) for `server` so joining doesn't depend on one specific node.

   From lesson 09 · Rancher + RKE2 provisioning

6. Q6. What problem does Elemental solve?

   1. APod networking
   2. BOnboarding and managing the operating system of edge machines from Rancher: machines register with a registration endpoint, appear as inventory, and are assigned to clusters and OS upgrades declaratively
   3. CReplacing Kubernetes
   4. DBackups only
   Show answer

   B. It extends cluster management down to the OS, using immutable SUSE-based images.

   From lesson 09 · Rancher + RKE2 provisioning

7. Q7. Why is pull-based GitOps especially suited to edge fleets?

   1. AIt's faster
   2. BSites dial out to fetch desired state, working behind NAT and across intermittent links; they keep running and converge when the link returns
   3. CPush is impossible
   4. DIt doesn't need Git
   Show answer

   B. The centre never needs inbound access to each site, and disconnected sites catch up automatically.

   From lesson 10 · GitOps fleet management

8. Q8. What's a canary site?

   1. AA site with birds
   2. BA small set of real sites that receive changes first; if they stay healthy for a defined period, the change is promoted to the next wave
   3. CThe lab cluster
   4. DA site without monitoring
   Show answer

   B. Labs catch obvious problems; canaries catch the ones that only appear with real hardware, traffic and networks.

   From lesson 10 · GitOps fleet management

9. Q9. Where should per-site differences live?

   1. AHand edits on each cluster
   2. BIn small, reviewed per-site values or overlays (site number, IPs, sizing profile) on top of a shared base, so 95% of the config is identical across sites
   3. CIn separate full copies per site
   4. DIn environment variables on laptops
   Show answer

   B. Small diffs are reviewable and keep the fleet consistent.

   From lesson 10 · GitOps fleet management

10. Q10. There's no cloud load balancer at the site. How do you give the Kubernetes API and Services stable IPs?

    1. AYou can't
    2. BA virtual IP managed in the cluster: kube-vip for the API endpoint (ARP or BGP), and kube-vip or MetalLB for Services of type LoadBalancer
    3. CUse node IPs only
    4. DBuy a public IP
    Show answer

    B. The VIP moves to a healthy node on failure, so clients and joining nodes keep working.

    From lesson 11 · Edge networking, storage & security

11. Q11. Why run local DNS and NTP at each site?

    1. AFor speed only
    2. BWhen the uplink fails, name resolution and correct time are still needed: certificates, etcd and logs all depend on time; local names must resolve without the centre
    3. CKubernetes requires them
    4. DTo save bandwidth only
    Show answer

    B. Clock drift breaks TLS certificate validation and makes incidents confusing; a site should survive being disconnected.

    From lesson 11 · Edge networking, storage & security

12. Q12. A server is stolen from a store. What limits the damage?

    1. ANothing
    2. BEncrypted disks bound to the device's TPM (and optionally a network unlock), per-site credentials that can be revoked, Secure Boot, and no long-lived secrets stored in plain text on the node
    3. CA strong BIOS password only
    4. DHiding the server
    Show answer

    B. Assume physical access by attackers; make the data unreadable and the credentials short-lived and revocable.

    From lesson 11 · Edge networking, storage & security

13. Q13. What do you need to rebuild an edge site after total hardware loss?

    1. AOnly the Git repo
    2. BSite definition (inventory + cluster spec) and GitOps repo in Git, images/bundles in the registry, and backups of state that isn't in Git (application data, and etcd if you restore rather than recreate)
    3. CA copy of the old disks
    4. DNothing, Kubernetes rebuilds itself
    Show answer

    B. Git recreates configuration; backups restore data. Both must be tested together.

    From lesson 12 · DR & compliance at scale

14. Q14. After a site-wide power loss, all nodes boot but the cluster doesn't come back. A common cause?

    1. AToo much RAM
    2. BNodes booted before the network/NTP were ready, clocks were wrong (certificate validation fails), or etcd members couldn't reach each other in time to form quorum
    3. CThe Git repo was deleted
    4. DPods were too small
    Show answer

    B. Power-on order, time sync and quorum formation are the usual suspects. Test full power cycles.

    From lesson 12 · DR & compliance at scale

15. Q15. Why automate compliance evidence per site?

    1. AAuditors like paper
    2. BWith hundreds of sites, manual checks can't keep up; automated scans, inventory and policy reports show continuously which sites meet the baseline and which have drifted
    3. CIt's required by Kubernetes
    4. DTo slow down changes
    Show answer

    B. Evidence generated by the platform is current, consistent and cheap.

    From lesson 12 · DR & compliance at scale