Your team manages a large Google Kubernetes Engine (GKE) cluster. Several application teams currently use the same namespace to develop microservices for the cluster. Your organization plans to…

Question

Options

• ACreate new role-based access controls (RBAC) for each team in the existing cluster, and define
• BCreate a new namespace for each environment in the existing cluster, and define resource
• CCreate a new GKE cluster for each team.
• DCreate a new namespace for each team in the existing cluster, and define resource quotas.

• A
  76% (32)
• B
  17% (7)
• C
  2% (1)
• D
  5% (2)

Explanation

Google's best practice for multi-team GKE clusters is to give each team its own namespace and then layer on: (1) RBAC roles and RoleBindings scoped to that namespace so teams can only access their own resources, (2) ResourceQuotas to cap CPU/memory consumption and protect neighbours' performance, and (3) NetworkPolicies to restrict cross-namespace communication. Option A captures this combination. Option D also mentions namespaces with resource quotas but omits RBAC, which is essential for security isolation - without it any team member can read or modify another team's secrets and workloads. Option B scopes namespaces to environments rather than teams, which doesn't address team-level access control. Option C (one cluster per team) provides the strongest isolation but is significantly more expensive and operationally complex - it is not the cost-minimising recommendation when namespaces can achieve the necessary isolation.

No community discussion yet for this question.