Staging and production overlays for a grants portal share one cluster and would collide on resource names if left unchanged. How does Kustomize typically avoid that collision?
Select an answer to reveal the explanation.
Short Explanation
Prefixes and suffixes are like putting “STG-” or “-prod” on locker tags in the same hallway. Same contents, different nameplates—no two apps fighting over one locker label.
Full Explanation
When staging and production overlays for a grants portal share one cluster, Kustomize typically avoids resource name collisions by applying namePrefix or nameSuffix in each overlay so generated metadata.names diverge per environment. That keeps both environments’ objects uniquely named without deleting namespaces or disabling Kubernetes uniqueness rules—practical for municipal clusters that host multiple envs.
Why the other options fail by concept: Deleting the production namespace whenever staging is applied is operationally unacceptable. Forcing identical metadata.name values across overlays causes conflicts on apply. You cannot disable Kubernetes name uniqueness with a Pod annotation.
Exam caveat: Prefix/suffix also rewrites many references automatically, but patches hard-coding old names may need updates. Combining namePrefix with namespace: is common—namespace isolation plus name divergence. Cross-env Services still need correct DNS/names when apps call each other.
Operational check: Set namePrefix: staging- and prod- in respective overlays, kubectl kustomize each, and confirm Deployment/Service names differ. Apply both to the shared cluster and kubectl get deploy to see coexistence without AlreadyExists errors.