Cheat sheet & self-check

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

1. Q1. Why does a kubeadm cluster have a separate etcd CA?

   1. AFor speed
   2. BSo only holders of etcd-CA-signed certificates (API servers, etcd peers) can talk to etcd, not anything signed by the main cluster CA
   3. Cetcd requires RSA
   4. DIt's optional decoration
   Show answer

   B. Separate trust domains limit blast radius: a certificate issued for a user or kubelet by the cluster CA is useless against etcd.

   From lesson 01 · Cluster PKI & certificates

2. Q2. You add a new load-balancer DNS name, and kubectl complains 'x509: certificate is valid for …, not k8s-api.new.example.com'. Cause?

   1. AThe CA expired
   2. BThe API server certificate's SANs don't include the new name; it must be re-issued with the name added
   3. CDNS is wrong
   4. DRBAC denies access
   Show answer

   B. TLS clients check that the name they connected to appears in the certificate's Subject Alternative Names.

   From lesson 01 · Cluster PKI & certificates

3. Q3. What are sa.key and sa.pub used for?

   1. AHTTPS for the API server
   2. BSigning and verifying ServiceAccount tokens (JWTs)
   3. Cetcd encryption
   4. DSSH to nodes
   Show answer

   B. They're a key pair, not certificates: the API server signs ServiceAccount tokens with sa.key and verifies them with sa.pub.

   From lesson 01 · Cluster PKI & certificates

4. Q4. What happens if the API server's certificate expires?

   1. ANothing
   2. BClients (kubectl, kubelets, controllers) refuse the TLS connection, so the cluster stops being manageable and nodes go NotReady
   3. CPods are deleted
   4. Detcd stops
   Show answer

   B. Expired certificates break TLS everywhere at once. Monitor expiry and renew well before the date.

   From lesson 01 · Cluster PKI & certificates

5. Q5. What's the difference between an Issuer and a ClusterIssuer?

   1. AClusterIssuers are faster
   2. BAn Issuer works only in its own namespace; a ClusterIssuer can issue certificates for any namespace
   3. CIssuers are deprecated
   4. DClusterIssuers only do Let's Encrypt
   Show answer

   B. Use ClusterIssuers for shared, platform-wide CAs; namespaced Issuers when a team manages its own.

   From lesson 02 · cert-manager in production

6. Q6. You need a wildcard certificate (*.apps.example.com) from Let's Encrypt. Which challenge type?

   1. AHTTP-01
   2. BDNS-01
   3. CTLS-ALPN-01
   4. DNone, wildcards aren't possible
   Show answer

   B. Let's Encrypt issues wildcard certificates only via DNS-01, which proves control of the domain's DNS.

   From lesson 02 · cert-manager in production

7. Q7. Why test with the Let's Encrypt staging endpoint first?

   1. AIt's faster
   2. BProduction has strict rate limits; mistakes during setup can lock you out for a while, while staging has generous limits (but untrusted certificates)
   3. CStaging certificates are free
   4. DProduction requires payment
   Show answer

   B. Get the whole flow working on staging, then switch the issuer to production.

   From lesson 02 · cert-manager in production

8. Q8. In a client certificate, what does Kubernetes use as the username and groups?

   1. AThe serial number
   2. BThe Common Name (CN) is the username; Organization (O) entries are groups
   3. CThe issuer
   4. DThe file name
   Show answer

   B. CN=asha,O=devops authenticates as user 'asha' in group 'devops'. RBAC then decides what that identity may do.

   From lesson 03 · Authentication methods

9. Q9. Why are client certificates a poor choice for human users?

   1. AThey're slow
   2. BThey can't be revoked and usually live for a year, so a leaked or departed user's cert keeps working until it expires
   3. CThey don't support groups
   4. Dkubectl can't use them
   Show answer

   B. Kubernetes has no certificate revocation. Humans should authenticate through an identity provider (OIDC), where access can be removed instantly.

   From lesson 03 · Authentication methods

10. Q10. What's special about the ServiceAccount tokens mounted into pods today?

    1. AThey never expire
    2. BThey're projected, short-lived and bound to the pod (audience and lifetime), and the kubelet rotates them
    3. CThey're stored in etcd as Secrets
    4. DThey're X.509 certificates
    Show answer

    B. Bound tokens expire and become invalid when the pod is deleted, far safer than the old long-lived token Secrets.

    From lesson 03 · Authentication methods

11. Q11. Why use a username and group prefix such as 'oidc:'?

    1. AIt's required
    2. BSo IdP users and groups can't collide with built-in identities like system:masters or kubeadm:cluster-admins
    3. CIt shortens names
    4. DIt enables MFA
    Show answer

    B. Without a prefix, someone who can create a group called 'system:masters' in the IdP could gain cluster-admin. Prefixes keep namespaces apart.

    From lesson 04 · OIDC login for kubectl

12. Q12. Where does the user's password or MFA challenge happen in an OIDC login?

    1. AIn the API server
    2. BAt the identity provider, in the browser; Kubernetes only ever sees the signed token
    3. CIn kubectl's config file
    4. DIn etcd
    Show answer

    B. The API server never sees credentials. It only validates the token's signature, issuer, audience and expiry.

    From lesson 04 · OIDC login for kubectl

13. Q13. What does kubelogin do?

    1. AIt replaces RBAC
    2. BIt runs the browser login flow, caches and refreshes tokens, and hands the ID token to kubectl via the exec credential plugin
    3. CIt signs certificates
    4. DIt's an ingress controller
    Show answer

    B. kubectl calls kubelogin through the kubeconfig's exec section; kubelogin returns a fresh ID token each time it's needed.

    From lesson 04 · OIDC login for kubectl

14. Q14. Where should MFA be enforced for kubectl access?

    1. AIn each API server
    2. BAt the identity provider during login; the API server only accepts the resulting token
    3. CIn the kubeconfig file
    4. DIn RBAC
    Show answer

    B. Kubernetes has no MFA of its own. It trusts tokens from an IdP that has already enforced password + second factor (and possibly device and location policies).

    From lesson 05 · SSO, federation & MFA

15. Q15. What makes a good break-glass credential?

    1. AA cluster-admin cert on every admin's laptop
    2. BStored offline or in a vault with multi-person access, usage alerted in real time, and rotated after every use
    3. CA password in the wiki
    4. DThe IdP admin password
    Show answer

    B. Break-glass must work when SSO is down, but using it must be rare, visible and followed by rotation.

    From lesson 05 · SSO, federation & MFA

16. Q16. Why put an identity broker (e.g. Dex or Keycloak) between the enterprise IdP and many clusters?

    1. AIt's required by Kubernetes
    2. BOne integration with the IdP, consistent claims and groups for every cluster, and clusters don't each need IdP app registrations
    3. CIt stores kubeconfigs
    4. DIt replaces RBAC
    Show answer

    B. A broker normalises identities and reduces the number of trust relationships to manage.

    From lesson 05 · SSO, federation & MFA

17. Q17. Why is 'create pods' in a namespace close to admin in that namespace?

    1. AIt isn't
    2. BA pod can run as any ServiceAccount in the namespace and mount any Secret there, inheriting their permissions
    3. CPods get cluster-admin
    4. DIt allows deleting nodes
    Show answer

    B. Creating workloads lets you choose serviceAccountName and volumes. Treat workload-creation rights as access to everything that namespace's identities can do.

    From lesson 06 · RBAC design at scale

18. Q18. What does an aggregated ClusterRole do?

    1. AMerges clusters
    2. BAutomatically includes rules from other ClusterRoles that carry a matching label
    3. CDeletes duplicate roles
    4. DApplies to all namespaces
    Show answer

    B. Adding the label rbac.authorization.k8s.io/aggregate-to-edit: 'true' to a CRD's role extends the built-in edit role, so teams get access to new resources automatically.

    From lesson 06 · RBAC design at scale

19. Q19. Where should RoleBindings for teams be defined?

    1. ACreated by hand with kubectl
    2. BIn Git, applied by GitOps, reviewed like code
    3. CIn a spreadsheet
    4. DInside each pod
    Show answer

    B. Git gives review, history and drift correction: every access change has an author, a reviewer and a reason.

    From lesson 06 · RBAC design at scale