A 24×7 municipal payments microservice must keep a declared replica count and roll out image changes safely on OKE. Which Kubernetes object should the team kubectl apply as the everyday service controller?
Select an answer to reveal the explanation.
Short Explanation
For a long-running service, Deployment is the daily driver. It keeps the replica count, owns ReplicaSets, and rolls out Pod template changes. A lone Pod has no rollout brain for 24×7 care.
Full Explanation
A 24×7 municipal payments microservice that must keep a declared replica count and roll out image changes safely should be managed with a Deployment. The Deployment maintains replicas, owns ReplicaSets, and performs rolling updates when the Pod template changes—image, environment, probes, or volumes—which is the everyday service controller pattern on OKE for long-running APIs. A single naked Pod manifest has no replica controller and no rollout strategy; if it dies or you need N copies with controlled surge and unavailable limits, you babysit replacements by hand. A ConfigMap holds non-secret settings and never creates running replicas by itself no matter how you name or label the object. Ingress declares HTTP host and path routing; without a workload controller there are no application Pods to route to and nothing that keeps a desired count true overnight. Exam caveat: StatefulSets or Jobs fit other shapes (stable network identity and storage, or run-to-completion batches); for a stateless always-on payments API, Deployment remains the default exam and operational answer. Operational check: kubectl apply a Deployment, change the image in the Pod template, watch a rolling update across ReplicaSets, and confirm ready replicas stay at the declared count throughout the rollout.