Workload Controllers

Workload Controllers Quiz

Quiz

Question 1 of 36 (0 answered)

Question 1

Why should you NOT create ReplicaSets directly in production?

ReplicaSets are deprecated and will be removed in future Kubernetes versions ReplicaSets don’t support rolling updates or rollbacks; Deployments provide these features ReplicaSets consume more resources than Deployments ReplicaSets can only manage one pod at a time

✓

Correct!

ReplicaSets DO provide self-healing and scaling by maintaining the desired replica count. However, they don’t support rolling updates (gradually replacing pods with new versions) or rollbacks (reverting to previous versions). Deployments layer these critical update strategies on top of ReplicaSets, making them essential for production workloads where you need to update applications safely without downtime.

✗

Incorrect

Think about what features you get with higher-level abstractions.

Question 2

Explain the three nested spec levels in a Deployment manifest and what each controls.

Three nested spec levels:

Deployment spec (top-level): Controls the Deployment lifecycle
- replicas: How many pods to maintain
- strategy: Update strategy (RollingUpdate, Recreate)
- selector: Which pods this Deployment manages
Pod template spec (under template.spec): Defines pod configuration
- volumes: Storage volumes
- restartPolicy: Container restart behavior
- securityContext: Pod-level security settings
Container spec (under template.spec.containers): Individual container settings
- image: Container image to run
- ports: Exposed ports
- resources: CPU/memory requests and limits
- probes: Liveness and readiness probes

Did you get it right?

✓

Correct!

✗

Incorrect

Question 3

During a rolling update with maxSurge: 1 and maxUnavailable: 0, which statements are TRUE?

At most 1 extra pod above the replica count can exist temporarily The minimum number of available pods never drops below the replica count Old pods are terminated before new pods are created New pods must pass readiness probes before old pods are terminated Both old and new ReplicaSets can have active pods simultaneously

✓

Correct!

maxSurge: 1 allows 1 extra pod temporarily. maxUnavailable: 0 ensures no pods go unavailable, maintaining full availability. New pods must be ready before old ones are removed. Both ReplicaSets exist during the update. Option 3 is false - new pods are created first.

✗

Incorrect

Think about zero-downtime deployments and readiness requirements.

Question 4

What happens when you apply this configuration to a Deployment currently running 3 replicas of nginx:1.21?

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
  template:
    spec:
      containers:
      - name: web
        image: nginx:1.22

What will this code output?

All 3 pods are terminated simultaneously and then recreated with nginx:1.22 1 old pod is terminated, then 1 new pod created; process repeats until all updated 1 new pod is created, then 1 old pod is terminated; process repeats The update fails because maxSurge and maxUnavailable cannot both be set

✓

Correct!

With maxSurge: 0 (no extra pods) and maxUnavailable: 1 (one can be down), Kubernetes terminates 1 old pod first, then creates 1 new pod with the updated image. This continues sequentially, causing brief moments with only 2 pods available.

✗

Incorrect

When maxSurge=0, no extra pods can be created above the replica count.

Question 5

The pod-template-hash label is manually added by users to track different versions of pods.

True False

✓

Correct!

False! The pod-template-hash label is automatically generated by the Deployment controller. It’s a hash of the pod template specification and is used to uniquely identify ReplicaSets and prevent selector conflicts during rolling updates.

✗

Incorrect

Think about who manages internal Kubernetes labels.

Question 6

The revisionHistoryLimit parameter controls how many old _____ are retained for rollback capability.

✓

Correct!

The revisionHistoryLimit (default: 10) specifies how many old ReplicaSets to keep. These scaled-to-zero ReplicaSets allow you to rollback to previous versions. Setting it to 0 would prevent rollbacks.

✗

Incorrect

What does a Deployment create to manage pods?

Question 7

You set minReadySeconds: 30 on a Deployment. A new pod passes its readiness probe at t=10s but crashes at t=25s. What happens?

The pod is considered available and the rolling update continues The rolling update pauses because the pod didn’t stay ready for 30 seconds The pod is immediately restarted and the rolling update continues The entire deployment is rolled back automatically

✓

Correct!

minReadySeconds requires a pod to stay ready for the specified duration before being considered available. If the pod crashes during this period, it’s NOT considered available, and the rolling update pauses to prevent rolling out a bad version.

✗

Incorrect

This parameter exists to prevent premature rollouts of unstable versions.

Question 8

Complete the Deployment strategy to achieve a blue-green deployment pattern (all new pods created before any old ones are terminated):

Fill in the maxSurge value for 3 replicas

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: _____
    maxUnavailable: 0

Your answer:

✓

Correct!

For blue-green deployment with 3 replicas, set maxSurge: 3 (or 100%) to allow all 3 new pods to be created alongside the 3 old pods. Combined with maxUnavailable: 0, this ensures all old pods remain until all new pods are ready.

✗

Incorrect

Blue-green means running both versions fully at the same time.

Question 9

Arrange the rolling update steps in the correct order:

Drag to sequence from first to last

⋮⋮ Create new ReplicaSet with updated pod template

⋮⋮ Scale up new ReplicaSet (controlled by maxSurge)

⋮⋮ Wait for new pods to pass readiness probe

⋮⋮ Scale down old ReplicaSet (controlled by maxUnavailable)

⋮⋮ Old ReplicaSet reaches zero pods

⋮⋮ Rolling update complete

✓

Correct!

Rolling updates follow this precise sequence: create new ReplicaSet → gradually scale up new pods → wait for readiness → gradually scale down old pods → complete when old ReplicaSet is at zero.

✗

Incorrect

Question 10

What is the primary difference between a Deployment and a StatefulSet?

Deployments can scale but StatefulSets cannot StatefulSets provide stable pod identities and persistent storage per pod; Deployments use random pod names and ephemeral storage StatefulSets are only for databases; Deployments are for web applications Deployments support rolling updates but StatefulSets do not

✓

Correct!

StatefulSets provide stable, ordered pod identities (app-0, app-1, app-2) and persistent storage per pod, making them suitable for stateful applications. Deployments use random pod names and are designed for stateless applications where pods are interchangeable.

✗

Incorrect

Think about what ‘stateful’ means - stable identity and persistent data.

Question 11

Which characteristics are true for StatefulSets?

Pod names follow a pattern: - Pods are created in parallel for faster deployment Each pod can have its own PersistentVolumeClaim Scaling down deletes pods in reverse order (highest ordinal first) Pods are interchangeable and can be replaced randomly

✓

Correct!

StatefulSets use ordered naming (app-0, app-1), sequential deployment/scaling, persistent storage per pod via volumeClaimTemplates, and reverse-order deletion. Pods are NOT interchangeable - each has a stable identity.

✗

Incorrect

StatefulSets are all about order and stability.

Question 12

A StatefulSet named database has 3 replicas. You scale it to 5 replicas. What happens?

kubectl scale statefulset database --replicas=5

What will this code output?

database-3 and database-4 are created in parallel immediately database-3 is created and must be Ready before database-4 starts All 5 pods are recreated from scratch in order The operation fails because StatefulSets cannot be scaled

✓

Correct!

StatefulSets scale sequentially. When scaling from 3 to 5, database-3 is created first. Only after it becomes Ready will database-4 be created. This ordered scaling ensures each pod is stable before proceeding.

✗

Incorrect

StatefulSets maintain strict ordering during scaling.

Question 13

A StatefulSet requires a _____ Service to provide stable DNS entries for each pod.

✓

Correct!

A Headless Service (with clusterIP: None) is required for StatefulSets. It creates DNS entries like <pod-name>.<service-name>.<namespace>.svc.cluster.local, providing stable network identities for each pod.

✗

Incorrect

This type of service has clusterIP set to None.

Question 14

Explain what volumeClaimTemplates in a StatefulSet do and how they differ from regular PersistentVolumeClaim.

volumeClaimTemplates:

Automatically creates a unique PersistentVolumeClaim for each pod in the StatefulSet
Each PVC is bound to a specific pod ordinal (e.g., data-mysql-0, data-mysql-1)
PVCs persist even if pods are deleted - when a pod is recreated, it reattaches to the same PVC
Scaling up creates new PVCs; scaling down does NOT delete PVCs (manual cleanup required)

vs. Regular PersistentVolumeClaim:

Regular PVC is manually created and all pods reference the same PVC by name
With ReadWriteOnce (RWO), only one pod can mount it at a time
With ReadWriteMany (RWX), all pods share the same storage (not isolated)
volumeClaimTemplates provide per-pod isolated persistent storage
Essential for stateful applications where each instance needs its own data

Did you get it right?

✓

Correct!

✗

Incorrect

Question 15

A DaemonSet is deployed to a cluster with 5 nodes. How many pods will be created?

1 pod total (DaemonSets only run a single pod) 5 pods (one per node) It depends on the replicas field in the DaemonSet spec 0 pods (DaemonSets need explicit nodeSelector to function)

✓

Correct!

DaemonSets automatically create one pod per node in the cluster. With 5 nodes, it creates 5 pods. There is no replicas field - the number of nodes determines the pod count. If a node is added, a new pod is automatically created on it.

✗

Incorrect

DaemonSets ensure cluster-wide coverage.

Question 16

DaemonSets respect node taints and will not schedule pods on tainted nodes unless the pod has matching tolerations.

True False

✓

Correct!

True! DaemonSets respect the same scheduling constraints as other workloads, including taints and tolerations. To run on tainted nodes (like master nodes), the DaemonSet pod template must include appropriate tolerations.

✗

Incorrect

Scheduling rules apply consistently across all workload types.

Question 17

What happens when you apply this DaemonSet to a cluster with 5 nodes, where 2 of them are labeled accelerator=nvidia?

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: gpu-plugin
spec:
  selector:
    matchLabels:
      app: gpu
  template:
    metadata:
      labels:
        app: gpu
    spec:
      nodeSelector:
        accelerator: nvidia
      containers:
      - name: plugin
        image: gpu-plugin:1.0

What will this code output?

5 pods are created (one per node) 2 pods are created (only on nodes with accelerator=nvidia label) 3 pods are created (one per worker node) 0 pods are created (nodeSelector conflicts with DaemonSet behavior)

✓

Correct!

The nodeSelector restricts the DaemonSet to only nodes with the accelerator=nvidia label. Even though there are 5 total nodes, only 2 match the selector, so only 2 pods are created.

✗

Incorrect

The nodeSelector restricts the DaemonSet to only nodes with the accelerator=nvidia label. Even though there are 5 total nodes, only 2 match the selector, so only 2 pods are created.

nodeSelector filters which nodes the DaemonSet runs on.

Question 18

What is the main difference between a Job and a Deployment?

Jobs cannot run multiple pods, Deployments can Jobs run pods to completion and then stop; Deployments keep pods running continuously Jobs are scheduled by CronJobs; Deployments are not Jobs support rolling updates; Deployments do not

✓

Correct!

Jobs are designed for finite tasks - they run pods to completion and track success/failure. Deployments keep pods running continuously and restart them if they exit. Jobs use restartPolicy: Never or OnFailure, while Deployments use Always.

✗

Incorrect

Think about the lifecycle: finite task vs. long-running service.

Question 19

Which fields control Job parallelism and completion behavior?

completions - Total number of successful pod completions required parallelism - Maximum number of pods running simultaneously replicas - Number of pods to maintain backoffLimit - Number of retries on failure ttlSecondsAfterFinished - Time to keep completed job before deletion

✓

Correct!

Jobs use completions (total pods needed), parallelism (concurrent pods), backoffLimit (retry count), and ttlSecondsAfterFinished (cleanup time). There is no replicas field - that’s for Deployments/ReplicaSets.

✗

Incorrect

Jobs have different terminology than continuous workloads.

Question 20

A Job is configured with completions: 10 and parallelism: 3. How does it execute?

spec:
  completions: 10
  parallelism: 3
  template:
    spec:
      containers:
      - name: worker
        image: processor:1.0
      restartPolicy: OnFailure

What will this code output?

All 10 pods start simultaneously 3 pods run at a time; after one completes, another starts until 10 total completions Only 3 pods run total, then the job completes The configuration is invalid (completions must equal parallelism)

✓

Correct!

The Job runs 3 pods in parallel (wave 1). As each completes successfully, a new pod starts. This continues until 10 total successful completions are achieved. Think of it as processing a queue with 3 workers.

✗

Incorrect

Think of parallelism as worker count and completions as total work items.

Question 21

In a Job spec, what restartPolicy values are allowed?

✓

Correct!

Jobs can only use restartPolicy: Never (don’t restart, create new pod on failure) or OnFailure (restart container on failure). The Always policy is NOT allowed for Jobs because they are meant to run to completion, not continuously.

✗

Incorrect

Jobs are finite tasks, not long-running services.

Question 22

Explain the three CronJob concurrencyPolicy options and when to use each.

CronJob concurrencyPolicy options:

Allow (default)
- Multiple job instances can run simultaneously
- Use when: Jobs are independent and can overlap safely
- Example: Hourly log analysis where overlapping is fine
Forbid
- Skip the new job if the previous one hasn’t finished
- Use when: Jobs must not overlap (e.g., exclusive resource access)
- Example: Database backup that locks tables
Replace
- Cancel the running job and start the new one
- Use when: Only the latest execution matters
- Example: Generating a “current status” report where old jobs are obsolete

Did you get it right?

✓

Correct!

✗

Incorrect

Question 23

Complete the CronJob schedule to run every day at 2:30 AM:

Fill in the cron expression

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-backup
spec:
  schedule: "_____"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: backup:1.0

Your answer:

✓

Correct!

Cron format: minute hour day month day-of-week. For 2:30 AM daily: 30 (minute) 2 (hour) * (any day) * (any month) * (any day of week) = 30 2 * * *.

✗

Incorrect

Cron format: minute hour day month day-of-week. For 2:30 AM daily: 30 (minute) 2 (hour) * (any day) * (any month) * (any day of week) = 30 2 * * *.

Format: minute hour day month day-of-week

Question 24

Arrange these CronJob schedules from MOST frequent to LEAST frequent:

Order from most frequent (top) to least frequent (bottom)

⋮⋮ 0 0 1 * *

⋮⋮ */5 * * * *

⋮⋮ 0 9 * * 1-5

⋮⋮ 0 * * * *

✓

Correct!

Frequency order: Every 5 minutes (288/day) → Every hour (24/day) → Weekdays at 9 AM (5/week) → First of month (12/year). Remember: smaller time units = higher frequency.

✗

Incorrect

Frequency order: Every 5 minutes (288/day) → Every hour (24/day) → Weekdays at 9 AM (5/week) → First of month (12/year). Remember: smaller time units = higher frequency.

Question 25

When you delete a StatefulSet with default settings, all associated PersistentVolumeClaims are automatically deleted.

True False

✓

Correct!

False! By default, PVCs created by a StatefulSet’s volumeClaimTemplates are NOT automatically deleted when the StatefulSet is deleted. This prevents accidental data loss. You must manually delete PVCs if needed.

✗

Incorrect

Kubernetes errs on the side of data safety.

Question 26

You have a Deployment with 5 replicas and want to temporarily stop it without losing its configuration. What should you do?

Delete the Deployment Scale it to 0 replicas Pause the rollout with kubectl rollout pause Set suspend: true in the spec

✓

Correct!

Scaling to 0 replicas (kubectl scale deploy <name> --replicas=0) stops all pods while preserving the Deployment configuration. You can later scale back up. rollout pause stops updates but doesn’t stop pods. suspend is for CronJobs, not Deployments.

✗

Incorrect

Think about how to maintain 0 pods while keeping the resource.

Question 27

Which workload controllers create pods that run continuously (not to completion)?

Deployment Job StatefulSet CronJob DaemonSet

✓

Correct!

Deployments, StatefulSets, and DaemonSets create long-running pods that restart if they exit (restartPolicy: Always). Jobs and CronJobs create pods that run to completion with restartPolicy: Never or OnFailure.

✗

Incorrect

Which controllers are for services vs. batch tasks?

Question 28

What is the result of this rollback command when the current revision is 5?

kubectl rollout undo deployment web-app --to-revision=3

What will this code output?

The Deployment rolls back to revision 4 (previous revision) The Deployment rolls back to revision 3 (specific version) The Deployment rolls forward to revision 6 The command fails (can only rollback to previous revision)

✓

Correct!

The --to-revision=3 flag explicitly rolls back to revision 3, regardless of the current revision. Without this flag, kubectl rollout undo would rollback to the immediate previous revision (4 in this case).

✗

Incorrect

The –to-revision flag allows targeting specific revisions.

Question 29

What happens to the old ReplicaSet after a successful rolling update?

It is immediately deleted It is scaled to 0 replicas but retained for rollback capability It is converted into a backup Deployment It continues running with 1 replica for redundancy

✓

Correct!

After a successful rolling update, the old ReplicaSet is scaled to 0 replicas but NOT deleted. It’s retained (up to revisionHistoryLimit count) to enable rollbacks. This allows quick restoration to previous versions.

✗

Incorrect

Think about how rollbacks work without re-downloading images.

Question 30

The progressDeadlineSeconds parameter sets a timeout for deployment progress. The default value is _____ seconds.

✓

Correct!

The default progressDeadlineSeconds is 600 seconds (10 minutes). If a deployment doesn’t make progress within this time (new pod ready, old pod terminated, or status change), it’s marked as failed.

✗

Incorrect

It’s 10 minutes expressed in seconds.

Question 31

A DaemonSet can be configured with rolling update strategy similar to Deployments.

True False

✓

Correct!

True! DaemonSets support rolling updates controlled by updateStrategy.type: RollingUpdate and updateStrategy.rollingUpdate.maxUnavailable, which specifies how many nodes can update simultaneously. However, unlike Deployments, DaemonSets don’t support canary deployments.

✗

Incorrect

Most Kubernetes resources support gradual updates.

Question 32

In the context of Deployments, what does the selector field do?

It selects which nodes the pods should run on It selects which pods this Deployment manages based on their labels It selects which container image to use It selects the update strategy for rolling updates

✓

Correct!

The selector field uses label matching to identify which pods the Deployment manages. It must match the labels in template.metadata.labels. This allows the Deployment controller to track and manage the correct pods.

✗

Incorrect

Selectors are about identifying resources, not placement.

Question 33

Compare the use cases for Deployment vs. StatefulSet vs. DaemonSet. When would you use each?

Deployment:

Use for: Stateless applications (web apps, APIs, microservices)
Characteristics: Pods are interchangeable, ephemeral storage, parallel deployment
Example: REST API server, web frontend, stateless processing service

StatefulSet:

Use for: Stateful applications requiring stable identity and stable storage
Characteristics: Ordered pods, stable network IDs, stable per-pod storage (each pod always reattaches to its specific PVC)
Example: Databases (MySQL, PostgreSQL), message brokers (Kafka, RabbitMQ), distributed systems (Zookeeper, etcd)

DaemonSet:

Use for: Cluster-wide services that must run on every node (or selected nodes)
Characteristics: One pod per node, automatic scaling with cluster
Example: Log collectors (Fluentd), monitoring agents (Prometheus Node Exporter), network plugins (Calico), storage daemons

Did you get it right?

✓

Correct!

✗

Incorrect

Question 34

A Job has backoffLimit: 3. The pod fails 4 times. What happens?

spec:
  backoffLimit: 3
  template:
    spec:
      containers:
      - name: worker
        image: processor:1.0
      restartPolicy: Never

What will this code output?

The Job keeps retrying indefinitely The Job is marked as failed after 3 retries (4 total attempts) The Job succeeds after 4 attempts The Job is immediately deleted

✓

Correct!

backoffLimit: 3 means the Job will retry up to 3 times after the initial failure. After 4 total attempts (1 initial + 3 retries) all fail, the Job is marked as Failed and stops creating new pods.

✗

Incorrect

backoffLimit: 3 means the Job will retry up to 3 times after the initial failure. After 4 total attempts (1 initial + 3 retries) all fail, the Job is marked as Failed and stops creating new pods.

backoffLimit is the number of RETRIES, not total attempts.

Question 35

Which parameters affect how long a Deployment takes to complete a rolling update?

minReadySeconds - Adds wait time after each pod becomes ready progressDeadlineSeconds - Maximum time allowed for the entire update maxSurge - Controls how many pods can be created at once maxUnavailable - Controls how many pods can be terminated at once revisionHistoryLimit - Number of old ReplicaSets to keep

✓

Correct!

Update duration is affected by: minReadySeconds (stability wait), progressDeadlineSeconds (timeout), maxSurge (creation rate), and maxUnavailable (termination rate). revisionHistoryLimit only affects cleanup, not update speed.

✗

Incorrect

Think about factors that control the pace and timing of updates.

Question 36

Explain the functional purpose of each workload controller. What problem does each solve?

ReplicaSet: Maintains pod count and self-healing (but no update strategy)

Deployment: Provides rolling updates, rollbacks, and zero-downtime deployments

StatefulSet: Manages stateful apps with stable identity, ordered deployment, and stable storage bindings

DaemonSet: Ensures node-level coverage for cluster-wide services

Did you get it right?

✓

Correct!

✗

Incorrect

Quiz Results

Score

0/0

Accuracy

Right

Wrong

Skipped

Last updated on March 15, 2026

Pod Lifecycle Services