Checkout-stage and checkout-prod for the city storefront share one OKE cluster. What Kubernetes unit keeps their Services, ConfigMaps, and Secrets from clobbering each other?
Select an answer to reveal the explanation.
Short Explanation
Namespaces are separate drawers in the same filing cabinet (cluster). Stage and prod Services, ConfigMaps, Secrets, and RBAC stay out of each other's way. An OCI compartment is tenancy IAM—not a substitute for Kubernetes isolation.
Full Explanation
Separate Kubernetes namespaces keep checkout-stage and checkout-prod from clobbering each other on one shared OKE cluster. Namespaces scope object names, DNS (service.namespace), Secrets, ConfigMaps, and RBAC so identically named Services in stage and prod do not overwrite one another. That is the cluster-local isolation unit for multi-environment tenancy of Kubernetes objects. A single default namespace makes name collisions routine: kubectl apply for stage can overwrite prod objects with the same names. That is the anti-pattern for two environments sharing a cluster. An OCI compartment is a tenancy IAM and resource-organization boundary. Putting a compartment identifier inside a Pod spec does not replace Kubernetes namespacing; compartments do not provide Service DNS isolation or Kubernetes RBAC scopes inside the cluster. Forcing identical resource names into one namespace guarantees conflict: only one object can own a given name, and DNS cannot meaningfully point at two different releases with the same Service name in the same namespace. Exam caveat: namespaces are not a hard security boundary by themselves—pair them with NetworkPolicies, RBAC, and separate Secrets management; they solve object scoping, not every isolation threat. Operational check: deploy both environments into distinct namespaces, confirm Services resolve with namespace-qualified DNS, and verify a stage apply cannot mutate prod ConfigMaps or Secrets.