Examkin

Question

Difficulty: Very hardDeploying and Managing Google Kubernetes Engine (GKE) Clusters and Workloads

An enterprise DevOps team is designing the GKE deployment architecture for two upcoming microservices:

1. A stateless HTTP API service that experiences sudden, unpredictable load spikes and requires hands-off node infrastructure management with zero operational overhead for cluster upgrades.
2. A specialized network security monitoring daemon that requires elevated Linux privileges (`CAP_SYS_ADMIN`) and direct access to the host node network namespace (`hostNetwork: true`).

Which GKE deployment and cluster configuration strategy correctly fulfills both application requirements while adhering to Google Cloud recommended best practices?

  1. Deploy the stateless HTTP API service to a GKE Autopilot cluster, and deploy the network security daemon to a GKE Standard cluster with a dedicated node pool.Answer
  2. B
    Deploy both microservices to a single GKE Autopilot cluster using separate Kubernetes namespaces and custom pod security standards.
  3. C
    Deploy both microservices to a single GKE Standard cluster using Spot VM node pools for both workloads to minimize operational costs.
  4. D
    Deploy the HTTP API service to GKE Standard using a Horizontal Pod Autoscaler (HPA) configured to scale the node pool VM instance count, and deploy the daemon to GKE Autopilot.

Answer

Deploy the stateless HTTP API service to a GKE Autopilot cluster, and deploy the network security daemon to a GKE Standard cluster with a dedicated node pool.
The correct strategy separates the workloads based on GKE operational boundaries. GKE Autopilot provides fully managed node provisioning, scaling, and maintenance for stateless workloads without infrastructure management overhead. However, Autopilot restricts host network binding (`hostNetwork: true`) and elevated Linux capabilities (`CAP_SYS_ADMIN`). Consequently, the privileged monitoring daemon must be deployed to a GKE Standard cluster where node configuration and pod security settings can be customized.

Step-by-Step Solution

1
Evaluate the operational and security constraints of GKE Autopilot.
GKE Autopilot manages all node infrastructure, provisioning, and OS patching, making it ideal for stateless web workloads. However, to maintain cluster security, Autopilot blocks capabilities such as hostNetwork: true, hostPort, and elevated Linux capabilities like CAP_SYS_ADMIN.
Security boundaries in GKE Autopilot prevent workloads from modifying host node networking or kernel capabilities.
2
Evaluate requirements for the privileged monitoring daemon.
The network security daemon requires host network namespace access and CAP_SYS_ADMIN privileges, which are supported in GKE Standard node pools where administrators have full control over node configurations and pod security contexts.
GKE Standard allows custom node pool management and unrestricted Pod Security Standards when explicitly configured.
3
Synthesize the cluster architecture selection.
Combining GKE Autopilot for the hands-off HTTP API service and GKE Standard for the privileged security daemon satisfies all operational and technical requirements.
This workload segregation respects GKE feature boundaries while following Google Cloud architectural guidelines.

Key Concept

GKE Autopilot vs. Standard Operational Boundaries and Workload Isolation Requirements
Rate this question

Topics

Deploying and Managing Google Kubernetes Engine (GKE) Clusters and Workloads