Courseiva
Kubernetes Fundamentals →hardMultiple Select

KCNA Kubernetes Fundamentals Practice Question

Which two scenarios would benefit from using a StatefulSet instead of a Deployment? (Choose two.)

⚠ Common exam trap

Candidates often confuse the need for stable network identities (StatefulSet) with the ability to run on any node (Deployment), or mistakenly think batch jobs fit into StatefulSets because they involve 'state' like logs.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

An application that requires persistent storage unique to each instance

Option A is correct because a StatefulSet provides each Pod with a stable, unique identity and its own PersistentVolumeClaim via volumeClaimTemplates, so each replica keeps dedicated persistent storage that survives rescheduling — something a Deployment cannot guarantee since its Pods share no ordinal-based PVC binding. Option B is correct because StatefulSet Pods get predictable, stable DNS names through a headless Service (e.g., pod-0.svc.namespace.svc.cluster.local), which database clusters such as MySQL, PostgreSQL, or etcd need for peer discovery and quorum. Option C is wrong because run-once batch workloads are better handled by a Job (or CronJob), not a StatefulSet or Deployment. Option D is wrong because stateless horizontally scalable web apps are the canonical use case for a Deployment, which offers rolling updates and replica management without per-Pod identity. Option E is wrong because node-agnostic microservices are stateless by nature and gain nothing from StatefulSet's stable identity or storage guarantees.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    An application that requires persistent storage unique to each instance

    Why this is correct

    StatefulSet assigns each replica a stable, ordinal identity and its own PersistentVolumeClaim via volumeClaimTemplates, so storage survives rescheduling and remains bound to that pod. A Deployment's replicas share no such per-instance identity, making it unsuitable when each instance needs persistent storage unique to itself.

  • ✓

    A database cluster that requires stable network identities

    Why this is correct

    StatefulSets assign each pod a stable, ordinal hostname via a headless Service, so cluster members keep predictable DNS names across restarts and rescheduling. A Deployment's pods receive random names and shared load-balanced addressing, which breaks peer discovery and replication. This satisfies the database cluster's requirement for stable network identities.

  • ✗

    A batch job that runs once and exits

    Why it's wrong here

    Batch jobs require a finite execution lifecycle where pods terminate upon completion, whereas StatefulSets maintain stable network identities and persistent storage bindings for long-running, stateful instances. This scenario is tempting because both manage workloads on Kubernetes; however, Jobs are the correct mechanism for one-off tasks that exit, while StatefulSets provide the ordinal index and persistent volume retention required by distributed databases.

  • ✗

    A stateless web application that can scale horizontally

    Why it's wrong here

    A stateless web application scales horizontally by adding replicas with no need for stable network identities or persistent storage per instance, which a Deployment handles through its default replica management. StatefulSet is tempting because it is designed for workloads requiring ordered startup, unique network identifiers, and persistent volumes—scenarios like databases or message queues where each pod must maintain its own state across rescheduling.

  • ✗

    A microservice that can use any available node

    Why it's wrong here

    Scheduling across any available node is exactly what a Deployment provides, since pods are interchangeable and stateless. StatefulSets are for workloads needing stable network identities and persistent per-pod storage, such as databases or clustered systems with ordered startup and durable volume claims.

Visual reference

Client DHCP Server 1 Discover (broadcast) 2 Offer (IP: 192.168.1.10) 3 Request (I accept) 4 Acknowledge (lease confirmed) DORA — the four-step DHCP lease process

About these practice questions

This KCNA question is part of Courseiva's 930-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This KCNA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the KCNA exam.