Cluster Architecture, Installation and Configuration — CKA practice questions

A Role grants get/list/watch on pods in namespace dev. To let user alice use it, you create:

1. A ClusterRoleBinding whose roleRef points at that namespaced Role object
2. A RoleBinding in dev with subject User alice and roleRef to that Role
3. A ServiceAccount named alice in dev, which inherits the Role's verbs
4. A ClusterRole named alice that duplicates the same get/list/watch verbs

Answer: B — A RoleBinding in dev with subject User alice and roleRef to that Role

B is right: a Role is namespaced and is bound by a RoleBinding in the same namespace, with subjects listing kind User and name alice. A is not merely over-broad, it is invalid - a ClusterRoleBinding can only reference a ClusterRole. C confuses identities: a ServiceAccount is a workload identity and grants nothing without a binding. D creates a permission object with no subject attached, so alice still has no access.

Which is the BEST description of etcd in a Kubernetes cluster?

1. Distributed key-value store holding all cluster state for the whole control plane
2. The component that filters and scores nodes to place pending pods, which is kube-scheduler
3. The container runtime that pulls images and starts containers on each node through the CRI
4. A service mesh sidecar layer providing mTLS and traffic shifting between application pods
5. The image registry that stores and serves container images pulled by nodes at pod startup

Answer: A — Distributed key-value store holding all cluster state for the whole control plane

A is the answer: etcd is a Raft-consensus key-value store, and every object the API server serves is persisted there — losing it without a snapshot loses the cluster, which is why etcdctl snapshot save is a CKA skill. B describes kube-scheduler. C describes containerd or another CRI runtime. D is an add-on Kubernetes does not ship. E is an external registry, not a control-plane component.

A worker node must join an existing cluster, but the admin has lost the original join command output. What is the BEST way to regenerate a usable join command?

1. Run `kubeadm token create --print-join-command` on a control-plane node
2. Copy /etc/kubernetes/admin.conf to the worker and run `kubeadm init --skip-phases`
3. Recreate the whole cluster with `kubeadm init` so a fresh bootstrap token is printed
4. Run `kubeadm join --discovery-file` with the worker's own kubelet client certificate

Answer: A — Run `kubeadm token create --print-join-command` on a control-plane node

A) Correct — this mints a new bootstrap token and prints the full join line, including the CA cert hash. B) tempts because admin.conf does authenticate to the API, but copying cluster-admin credentials to a worker is not a join mechanism and `kubeadm init` is for control planes. C) is destructive overkill for a recoverable token. D) inverts the trust flow: the worker has no valid client certificate before it joins; the certificate is what joining obtains.

Two kube-controller-manager replicas run in an HA cluster. What prevents them from both acting on the same objects?

1. The API server rejects duplicate writes using optimistic concurrency alone
2. A leader election lease means only the current leader runs the control loops
3. Each replica is sharded by namespace at startup by kubeadm configuration
4. The scheduler assigns each controller manager a disjoint set of resource kinds

Answer: B — A leader election lease means only the current leader runs the control loops

B) Correct — the controller manager and scheduler use a Lease object for leader election, so standby replicas idle until the lease is lost. A) is partially true as a safety net, since resourceVersion conflicts do reject stale writes, but it is not the mechanism that prevents duplicate control loops. C) invents namespace sharding. D) misassigns work to the scheduler, which places pods and has no role in dividing controller responsibilities.

What is kubeadm used for?

1. Bootstrapping conformant clusters with 'init', 'join', 'upgrade', 'reset'
2. Provisioning cloud VMs and load balancers before any Kubernetes install
3. Building and pushing container images from a Containerfile to a registry
4. Collecting cluster metrics and serving them to the horizontal autoscaler
5. Serving a browser dashboard for viewing workloads and node conditions

Answer: A — Bootstrapping conformant clusters with 'init', 'join', 'upgrade', 'reset'

A is right: kubeadm bootstraps and maintains the cluster lifecycle - 'kubeadm init' brings up the control plane, 'kubeadm join' adds nodes, 'kubeadm upgrade plan/apply' drives version upgrades, and 'kubeadm reset' tears a node down. B is infrastructure provisioning, which kubeadm deliberately leaves to Terraform, kops, kubespray or a cloud provider. C is an image build tool such as buildah or kaniko; kubeadm never touches images. D describes metrics-server, the component the HPA reads through metrics.k8s.io. E describes an add-on dashboard, installed separately after the cluster exists.

A pod object exists with `spec.nodeName` empty and status Pending, and cluster events are silent. Which component's failure BEST explains the symptom?

1. kube-proxy has stopped programming Service rules on every node
2. kube-controller-manager has lost its leader election lease
3. The container runtime on every worker is refusing to pull images
4. kube-scheduler is not running, so no binding decision is ever made

Answer: D — kube-scheduler is not running, so no binding decision is ever made

D) Correct — an unbound pod with no scheduling events points at the scheduler, which is the only component that writes the binding. A) affects Service traffic, not pod placement, and the pod would already be running. B) would stop new pods being created at all rather than leaving created pods unscheduled. C) would give the pod a node and then ImagePullBackOff, not an empty nodeName.

Which components make up Kubernetes RBAC?

1. Only user objects, which the API server stores and authenticates with static tokens
2. Only Role objects, whose permissions apply to every authenticated subject by default
3. Role or ClusterRole defining verbs on resources, bound to subjects by the two bindings
4. Only bindings, which name both the permitted verbs and the subjects that receive them
5. The cloud provider's IAM, which the API server consults on every authorization check

Answer: C — Role or ClusterRole defining verbs on resources, bound to subjects by the two bindings

C is the answer: the rules live in a Role or ClusterRole, and a RoleBinding or ClusterRoleBinding attaches them to users, groups or ServiceAccounts — a RoleBinding may also reference a ClusterRole to reuse one rule set per namespace. B is wrong because a Role grants nothing until it is bound, and D is wrong because a binding carries no rules of its own. A is wrong because Kubernetes has no User object. E describes cloud IAM, which sits outside API authorization.

A Namespace in Kubernetes provides:

1. Logical scoping of resources for RBAC and quota, not hard isolation between tenants
2. Complete isolation, so pods in different namespaces cannot reach each other at all
3. Physical separation of workloads onto distinct node pools, one pool per namespace
4. A separate cluster with its own API server and etcd, joined to the parent cluster
5. Isolation of storage only, so PersistentVolumes are scoped to a single namespace

Answer: A — Logical scoping of resources for RBAC and quota, not hard isolation between tenants

A is the answer: namespaces scope names, RBAC and ResourceQuota, and the built-in ones are default, kube-system, kube-public and kube-node-lease. B is the tempting overstatement: pods in different namespaces can reach each other freely until a NetworkPolicy says otherwise. C is wrong because nothing about namespaces implies node placement. D is a separate cluster. E is wrong because PersistentVolumes are cluster-scoped while PVCs are namespaced.

A node must be taken out of service permanently. Which sequence is correct?

1. Delete the node object, then drain it, then run `kubeadm reset` on the host
2. Cordon the node, delete the node object, then drain the workloads off it
3. Drain the node, delete the node object, then run `kubeadm reset` on it
4. Run `kubeadm reset` first, then drain the node so pods reschedule cleanly

Answer: C — Drain the node, delete the node object, then run `kubeadm reset` on it

C) Correct — evacuate workloads first, remove the node from the API, then clean the host's cluster state. A) and B) both delete the node object before evacuating, so pods are removed abruptly rather than evicted gracefully. D) tears down the kubelet and runtime while pods are still expected to be running there, so the drain has nothing functional to work with.

A cluster's API server is at v1.35. Which kubelet version on a worker node is OUTSIDE the supported version skew?

1. v1.35, exactly matching the API server
2. v1.34, one minor version behind
3. v1.33, two minor versions behind
4. v1.36, one minor version ahead

Answer: D — v1.36, one minor version ahead

D) Correct — kubelets may lag the API server by a bounded number of minor versions but must never run ahead of it. A) is trivially supported. B) is supported and is the normal state mid-upgrade. C) is supported under the current skew policy, which allows kubelets several minors behind the API server. D) is the one direction the policy forbids, which is why the control plane is always upgraded first.

Operators?

Application-specific controllers for managing apps. Kubernetes-native.

What is the correct order of operations for upgrading a kubeadm control-plane node?

Upgrade the kubeadm binary from the package repo, run 'kubeadm upgrade plan', run 'kubeadm upgrade apply v<version>', then drain the node, upgrade the kubelet and kubectl packages, restart the kubelet, and uncordon the node.

CKA prerequisite?

None official, but 6+ months hands-on experience strongly recommended.

Static pods?

Managed by kubelet (not control plane). YAML in /etc/kubernetes/manifests/.