A municipal HR app's Pods fail to start because the Deployment references a ConfigMap name that does not exist in the Namespace. What does that illustrate?
Select an answer to reveal the explanation.
Short Explanation
Point the app at a config locker that is not there and the movers stall—Pods that need that ConfigMap will not start clean. Fix the name or create the object.
Full Explanation
A municipal HR app whose Pods fail to start because the Deployment references a ConfigMap name that does not exist in the Namespace illustrates that wrong or missing ConfigMap or Secret references prevent Pods from starting correctly. kubelet must resolve projected configuration before containers run as intended; a missing ConfigMap or Secret commonly leaves Pods in CreateContainerConfigError or similar waiting states. For HR payroll and benefits workloads, a typo’d config reference is an outage until the object exists or the reference is fixed.
Wrong ConfigMap names are not ignored with Pods always becoming Ready anyway—the failure mode is exactly that readiness never arrives. Missing ConfigMaps do not automatically create empty PersistentVolumes as substitutes; storage claims are a different API. kube-scheduler does not rewrite all ConfigMap names to default when objects are absent; scheduling and config projection are separate stages.
Exam caveat: describe the Pod events and messages to spot missing config references quickly during troubleshooting questions. Operational check: kubectl describe pod for the HR workload, confirm the missing ConfigMap name, create or rename to match, and watch Pods progress to Running and Ready.