Cheat sheet & self-check

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

1. Q1. What's the main reason to split one big cluster into several?

   1. AKubernetes can't run more than 100 nodes
   2. BLimit blast radius: an outage, bad upgrade or noisy tenant affects only one cluster
   3. CClusters are free
   4. DRBAC doesn't work in big clusters
   Show answer

   B. Separate clusters isolate failures, upgrades, compliance scope and tenants. The cost is more to manage, which is why fleet tooling exists.

   From lesson 28 · Multi-cluster & fleet management

2. Q2. In Cluster API, what is the management cluster?

   1. AThe biggest production cluster
   2. BA cluster running Cluster API controllers that create and manage other (workload) clusters from Kubernetes objects
   3. CA cloud console
   4. DThe etcd cluster
   Show answer

   B. Workload clusters are described as Cluster, MachineDeployment and related objects. Controllers in the management cluster reconcile them into real machines.

   From lesson 28 · Multi-cluster & fleet management

3. Q3. How do you install the same monitoring stack on every production cluster with Argo CD?

   1. ACreate one Application per cluster by hand
   2. BAn ApplicationSet with a cluster generator selecting clusters labelled env=prod
   3. CCopy YAML with scp
   4. DUse a DaemonSet
   Show answer

   B. An ApplicationSet generates one Application per matching cluster from a single template, including clusters added later.

   From lesson 28 · Multi-cluster & fleet management

4. Q4. Which tenancy model gives the strongest isolation?

   1. ANamespaces with RBAC
   2. BVirtual clusters
   3. CA dedicated cluster per tenant
   4. DLabels on pods
   Show answer

   C. Separate clusters share nothing in the control plane or nodes (unless you choose to). The trade-off is cost and operational overhead.

   From lesson 29 · Multi-tenancy models

5. Q5. By default, can a pod in namespace team-a reach a pod in team-b?

   1. ANo, namespaces isolate networks
   2. BYes: Kubernetes networking is flat until NetworkPolicies (enforced by the CNI) restrict it
   3. COnly through a Service
   4. DOnly with RBAC permission
   Show answer

   B. Namespaces are an API boundary, not a network boundary. Add default-deny NetworkPolicies, with a CNI that enforces them.

   From lesson 29 · Multi-tenancy models

6. Q6. What does labelling a namespace pod-security.kubernetes.io/enforce=restricted do?

   1. AEncrypts its secrets
   2. BRejects pods that don't meet the 'restricted' Pod Security Standard (e.g. privileged, root, host access)
   3. CHides it from other users
   4. DLimits its CPU
   Show answer

   B. Pod Security Admission is built in. 'restricted' blocks privileged containers, host namespaces, running as root and other risky settings.

   From lesson 29 · Multi-tenancy models

7. Q7. A virtual cluster (e.g. vcluster) gives each tenant…

   1. ATheir own physical nodes
   2. BTheir own API server and control plane, while pods run on the shared host cluster
   3. CA separate cloud account
   4. DNothing more than a namespace
   Show answer

   B. Tenants get cluster-admin-like freedom (their own CRDs, namespaces, RBAC) inside a virtual control plane, while the host cluster's nodes and networking are shared.

   From lesson 29 · Multi-tenancy models

8. Q8. What is a 'golden path'?

   1. AThe only allowed way to deploy
   2. BA well-supported, opinionated default route from idea to production that teams choose because it's easiest
   3. CA premium support tier
   4. DA network route
   Show answer

   B. Golden paths are paved roads, not walls: the easy, safe default. Teams can leave them, but then own the extra responsibility.

   From lesson 30 · Internal Developer Platform design

9. Q9. Why treat the platform as a product?

   1. ATo charge teams money
   2. BBecause its success depends on developers choosing to use it: that needs user research, a roadmap and feedback, like any product
   3. CTo avoid documentation
   4. DBecause Kubernetes requires it
   Show answer

   B. A platform nobody adopts has failed, however good the technology. Product thinking keeps it focused on developers' real problems.

   From lesson 30 · Internal Developer Platform design

10. Q10. Which is a guard-rail rather than a gate?

    1. AA weekly change-approval meeting
    2. BAn admission policy that automatically rejects containers running as root
    3. CEmailing the platform team for every deploy
    4. DA spreadsheet of approved images
    Show answer

    B. Guard-rails are automated and instant. Gates are manual and slow. Good platforms turn most gates into guard-rails.

    From lesson 30 · Internal Developer Platform design

11. Q11. Why measure 'can a team deploy and reach a test app' with a synthetic probe?

    1. AIt's cheaper than metrics
    2. BIt measures a real user journey end to end (API, scheduling, image pull, networking, DNS), which component metrics can miss
    3. CPrometheus can't measure the API
    4. DIt replaces all other monitoring
    Show answer

    B. Users experience journeys, not components. A probe that deploys, exposes and calls an app fails if any layer is broken, even when each component looks healthy.

    From lesson 31 · SLOs for the platform itself

12. Q12. A 99.9% monthly SLO allows roughly how much 'bad' time in 30 days?

    1. A4 minutes
    2. B43 minutes
    3. C7 hours
    4. D3 days
    Show answer

    B. 0.1% of 30 days = 0.001 × 43,200 minutes ≈ 43 minutes. That's the error budget.

    From lesson 31 · SLOs for the platform itself

13. Q13. What's the benefit of burn-rate alerts over 'error ratio > 0' alerts?

    1. AThey fire more often
    2. BThey page only when the budget is being consumed fast enough to matter, and ignore harmless blips
    3. CThey don't need Prometheus
    4. DThey measure latency only
    Show answer

    B. Burn-rate alerts tie paging to the SLO: a burn rate of 14.4 over an hour spends 2% of a 30-day budget, which is worth waking someone up for.

    From lesson 31 · SLOs for the platform itself

14. Q14. What's the purpose of an ADR (Architecture Decision Record)?

    1. ATo list every YAML file
    2. BTo capture one decision, its context, the options considered and the consequences, so future readers understand why
    3. CTo replace the design document
    4. DTo assign tickets
    Show answer

    B. ADRs keep the 'why' next to the 'what'. When someone asks in two years why there are 6 clusters, the answer is written down.

    From lesson 32 · Capstone: platform design review

15. Q15. A reviewer asks 'what happens if the management cluster is down?' A strong answer is…

    1. AIt can't go down
    2. BWorkload clusters keep running and serving; only provisioning and fleet changes pause; it's HA and backed up, with a tested rebuild runbook
    3. CEverything stops until it's back
    4. DWe'd switch to manual kubectl
    Show answer

    B. Good designs make the blast radius of each failure explicit and small, and back it with evidence (tests, runbooks).

    From lesson 32 · Capstone: platform design review

16. Q16. Which is the best sign of a mature design?

    1. AIt uses the newest tools
    2. BIt states trade-offs and open risks honestly, with how each will be handled
    3. CIt has no risks
    4. DIt's longer than 50 pages
    Show answer

    B. Every design has trade-offs. Naming them, and explaining how they're managed, builds trust and makes the review productive.

    From lesson 32 · Capstone: platform design review