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
Pods that reference nonexistent ConfigMaps or Secrets (for required env or volume mounts) typically fail to create or start correctly until the referenced object exists with the expected keys. Kubernetes does not silently ignore required missing config, invent substitute PVs, or have the scheduler rewrite ConfigMap names.