Skip to content

Controller Manager: KCSA practice questions

The kube-controller-manager is a daemon that embeds the core control loops shipped with Kubernetes. A controller is a non-terminating loop that watches the shared state of the cluster through the API server and makes changes to move the current state toward the desired state, much as a thermostat switches heating on and off to reach a set temperature.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Controller Manager covers in KCSA

The kube-controller-manager is a daemon that embeds the core control loops shipped with Kubernetes. A controller is a non-terminating loop that watches the shared state of the cluster through the API server and makes changes to move the current state toward the desired state, much as a thermostat switches heating on and off to reach a set temperature. Kubernetes prefers many simple controllers to one large loop, so each can fail independently.

Controllers act through the API rather than directly. The Job controller is the standard example: it does not run any containers itself; it tells the API server to create or remove Pods, other components schedule and run them, and the controller marks the Job finished when the work is done. Because every built-in controller talks to the API server, the controller manager is itself an API client whose permissions matter.

The --controllers flag lists what runs. Its default of * enables every on-by-default controller, a name enables a specific one and -name disables it. The list includes, among many others, deployment-controller, replicaset-controller, statefulset-controller, daemonset-controller, job-controller, cronjob-controller, horizontal-pod-autoscaler-controller, endpointslice-controller, namespace-controller, node-lifecycle-controller, garbage-collector-controller, resourcequota-controller, serviceaccount-controller and serviceaccount-token-controller. bootstrap-signer-controller, token-cleaner-controller and selinux-warning-controller are disabled by default. Anything not in that list, such as the scheduler or kube-proxy, is a separate component.

Workload behavior follows from these loops. A ReplicaSet maintains a stable set of identical replica Pods; it uses its selector to find Pods to acquire and links them through metadata.ownerReferences, and it will adopt any matching Pod that has no controller owner, which is why bare Pods should not carry labels that match a ReplicaSet selector. Kubernetes recommends Deployments instead of using ReplicaSets directly: changing a Deployment's Pod template creates a new ReplicaSet and gradually shifts Pods to it, and each change records a revision. kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 changes only the image, kubectl scale deployment/nginx-deployment --replicas=10 changes the replica count, and kubectl rollout undo returns to the previous revision, or to a chosen one with --to-revision. A HorizontalPodAutoscaler updates a scalable workload such as a Deployment to match observed metrics like average CPU utilization.

Several controllers are security-relevant. The ServiceAccount controller ensures a ServiceAccount named default exists in every active namespace. The token controller maintains legacy Secret-based ServiceAccount tokens; it signs them with the private key given to the controller manager through --service-account-private-key-file, while the API server verifies them with the matching public key from --service-account-key-file. The legacy token cleaner checks every 24 hours for auto-generated legacy tokens that have not been used for a configurable period, one year by default, marks them invalid and later deletes them. Hardening options include --use-service-account-credentials, which gives each controller its own service account credentials so RBAC can scope them individually, and --profiling, which defaults to true. The controller manager serves HTTPS on --secure-port 10257 by default.

Key points

  • Built-in controllers run inside kube-controller-manager and act only through the API server.
  • --controllers=* enables all on-by-default controllers; -name disables one.
  • The scheduler and kube-proxy are separate components, not controllers in kube-controller-manager.
  • --use-service-account-credentials gives each controller its own credentials for least-privilege RBAC.
  • The ServiceAccount controller creates a default ServiceAccount in every active namespace.

Three sample questions

11 KCSA questions on Controller Manager, 11 with explanations. How practice works

Question 1

How can you update the container image of a Kubernetes deployment without modifying other deployment configurations?
  1. A.Manually edit the deployment YAML file and apply changes
  2. B.Delete the existing deployment and recreate it with the new image
  3. C.Use the 'kubectl set image' command to update the image
  4. D.Scale the deployment down to zero replicas, update the image, then scale back up
  5. E.Update the image directly in the container registry

Correct answer: C

The 'kubectl set image' command allows you to update the container image of a deployment directly without changing other configuration parameters. This command triggers a rolling update, ensuring minimal downtime. Manually editing the YAML is error-prone and may unintentionally alter other settings. Deleting and recreating the deployment causes downtime and loss of state. Scaling down to zero is unnecessary and disruptive. Updating the image in the container registry alone does not affect running deployments.

Sources: Kubernetes Official Documentation - Updating a Deployment, Kubernetes kubectl Cheat Sheet

Question 2

Which of the following controllers are included in the Kubernetes kube-controller-manager? (Select all that apply)

Select all that apply.

  1. A.Node Controller
  2. B.ReplicaSet Controller
  3. C.Ingress Controller
  4. D.Cloud Controller Manager
  5. E.Service Account Controller

Correct answers: A, B, E

The kube-controller-manager runs several core controllers including the Node Controller, which manages node status; the ReplicaSet Controller, which ensures the desired number of pod replicas; and the Service Account Controller, which manages service account tokens. The Ingress Controller is typically deployed separately as an add-on and is not part of the kube-controller-manager. The Cloud Controller Manager is a separate component responsible for cloud-specific control loops and is not included in the kube-controller-manager.

Sources: Kubernetes Official Documentation - Controller Manager, Kubernetes Official Documentation - Controllers

Question 3

What is the role of the Service Account Controller in Kubernetes?
  1. A.Manages the creation and lifecycle of service accounts and their associated authentication tokens
  2. B.Controls access permissions to external services from the cluster
  3. C.Assigns network policies to service accounts for traffic control
  4. D.Manages the lifecycle and scaling of Kubernetes services
  5. E.Handles automatic scaling of deployments based on load

Correct answer: A

The Service Account Controller, part of the kube-controller-manager, is responsible for creating service accounts and generating the associated authentication tokens used by pods to interact securely with the Kubernetes API. It does not control external service access, assign network policies, manage service lifecycles, or handle deployment scaling.

Sources: Kubernetes Official Documentation - Service Accounts, Kubernetes Controller Manager Overview

Practice this topic

Focus mode keeps every question on Controller Manager until you leave it. 10 free guest answers, then a free account; no credit card.

Or open KCSA practice across all topics.

Sources

The explanation above was checked against these official documents.