A developer proposes packing a second unrelated business microservice into the same Pod “for locality.” What is the sound CKAD-oriented guidance?
Select an answer to reveal the explanation.
Short Explanation
Roommates should share chores, not run two different businesses out of one bedroom. Sidecars and inits are helpers; separate products get separate Deployments and Services.
Full Explanation
When a developer proposes packing a second unrelated business microservice into the same Pod “for locality,” sound CKAD-oriented guidance is to prefer separate Deployments and Services unless a true helper pattern (sidecar or init) applies. Unrelated services have different scaling needs, release cadences, and failure domains. Co-locating them forces identical replica counts and couples outages—poor practice for independent municipal APIs that should fail and ship independently.
Always merging microservices into one Pod to guarantee identical replica counts is an anti-goal for most city platforms. The claim that unrelated services must share one Pod so they can use different ServiceAccounts is backwards: containers in a Pod share the Pod-level ServiceAccount. Combining them only if both are CronJobs with identical schedules still ignores separation of concerns and workload fit.
Exam caveat: Multi-container Pods exist for tightly coupled helpers—log shippers, proxies, metrics adapters, schema init—not for stuffing two business microservices together to save DNS lookups.
Operational check: model each service as its own Deployment and Service; scale one without the other; verify independent rollouts with kubectl rollout status on each Deployment; confirm separate Service Endpoints.