A 24/7 city website needs always-on replicas behind a Service with rolling updates. Which workload should the team choose?
Select an answer to reveal the explanation.
Short Explanation
A city website is a shop that must stay open—Deployments keep the desired number of cashiers (replicas) running and let you remodel (roll out) without locking the doors. Jobs and CronJobs are for tasks that finish, not storefronts.
Full Explanation
A 24/7 city website needs long-running replicas behind a Service with rolling updates. Choose a Deployment: it maintains a desired replica count, replaces failed Pods, and supports rolling (or recreate) strategies so the municipal homepage stays available while images change. Pair the Deployment with a Service selector on shared labels so traffic continues across Pod replacements.
A one-shot Job that exits after the first successful HTTP response is for finite batch work, not an always-on website. A CronJob that recreates the site every hour introduces downtime between schedules and is the wrong controller for continuous HTTP serving. A single bare Pod with restartPolicy Never lacks replica management, rollouts, and self-healing expected for production civic sites.
Exam caveat: CKAD workload selection hinges on lifetime and update needs—Deployments for stateless long-running apps, Jobs/CronJobs for finite or scheduled work, DaemonSets for per-node agents. Do not stretch Jobs into web servers.
Operational check: kubectl create deploy or apply a Deployment manifest, expose it with a Service, run kubectl rollout status, delete a Pod and confirm the ReplicaSet recreates it, and verify Endpoints list Ready addresses.