Desired state vs actual state reconciliation in Kubernetes - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the main purpose of Kubernetes' reconciliation loop?

Kubernetes uses a reconciliation loop to manage resources. What does this loop do?

A It only creates resources once and never checks their status again.

B It continuously compares the desired state with the actual state and makes changes to match them.

C It deletes all resources periodically to free up space.

D It manually requires users to update resource states through commands.

💡 Hint

Think about how Kubernetes keeps your apps running as you want.

The reconciliation loop ensures the cluster matches the desired state by detecting differences and fixing them automatically.

💻 Command Output

intermediate

What is the output of 'kubectl get pods' after deleting a pod manually?

You manually delete a pod that is part of a Deployment. What will 'kubectl get pods' show shortly after?

Kubernetes

kubectl delete pod <pod-name>
kubectl get pods

A The deleted pod remains in the list with status 'Terminating' forever.

B No pods are running because the deleted pod is gone.

C A new pod with a different name is created to replace the deleted one.

D An error message saying pods cannot be deleted manually.

💡 Hint

Think about how Deployments maintain the number of pods.

Deployments ensure the desired number of pods. When one is deleted, the controller creates a new pod to replace it.

❓ Configuration

advanced

Which YAML snippet correctly defines a desired state for a Deployment with 3 replicas?

Choose the YAML snippet that correctly sets a Deployment to have 3 replicas of an nginx container.

A

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

B

apiVersion: v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

C

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 'three'
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

D

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest

💡 Hint

Check apiVersion, kind, and selector format carefully.

Option A uses correct apiVersion, kind, replicas as integer, and proper selector.matchLabels format required for Deployment.

❓ Troubleshoot

advanced

Why does a Deployment never reach the desired number of ready pods?

You set replicas: 5 in your Deployment, but 'kubectl get pods' shows only 3 pods running and ready. What could cause this?

A The pod template has an invalid image name causing pods to crash on start.

B The Deployment controller does not support more than 3 replicas.

C The cluster has no nodes available to schedule pods.

D The Deployment spec is missing the replicas field.

💡 Hint

Check pod status and events for crash loops.

If pods crash due to invalid images, Kubernetes keeps trying but pods never become ready, so desired count is not met.

🔀 Workflow

expert

What is the correct sequence of steps Kubernetes takes to reconcile a changed Deployment manifest?

Put these steps in the order Kubernetes performs them when you update a Deployment manifest to change replicas from 2 to 4.

A 1,3,2,4

B 2,1,3,4

C 3,1,2,4

D 1,2,3,4

💡 Hint

Think about how the update flows from manifest to running pods.

The API server first receives the change, then the controller compares states, creates pods, and finally pods run on nodes.