A developer needs a ConfigMap holding a non-sensitive database host for a city permits app using kubectl. Which approach correctly creates that configuration object?
Select an answer to reveal the explanation.
Short Explanation
ConfigMaps are the labeled cubbies for plain settings like a DB hostname. kubectl create configmap --from-literal fills a cubby without pretending the value is a Secret. expose and raw Pod env alone are different tools.
Full Explanation
A developer who needs a ConfigMap holding a non-sensitive database host for a city permits app should run kubectl create configmap permits-db --from-literal=host=db.permits.svc, or apply an equivalent ConfigMap manifest. That creates a first-class ConfigMap API object the Deployment can consume via environment variables or volume mounts without misusing Secrets for non-sensitive hostnames.
Using kubectl create secret generic for the host so ConfigMaps stay empty misclassifies non-sensitive DNS names as Secret material and fails the requirement to create a ConfigMap. Applying a Pod that embeds the host only in an env value without any ConfigMap API object fails to create the requested configuration object. kubectl expose deployment creating a Service does not auto-create a ConfigMap named permits-db for database host configuration.
Exam caveat: prefer Secrets for credentials and ConfigMaps for non-sensitive config; never place database passwords in ConfigMaps even when create would succeed. Operational check: create the ConfigMap, inspect it with kubectl get configmap permits-db -o yaml, reference it from the permits Deployment, and confirm the application resolves the database host.