A county IT shared-services team runs coding agents for multiple departments on a shared GKE cluster and wants a compromised agent in one department's workload to be unable to reach another department's code or secrets. Which design best achieves this isolation?
Select an answer to reveal the explanation.
Short Explanation
Think of GKE namespaces like separate offices in the same building: same building, different locks, different keys. Give each department its own namespace with tight RBAC and a network policy that blocks cross-office traffic, and a compromised agent in one office literally can't walk down the hall to another department's secrets. Shared namespaces and shared service accounts turn that hallway into an open floor plan.
Full Explanation
The mechanism is namespace-scoped isolation: GKE enforces RBAC at the namespace boundary, and a Kubernetes NetworkPolicy can deny pod-to-pod traffic across namespaces by default, so pairing a dedicated namespace per department with its own service accounts and secrets means a compromised agent's credentials only unlock resources inside its own boundary. The enforcement point is the namespace, not a convention layered inside one shared namespace.
Running every department in one namespace, even with separate service accounts, fails because many default cluster configurations still allow pod-to-pod traffic within a namespace, so a compromised agent can often reach sibling workloads or shared secrets mounted there. A cluster-admin-scoped shared service account fails on a different concept entirely, it collapses the isolation model rather than weakening it, since any agent holding that credential can act as every department at once. Label-based filtering inside a shared namespace relies on the agent's own queries to self-restrict, which is exactly the kind of enforcement a compromised or misled agent can ignore.
Scope caveat: namespace isolation alone is incomplete without an explicit default-deny NetworkPolicy, since cross-namespace traffic is often permitted until one is applied. A concrete check: attempt a cross-namespace API call from one department's agent pod and confirm it is refused before considering the isolation complete.