Access Control CKS Practice Questions (Page 1)

Questions 1–5

1. 1foundation · easy

   What is the purpose of setting automountServiceAccountToken: false on a service account?

   • ATo prevent Pods using that service account from automatically mounting the service account token.
   • BTo disable the service account entirely so it cannot be used.
   • CTo make the service account token expire immediately.
   • DTo prevent the service account from being bound to any Role.
   Reveal Solution Discussion Select an answer first
2. 2foundation · easy

   Why is it important to secure kubeconfig files?

   • AThey contain the API server's private key.
   • BThey contain the cluster's secret encryption keys.
   • CThey are required to be world-readable for kubectl to work.
   • DThey contain credentials that can be used to authenticate to the API server.
   Reveal Solution Discussion Select an answer first
4. 3foundation · easy

   Which feature allows you to issue short-lived tokens for service accounts?

   • ARBAC authorization
   • BKubelet certificate rotation
   • CTokenRequest API
   • DServiceAccount secrets
   Reveal Solution Discussion Select an answer first
5. 4expert · hard

   A Pod in the 'worker' namespace needs to authenticate to the Kubernetes API to list its own Pod. You want to minimize the risk of token theft. The Pod is long-running. Which configuration is most secure?

   • ACreate a new ServiceAccount for the Pod with a Role that only allows listing Pods in the 'worker' namespace.
   • BSet automountServiceAccountToken: false on the Pod and manually mount a token from a Secret.
   • CUse a projected service account token with a short expiration time (e.g., 1 hour) and an audience of 'kubernetes.default.svc'.
   • DUse the default ServiceAccount token, which is long-lived, and rely on RBAC to limit permissions.
   Reveal Solution Discussion Select an answer first
6. 5foundation · easy

   A Pod needs to list Secrets in the 'database' namespace. What is the best practice for granting this permission?

   • AUse the default service account and grant it a ClusterRole with full access to Secrets.
   • BCreate a service account and bind it to a ClusterRole with 'get' and 'list' permissions on Secrets in all namespaces.
   • CUse the default service account and rely on the namespace's default permissions.
   • DCreate a dedicated service account, bind it to a Role with 'get' and 'list' permissions on Secrets in that namespace, and use that service account in the Pod.
   Reveal Solution Discussion Select an answer first