A legacy case-management component needs stable per-instance network identity and durable storage attachment as replicas come and go. Which workload contrast is most accurate at selection time?
Select an answer to reveal the explanation.
Short Explanation
Stateless web replicas are interchangeable jerseys; some legacy data companions want a locker with their number on it. StatefulSets give stable names and storage hooks—Deployments treat Pods as replaceable clones.
Full Explanation
A legacy case-management component that needs stable per-instance network identity and durable storage attachment as replicas come and go is a classic StatefulSet-shaped workload. StatefulSets provide stable hostnames, ordinal identity, and volumeClaimTemplates so each instance remounts its own data—more appropriate than a typical stateless Deployment when each municipal case shard must be addressed individually and keep its disk.
Preferring a CronJob because schedules create stronger network identities than StatefulSets is incorrect; CronJobs create finite Jobs. A Deployment does not assign fixed hostnames equal to the Deployment name plus ordinal indexes by default. Claiming a bare Pod is required because only unmanaged Pods can mount PersistentVolumeClaims is false—Deployments and StatefulSets both mount PVCs, with StatefulSets better matching identityful storage.
Exam caveat: CKAD may test contrast-level StatefulSet understanding even when deep storage provisioning is admin-scoped. Prefer Deployment for stateless APIs; StatefulSet when stable identity and per-pod storage matter.
Operational check: kubectl get sts,pvc; resolve pod-0.<service> DNS; delete pod-0 and confirm it returns with the same name and reattaches its claim; compare with a Deployment Pod that gets a new name on recreate.