A base kustomization.yaml must declare which YAML files belong in the build. Which field lists those manifests?
Select an answer to reveal the explanation.
Short Explanation
resources: is the packing list for the moving truck. If a manifest is not on the list, Kustomize will not load it—no mystery includes.
Full Explanation
A base kustomization.yaml declares which YAML files belong in the build using the resources: field, listing the local YAML files or directories to include. That list is the inventory of municipal base manifests—Deployments, Services, ConfigMaps, and related objects—that overlays later customize. Without a correct resources: list, Kustomize has no inputs to build from the base and overlays cannot reliably compose the city’s shared foundation.
Why the other options fail by concept: helmCharts: alone with no chart name does not invent local Deployment YAML as a substitute for resources. openapi: with a random URL and empty resources does not include application manifests. sortOptions: may influence ordering of output; it is not the field that includes Deployment YAML in the build.
Exam caveat: resources paths are relative to the kustomization.yaml file’s directory. You may include subdirectories that themselves contain kustomization.yaml for nested bases. Typos in resources: often yield quietly incomplete builds—compare object counts to an expected inventory in CI for municipal repos.
Operational check: List every base YAML under resources:, run kubectl kustomize base, and confirm each expected kind/name appears before wiring overlays. Add a CI snapshot or grep check so missing resources fail the pipeline before anyone applies to a city cluster.