Question

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

A platform team is establishing deployment infrastructure for a multi-tenant application on Google Kubernetes Engine (GKE). The application consists of a persistent transactional database requiring guaranteed node availability and an asynchronous queue-processing worker service designed to handle sudden termination gracefully. Additionally, administrators need to execute `kubectl` commands from a new CI/CD build agent that has the `gcloud` CLI authenticated. Which deployment configuration and administrative setup correctly satisfies these workload requirements while maintaining cost efficiency and proper cluster connectivity?

  1. Provision a GKE Standard cluster with a standard node pool for the persistent database and a Spot node pool for the queue-processing workers, then execute `gcloud container clusters get-credentials` on the build agent before running `kubectl` commands.Answer
  2. B
    Provision a GKE Standard cluster configured with a single Spot node pool for both the database and worker workloads to minimize overall compute cost, then execute `gcloud container clusters get-credentials` on the build agent before running `kubectl` commands.
  3. C
    Provision a GKE Standard cluster with a standard node pool for the persistent database and a Spot node pool for the queue-processing workers, then execute `gcloud config set container/cluster` on the build agent to configure cluster access for `kubectl`.
  4. D
    Provision a GKE Autopilot cluster and configure custom Linux kernel sysctl parameters on node pools for both workloads, then execute `gcloud container clusters get-credentials` on the build agent before running `kubectl` commands.

Answer

Provision a GKE Standard cluster with a standard node pool for the persistent database and a Spot node pool for the queue-processing workers, then execute `gcloud container clusters get-credentials` on the build agent before running `kubectl` commands.
The correct strategy uses GKE Standard to separate stateful and fault-tolerant workloads into dedicated node pools (standard for persistent data, Spot for batch processing) to optimize cost without risking database stability. Additionally, `gcloud container clusters get-credentials` must be executed to fetch cluster API endpoints and write valid credentials to the kubeconfig file used by `kubectl`.

Step-by-Step Solution

1
Analyze workload availability and persistence requirements.
Database workloads need standard node pools to prevent node preemptions, while queue-processing workers can leverage Spot VM node pools for cost savings.
Spot instances can be reclaimed at any time, which risks database corruption or downtime for non-fault-tolerant stateful applications.
2
Evaluate cluster operational modes (Autopilot vs. Standard).
GKE Standard allows custom node pool definitions (standard vs. Spot) and hardware/kernel tuning, whereas GKE Autopilot abstracts node pool management.
Autopilot manages nodes automatically and limits custom node modifications or explicit node pool separation patterns required here.
3
Determine the proper cluster authentication procedure for CLI tools.
Run `gcloud container clusters get-credentials` with the cluster name and zone/region.
This command fetches cluster endpoint details and authentication tokens, writing them into the kubeconfig configuration file so `kubectl` can target the cluster.

Key Concept

GKE Node Pool Architecture and Cluster Credential Provisioning
Estimated Time:2m 0s
Rate this question