A 311 API has one shared base of manifests and needs different settings for staging versus production. Which Kustomize layout matches that goal?
Select an answer to reveal the explanation.
Short Explanation
Picture a city seal stamp (the base) and colored overlays for each district. Staging and prod stamp the same forms, then tint them—Kustomize base plus overlays do that without photocopying the whole binder twice.
Full Explanation
A 311 API with one shared base of manifests and different settings for staging versus production matches the classic Kustomize layout: a common base directory plus per-environment overlay directories that reference the base. Overlays patch replicas, images, and namespaces while the base stays DRY—ideal for municipal teams managing the same API across environments without copy-paste sprawl.
Why the other options fail by concept: Duplicating the entire base YAML tree into unrelated folders with no kustomization linkage invites drift. Storing only a Helm values.yaml and refusing Kustomize is a different toolchain choice, not a Kustomize layout for this goal. Putting every environment’s live etcd dump into a ConfigMap is not a maintainable source of truth for manifests.
Exam caveat: Overlays should reference the base via resources: (for example ../base), not rely on implicit parent magic. Keep secrets out of plain base YAML—use generators or external secret systems appropriate to city policy. Avoid environment-specific logic leaking into base; put differences in overlays.
Operational check: Tree the repo as base/ plus overlays/staging and overlays/production, run kubectl kustomize on each overlay, and diff renders to confirm shared objects plus intended env deltas before kubectl apply -k.