ExamFinch.com My Study

Study guide

7.1 Installing and Configuring kubectl

Practice this exam

Google Cloud Associate Cloud Engineer ACE

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Exam Overview

1.1 About the GCP Associate Cloud Engineer Exam 1.2 How to Use This Study Guide & Build a Study Plan

2 Chapter 2: Resource Hierarchy, IAM Basics & Cloud Identity

2.1 The GCP Resource Hierarchy: Organizations, Folders & Projects 2.2 Organization Policies & Granting IAM Roles 2.3 Cloud Identity: Managing Users and Groups

3 Chapter 3: APIs, Quotas & Billing Configuration

3.1 Enabling APIs and Provisioning Cloud Operations Suite 3.2 Assessing and Requesting Quota Increases 3.3 Billing Accounts, Project Linking & Billing Exports 3.4 Billing Budgets and Alerts

4 Chapter 4: Planning Compute & Storage Resources

4.1 Choosing the Right Compute Option: GCE vs. GKE vs. Cloud Run vs. Cloud Functions 4.2 Spot VMs, Custom Machine Types & Cost-Optimized Compute Planning 4.3 Choosing a Data Storage Product: Cloud SQL, BigQuery, Firestore, Spanner & Bigtable 4.4 Cloud Storage Classes & Persistent Disk Types

5 Chapter 5: Planning Network Resources

5.1 Load Balancing Options and Use Cases 5.2 Regional Resource Placement & High Availability Planning 5.3 Network Service Tiers: Premium vs. Standard

6 Chapter 6: Deploying Compute Engine Workloads

6.1 Launching Compute Engine Instances: Disks, SSH Keys & Availability Policies 6.2 Managed Instance Groups, Instance Templates & Autoscaling 6.3 OS Login and VM Manager for Fleet Configuration

7 Chapter 7: Deploying Google Kubernetes Engine Workloads

7.1 Installing and Configuring kubectl 7.2 Deploying GKE Clusters: Autopilot, Regional, Private & GKE Enterprise 7.3 Deploying Containerized Applications to GKE

8 Chapter 8: Deploying Serverless & Event-Driven Applications

8.1 Deploying Applications to Cloud Run and Cloud Functions 8.2 Event-Driven Architectures: Pub/Sub, Cloud Storage Triggers & Eventarc

9 Chapter 9: Deploying Data Solutions

9.1 Deploying Data Products: Cloud SQL, Firestore, Spanner, BigQuery & AlloyDB 9.2 Deploying Pub/Sub, Dataflow & Loading Data into Google Cloud

10 Chapter 10: Deploying Networking Resources & Infrastructure as Code

10.1 Creating VPCs, Subnets & Shared VPC 10.2 Firewall Rules, Cloud VPN & VPC Network Peering 10.3 Infrastructure as Code: Terraform, Config Connector, Cloud Foundation Toolkit & Helm

11 Chapter 11: Managing Compute Engine & GKE in Production

11.1 Connecting to and Managing Running Compute Engine Instances 11.2 Working with Snapshots and Custom Images 11.3 Managing GKE Clusters: Node Pools, Workloads & Artifact Registry Access 11.4 Horizontal and Vertical Pod Autoscaling in GKE

12 Chapter 12: Managing Cloud Run, Storage & Database Operations

12.1 Managing Cloud Run Revisions, Traffic Splitting & Scaling 12.2 Managing and Securing Cloud Storage Objects & Lifecycle Policies 12.3 Querying, Estimating Costs, Backup & Job Monitoring for Databases (Cloud SQL, BigQuery, Spanner, Dataflow)

13 Chapter 13: Networking Operations, Monitoring & Logging

13.1 Networking Operations: Subnets, Static IPs, Cloud DNS & Cloud NAT 13.2 Cloud Monitoring: Alerts, Custom Metrics & Dashboards 13.3 Cloud Logging: Buckets, Log Analytics, Routers & Filtering 13.4 Diagnostics, Ops Agent, Managed Service for Prometheus & Audit Logs

14 Chapter 14: IAM Policies & Role Types

14.1 IAM Policies: Structure, Bindings & Policy Hierarchy 14.2 IAM Role Types: Basic, Predefined & Custom Roles

15 Chapter 15: Service Accounts & Security Configuration

15.1 Creating Service Accounts & Assigning Least-Privilege Permissions 15.2 Assigning Service Accounts to Resources & Managing SA IAM Policies 15.3 Service Account Impersonation & Short-Lived Credentials

16 Chapter 16: Exam Readiness — Scenarios & Test-Day Strategy

16.1 Common ACE Exam Scenarios & Decision Frameworks 16.2 Test-Day Logistics, Time Management & Final Review Checklist

7.1 Installing and Configuring kubectl

Key Takeaways Explain This Topic AI

kubectl and gcloud are separate tools: gcloud manages GKE cluster infrastructure, kubectl manages objects inside the running cluster

Install kubectl with gcloud components install kubectl — Cloud Shell is the only place it ships pre-installed and pre-authenticated

Since GKE 1.26, kubectl requires the gke-gcloud-auth-plugin binary to authenticate — missing it causes auth errors unrelated to IAM

gcloud container clusters get-credentials writes an entry to $HOME/.kube/config (or $KUBECONFIG) and switches the current context automatically

Use kubectl config use-context to switch between already-configured clusters without re-running get-credentials

Last updated: July 2026

Why kubectl Setup Is Its Own Exam Objective

The ACE exam guide calls out "Installing and configuring the command line interface (CLI) for Kubernetes (kubectl)" as its own bullet under Domain 3 (Deploying and implementing a cloud solution). That is deliberate: kubectl is not gcloud , and candidates who have only clicked around the Cloud Console routinely miss the fact that talking to a Google Kubernetes Engine (GKE) cluster requires a second tool, a second authentication layer, and a second configuration file. Expect scenario questions where the "fix" is simply installing or re-pointing kubectl, not touching the cluster itself.

kubectl vs. gcloud: Two Different Control Planes

gcloud manages Google Cloud resources — it creates the GKE cluster, node pools, and the underlying VMs. It talks to the Google Cloud API.

kubectl manages objects inside a running Kubernetes cluster — Pods, Deployments, Services, ConfigMaps. It talks directly to the cluster's Kubernetes API server, not to the Google Cloud API.

You can create a flawless GKE cluster with gcloud and still be completely unable to deploy an application to it if kubectl isn't installed and pointed at the right cluster.

Installing kubectl

Method Command / Notes

Cloud Shell Pre-installed and pre-authenticated — no setup needed. This is why Cloud Shell is the fastest path for exam-style "deploy this now" scenarios.

gcloud CLI component gcloud components install kubectl — installs kubectl as a managed component alongside the Cloud SDK.

OS package manager sudo apt-get install kubectl (Debian/Ubuntu) or sudo yum install kubectl (RHEL/CentOS), using Google's Cloud SDK package repository.

Standalone binary Download directly from the official Kubernetes release site — works without gcloud installed at all, common for CI/CD runners.

A common exam trap: candidates assume gcloud installs kubectl automatically. It does not — the Cloud SDK installer only prompts you to add the kubectl component; you must accept it or run the install command explicitly.

The Authentication Plugin: gke-gcloud-auth-plugin

Since GKE version 1.26 , kubectl requires a separate binary called gke-gcloud-auth-plugin to exchange your gcloud identity for a short-lived Kubernetes authentication token. Without it, kubectl commands against a GKE cluster fail even if the kubeconfig file looks correct. gcloud components install gke-gcloud-auth-plugin

On some platforms you must also confirm the plugin is active by setting an environment variable: export USE_GKE_GCLOUD_AUTH_PLUGIN=True

If you see an authentication error referencing "exec plugin" or "auth-provider deprecated" when running kubectl get pods against a GKE cluster, the fix is almost always a missing or outdated gke-gcloud-auth-plugin — not an IAM permission problem.

Pointing kubectl at a Cluster: get-credentials

The single most important command for this objective is: gcloud container clusters get-credentials CLUSTER_NAME \

  • -zone ZONE # for zonal clusters
  • # or
  • -region REGION # for regional clusters

This command does two things automatically:

Writes an entry for the cluster into your kubeconfig file (default path $HOME/.kube/config , or the path specified by the KUBECONFIG environment variable).

Switches kubectl's current context to point at that cluster.

You need at least the container.clusters.get IAM permission (bundled into roles/container.viewer , roles/container.developer , or roles/container.admin ) on the project — without it, get-credentials itself fails before kubectl ever runs.

Working with kubeconfig and Contexts

A kubeconfig file can hold credentials for many clusters at once , each represented as a context (a named combination of cluster + user + namespace). Key commands:

  • Command Purpose
  • kubectl config get-contexts List all clusters currently known to kubectl
  • kubectl config current-context Show which cluster kubectl is currently talking to
  • kubectl config use-context CONTEXT_NAME Switch active cluster without re-authenticating
  • kubectl cluster-info Confirm connectivity to the control plane
  • kubectl get nodes Confirm the connection actually works end-to-end

Exam scenario: An engineer runs gcloud container clusters get-credentials cluster-a --zone us-central1-a , then later runs gcloud container clusters get-credentials cluster-b --region us-east1 . A kubectl get pods command unexpectedly returns Pods from cluster-b . Why? Because each get-credentials call overwrites the current context , so the most recently fetched cluster becomes active — the engineer needs kubectl config use-context to switch back to cluster-a without re-running get-credentials .

Exam scenario 2: A freshly created Compute Engine VM in the same project as a GKE cluster runs kubectl get pods and receives error: You must be logged in to the server (Unauthorized) or "no configuration has been provided." The root cause is almost never a firewall rule — it is that gcloud container clusters get-credentials was never run on that VM, so no kubeconfig entry exists yet.

Key Takeaways

kubectl and gcloud are separate tools with separate control planes: gcloud manages the cluster's infrastructure, kubectl manages objects inside it.

Install kubectl with gcloud components install kubectl ; it is not bundled by default outside Cloud Shell.

Since GKE 1.26, gke-gcloud-auth-plugin is required for kubectl authentication — missing it produces auth errors that look unrelated to IAM.

gcloud container clusters get-credentials writes to $HOME/.kube/config (or $KUBECONFIG ) and switches the current context automatically.

Use kubectl config use-context to switch between multiple already-configured clusters without re-running get-credentials .