GKE Cluster and Namespace Design for Data Isolation

PCDOE By islever Editorial Last updated

Managing infrastructure.

Short answer

C Create one cluster for each environment (development and production) with each application in its own namespace within each cluster.

Question

You work for a company that manages highly sensitive user data. You are designing the Google Kubernetes Engine (GKE) infrastructure for your company, including several applications that will be deployed in development and production environments. Your design must protect data from unauthorized access from other applications, while minimizing the amount of management overhead required. What should you do?
  1. Create one cluster for the organization with separate namespaces for each application and environment combination.
  2. Create one cluster for each application with separate namespaces for production and development environments.
  3. Create one cluster for each environment (development and production) with each application in its own namespace within each cluster. Correct Answer
  4. Create one cluster for the organization with separate namespaces for each application.

Key Takeaways

The core conflict is between strict physical isolation (many clusters) and operational efficiency (fewer clusters); the correct answer leverages RBAC within shared environment-specific clusters to minimize overhead while maintaining logical separation.

This question examines GKE infrastructure design principles for balancing security isolation with management overhead when handling sensitive data across development and production environments.

Common mistake: Many candidates select Option B, believing that separate clusters per application provides the strongest security; however, this creates unmanageable overhead and violates the requirement to minimize management burden.

Expert Analysis

Why the Answer Is Correct

Option C is the correct approach because it aligns with Google Cloud best practices for managing multiple environments. By creating one cluster per environment (Development and Production), you enforce a strong boundary between lifecycle stages, preventing accidental deployment of dev code to prod. Within each cluster, using separate namespaces for each application allows for logical isolation. When combined with Role-Based Access Control (RBAC) and Network Policies, this setup effectively prevents unauthorized access between applications without the excessive cost and complexity of managing hundreds of individual clusters.

Why the Other Options Are Wrong

Option A mixes development and production workloads in the same cluster, which poses a significant security risk and makes compliance auditing difficult due to lack of environment segregation. Option D fails to distinguish between development and production, leading to similar risks as A. Option B suggests creating a separate cluster for every single application; as noted by community experts, this results in massive management overhead, high costs, and complex maintenance, directly violating the constraint to "minimize the amount of management overhead required."

Community Comment Notes

Community consensus strongly favors Option C. One commenter highlighted that having 100 applications would require 100 clusters under Option B, calling it "EXPENSIVE, OVERLY COMPLEX." Another user confirmed that banks use separate clusters for DEV/TEST/STAGE/PROD but share them across applications within those environments, relying on RBAC for intra-cluster security. A dissenting view suggesting Option B was rebutted by noting that while B offers isolation, it ignores the critical operational constraints stated in the prompt.

Exam Strategy

When designing GKE architectures, always prioritize the 'least privilege' principle combined with operational feasibility. Use namespaces for logical isolation within a cluster, but reserve separate clusters primarily for separating distinct environments (like Prod vs. Dev) or highly regulated tenants, not for every single microservice.

Frequently Asked Questions

Why not create a separate cluster for each application?

Creating a cluster per application leads to exponential management overhead and high costs, violating the requirement to minimize operational burden.

How do namespaces protect data in GKE?

Namespaces provide logical isolation; when combined with RBAC and Network Policies, they prevent unauthorized cross-application access within the same cluster.

More PCDOE FAQ →

Discussion 5 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 5

  1. odinson 👍 5 Answered C
    Iyona, B is very bad decision. Imagine if you have 100 applications. You need 100 clusters for all those apps. EXPENSIVE, OVERLY COMPLEX. You can have RBAC and other IAM rules within the same cluster to avoid apps accessing others namespaces which is what we do in production. I worked in a BANK with sensitive PII stuff like credit card transaction details. We had seprate clusters for DEV,TEST,STAG and another for PROD. Every app had their own ns and we used RBAC and other secuirty guardrails. C is correct
  2. kitaharazyl 👍 3 Answered C
    C. Create one cluster for each environment (development and production) with each application in its own namespace within each cluster.
  3. lyona 👍 2 Answered B
    B - "Protect data from unauthorized access from other applications". C doesn't achieve this and neither do A and D. You could argue B might have a significant management overhead, but the question doesn't state how many applications
  4. Tartaruga1234 👍 2 Answered C
    Answer c is correct
  5. BlackCoffee 👍 1
    B is incorrect: Creating separate clusters for every single individual application creates massive management overhead, high infrastructure replication costs, and complex cross-application maintenance that directly violates the requirement to minimize operational overhead.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Binary Authorization Attestor Implementation

S-grade

Granting Log Export Permissions in Google Cloud

S-grade

Optimizing SLO Balance Between Reliability and Velocity

S-grade

Minimizing GKE Logging Costs with SYSTEM Mode

S-grade

Practice All PCDOE Questions

Access 75 questions with complete answers and detailed explanations.

View Full PCDOE Practice Test →

← Back to PCDOE Study Guide