An overlay needs Kubernetes Secrets derived from local key files without pasting raw secret YAML into every environment folder by hand. Which Kustomize feature addresses that pattern?
Select an answer to reveal the explanation.
Short Explanation
secretGenerator is the sealed envelope factory for an overlay: feed it files or literals, get a Secret object in the build—still treat the inputs carefully and prefer sealed or external secret workflows in real pipelines.
Full Explanation
An overlay that needs Kubernetes Secrets derived from local key files without pasting raw Secret YAML into every environment folder should use secretGenerator entries that build Secrets from literals or files. Generators keep municipal overlays DRY and reduce accidental commits of hand-maintained Secret manifests while still producing applyable Secret objects.
Why the other options fail by concept: commonLabels must never encode password material as label values (labels are widely readable and inappropriate for secrets). The images transformer’s newTag is for image references, not passwords. kubectl explain Secret documents schema; it is not an apply mechanism that generates env-specific Secrets from files.
Exam caveat: Generated Secrets still land in etcd—pair with encryption at rest and RBAC. Prefer external secret managers for production city credentials when policy requires. Hash suffixes behave like configMapGenerator regarding rollouts when names change.
Operational check: Add secretGenerator with file references in the overlay (keeping files out of public git if needed), kubectl kustomize to confirm a Secret object renders (data redacted as expected), apply to a restricted namespace, and verify the Deployment mounts/envFrom references resolve after rollout.