A staging overlay directory must reuse the shared base manifests. How should its kustomization.yaml wire that relationship?
Select an answer to reveal the explanation.
Short Explanation
Overlays “point upstairs” to the base like a district office citing citywide forms. resources: [../base] pulls that shared set in, then the overlay’s patches and transformers customize it.
Full Explanation
A staging overlay directory reuses shared base manifests by listing the base path (for example ../base) under resources: in its kustomization.yaml so the overlay build includes and then patches the base. That explicit wiring is how municipal overlays compose on a shared foundation rather than hoping kubectl searches parent folders magically.
Why the other options fail by concept: Omitting any base reference and relying on kubectl to search parent folders automatically is not how Kustomize composition works. Pointing replicas: at a filesystem path is invalid—replicas targets workload names. Setting namespace: to a filesystem path does not import the base.
Exam caveat: Relative paths depend on the overlay’s location; broken relative links are a common CI failure. Prefer consistent repo layout (base/, overlays/*). resources: can include multiple bases carefully, but keep graphs understandable for city platform teams.
Operational check: In overlays/staging/kustomization.yaml set resources: [../../base] (or the correct relative path), kubectl kustomize overlays/staging, and confirm base objects appear plus staging patches. Break the path on purpose once to recognize the error signature.