Google Cloud Hands-On First Steps: Console, gcloud CLI, Cloud Shell & SDKs

Once you understand where your resources live and how the resource hierarchy is organised, the next question is intensely practical: how do you actually do anything? Google Cloud gives you several front doors — a point-and-click web Console, a scriptable command-line tool called gcloud, a browser-based terminal called Cloud Shell, and programmatic client libraries — and a professional moves fluidly between them. The Console is where you explore and learn; the CLI is where you become fast, repeatable and automatable; the client libraries are where your applications live; and underneath all of them sits the single most misunderstood topic for newcomers: authentication — how a human and how a program prove who they are to Google Cloud.

This lesson is the hands-on on-ramp. It assumes you have a Google account and have seen the Console once. By the end you will install and drive the gcloud CLI properly (not just memorise three commands), understand configurations and properties so you can juggle multiple projects and identities without confusion, master the --format and --filter flags that turn gcloud into a data tool, use Cloud Shell and its Editor as a zero-install workstation, call Google Cloud from code with the client libraries, and — most importantly — understand service accounts and Application Default Credentials (ADC), including why exporting service-account keys is discouraged and what to do instead. It maps directly to the Cloud Digital Leader (CDL) and Associate Cloud Engineer (ACE) exams, both of which probe exactly these tools and the authentication model behind them.

Learning objectives

By the end of this lesson you can:

• Choose the right interface — Console, gcloud CLI, Cloud Shell, or client libraries — for a given task, and explain the trade-offs.
• Install the Cloud SDK, run gcloud init, and manage named configurations and properties so you can switch projects, regions and identities cleanly.
• Use the global flags --project, --format, --filter (and --impersonate-service-account) to make gcloud precise, scriptable and identity-aware.
• Distinguish gcloud auth login (your user identity) from gcloud auth application-default login (credentials for code), and explain when each is used.
• Explain service accounts, Application Default Credentials, the credential search order, service-account impersonation, and why downloaded keys are discouraged.
• Use Cloud Shell, the Cloud Shell Editor, and the dedicated tools gsutil and bq.
• Describe the path from interactive gcloud to Infrastructure as Code (Terraform / Config Connector).

Prerequisites

You need a Google account, a browser, and a Google Cloud project you can use as a sandbox (creating one is covered in the Cloud Fundamentals lesson). No prior command-line experience is assumed — every command is explained, and you can run all of them inside Cloud Shell with nothing installed locally. This is an early lesson in the Google Cloud Zero-to-Hero course: everything downstream (IAM, networking, compute, data) is operated through the tools you learn here, so time spent now pays back constantly.

Core concept: the four ways you talk to Google Cloud

Every action on Google Cloud is, underneath, a call to a REST API (for example compute.googleapis.com). The interfaces are just different clients that make those calls on your behalf. Knowing this demystifies everything: the Console, gcloud, Cloud Shell and the client libraries are four doors into the same house.

The practical rule for this course: learn in the Console, operate with gcloud, build with Terraform, and integrate with the client libraries. A junior clicks the Console for everything; an architect reaches for the CLI the moment a task will be done more than once, and for IaC the moment it must be reproducible.

Core concept: the Cloud Console

The Cloud Console is the web interface to your entire Google Cloud estate. A few features repay learning early because they appear in every screenshot and every exam scenario:

• The project picker (top bar) — almost everything you see is scoped to the currently selected project. The single most common Console confusion is “my resource has vanished”; nine times out of ten you are simply in the wrong project. The picker also lets you search and pin projects.
• The search bar — searches products, resources and documentation. Typing “buckets” jumps you straight to Cloud Storage; this is faster than the navigation menu once you know what you want.
• The navigation menu (the “hamburger”, top-left) — every product, grouped by area (Compute, Storage, Databases, Networking, …). Pin frequently used products to the top.
• Activate Cloud Shell (the terminal icon, top-right) — opens a command line in the browser; covered below.
• Notifications, billing and IAM — the bell, the billing console, and IAM & Admin are the three administrative areas you will return to constantly.
• Cloud Shell “Equivalent command line” / “Equivalent REST” — many create wizards show, before you click Create, the exact gcloud command or REST body that the form will execute. This is the single best way to learn gcloud: build something in the form, then copy the command it generates.

The Console is unmatched for discovery and for visual tasks (dashboards, billing reports, IAM review). It is the wrong tool for anything repeatable — which is where the CLI comes in.

Core concept: the gcloud CLI and the Cloud SDK

The Cloud SDK (also called the Google Cloud CLI) is a downloadable bundle of command-line tools. Its flagship is gcloud, the unified CLI for managing almost every Google Cloud service. The bundle also includes specialised tools — historically gsutil (Cloud Storage), bq (BigQuery) and kubectl (Kubernetes) — and a package manager called gcloud components for installing and updating them.

Installing the SDK

You have three good options:

The SDK requires Python (a compatible interpreter is bundled by the installers). Two release tracks exist: the stable track (default) and gcloud alpha / gcloud beta command groups for pre-GA features — install those component groups when a command you need is not yet GA.

Initialising: gcloud init

After installing, run:

gcloud init

This interactive command walks you through the essential first-time setup:

1. Log in — opens a browser to authenticate your user account (Google account). This establishes your identity for gcloud commands.
2. Pick a project — sets the default project for subsequent commands.
3. Pick a default region/zone (optional) — saves you from typing --zone constantly.

gcloud init creates (or updates) a configuration behind the scenes. Understanding configurations is the difference between a calm CLI experience and a confusing one.

Configurations: juggling projects and identities cleanly

A configuration is a named set of properties — your active account, default project, region, zone and many others. The default configuration is called default. The power of configurations is that you can keep several and switch between them instantly, which is exactly what you need when you work across, say, a dev project as yourself and a prod project under a different identity.

You can also force a single command to use a specific configuration without switching, via the --configuration flag or the CLOUDSDK_ACTIVE_CONFIG_NAME environment variable — handy in scripts and CI.

Properties: the settings inside a configuration

A property is one setting within a configuration, organised into sections (core, compute, auth, …). The commands:

gcloud config set project my-sandbox-123      # core/project
gcloud config set compute/region europe-west2 # compute/region
gcloud config set compute/zone europe-west2-a # compute/zone
gcloud config set account me@example.com      # core/account
gcloud config get-value project               # read one back
gcloud config list                            # show the active config's properties
gcloud config unset compute/zone              # remove a property

The most useful properties to know:

Precedence (highest wins): a flag on the command (e.g. --project) overrides an environment variable (e.g. CLOUDSDK_CORE_PROJECT), which overrides the active configuration’s stored property. Internalise this order — it explains almost every “but I set the project!” surprise.

The three global flags that matter most

These flags work on virtually every gcloud command and turn the CLI from a clicker-replacement into a precise data tool.

--project — run one command against a specific project without changing your active configuration:

gcloud compute instances list --project=other-project-456

--format — control the output shape. The default is human-readable tables; for scripting you want machine-readable output or a single value:

# Get just the external IP of one VM — perfect for scripting
gcloud compute instances describe web-1 --zone=europe-west2-a \
  --format="value(networkInterfaces[0].accessConfigs[0].natIP)"

--filter — server- or client-side filtering using a simple expression language, so you fetch only what you want:

gcloud compute instances list --filter="status=RUNNING AND zone:europe-west2-a"
gcloud compute instances list --filter="name~^web-"   # regex: names starting "web-"
gcloud projects list --filter="labels.env=prod"

--filter supports =, !=, <, >, : (“contains”), ~ (regex), and boolean AND/OR/NOT. Combine --filter to choose which rows and --format to choose which columns and you can answer almost any “what do I have?” question in one line. Two more helpers: --sort-by orders results, and --limit caps the count.

Components: managing the toolset

gcloud components is the SDK’s package manager (available when you installed via the interactive installer, not always via OS package managers):

gcloud components list                  # see installed/available components
gcloud components install kubectl       # add a component (e.g. kubectl, gke-gcloud-auth-plugin)
gcloud components update                 # update everything to the latest release
gcloud components remove <name>          # remove a component

Common components to install: kubectl and gke-gcloud-auth-plugin (for GKE), alpha/beta (pre-GA commands), and cloud-sql-proxy. Run gcloud version to see the installed SDK and component versions.

Discoverability and ergonomics

gcloud is highly discoverable from the command line itself:

• gcloud --help and gcloud <group> <command> --help document every flag.
• gcloud help <command> opens the full man-style help.
• gcloud cheat-sheet prints a one-page reference.
• gcloud topic lists guides on cross-cutting topics (e.g. gcloud topic filters, gcloud topic formats).
• gcloud interactive (from the gcloud-interactive-shell/alpha) gives auto-completion and inline help as you type.
• Enable tab-completion in your shell (the installer offers to add it) so you rarely mistype a command.

Core concept: authentication — gcloud auth login vs application-default

This is the topic that trips up nearly every newcomer, so we slow down. There are two distinct kinds of credentials, and using the wrong one is the cause of most “permission denied” and “could not find default credentials” errors.

gcloud auth login — credentials for you (the human using the CLI)

gcloud auth login

This authenticates your user identity for use by the gcloud, gsutil and bq command-line tools. It opens a browser, you consent, and gcloud stores a token so your subsequent CLI commands run as you. Manage these with:

gcloud auth list                       # show credentialed accounts and the ACTIVE one
gcloud config set account me@you.com   # switch the active account
gcloud auth revoke me@you.com          # remove stored credentials

Crucially, gcloud auth login credentials are used by the CLI tools only. Your application code (a Python script using the client libraries) does not automatically use them.

gcloud auth application-default login — credentials for code

gcloud auth application-default login

This creates Application Default Credentials (ADC) — a credential file on your machine (in your config directory) that the client libraries automatically discover and use when you run code locally during development. So:

The classic beginner trap: you run gcloud auth login, then run a Python script with the client library, and it fails with “Could not automatically determine credentials.” The fix is gcloud auth application-default login — because the library looks for ADC, not for the CLI’s login. Revoke ADC with gcloud auth application-default revoke.

Core concept: service accounts and Application Default Credentials (ADC)

Humans use user accounts; workloads (a VM, a Cloud Run service, a CI pipeline, a script in production) use service accounts.

What a service account is

A service account is a special, non-human Google identity that applications use to authenticate and to be authorised (via IAM roles) to call Google Cloud APIs. It is identified by an email like my-app@my-project.iam.gserviceaccount.com. You grant it IAM roles exactly as you would a user, and your workload then acts with that account’s permissions. (Service-account creation and IAM are covered in depth in the IAM lesson; here we focus on how the tools use them to authenticate.)

Application Default Credentials and the credential search order

Application Default Credentials (ADC) is a strategy the Google client libraries (and gcloud when impersonating) use to find credentials automatically, without you hard-coding anything. The library searches, in this fixed order, and uses the first source it finds:

The beauty of ADC is write once, run anywhere: the same application code authenticates correctly on your laptop (via step 2) and in production on Cloud Run (via step 3) with no code change — only the environment differs. This is why you should never see credentials hard-coded in well-written GCP code; the library finds them through ADC.

The third source deserves emphasis. Every VM, GKE node, Cloud Run instance and Cloud Function has a metadata server at http://metadata.google.internal that vends short-lived OAuth tokens for the resource’s attached service account. Because these tokens are minted on demand and expire quickly, there is no long-lived secret to leak — which is exactly why running on GCP is the gold standard for authentication.

Service-account impersonation — the modern alternative to keys

You often want to act as a service account from your own authenticated session — to test what that account can do, or to run an admin task with a tightly scoped identity — without ever creating a key. Impersonation does this:

# One command, run as the service account:
gcloud storage buckets list \
  --impersonate-service-account=deployer@my-project.iam.gserviceaccount.com

# Or make every gcloud command impersonate, via a property:
gcloud config set auth/impersonate_service_account deployer@my-project.iam.gserviceaccount.com

# Generate ADC that impersonate an SA (so local *code* runs as that SA):
gcloud auth application-default login \
  --impersonate-service-account=deployer@my-project.iam.gserviceaccount.com

To impersonate, your user needs the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) on the target service account. Behind the scenes Google mints a short-lived token for the service account — again, no downloadable secret exists. Impersonation is the recommended way to “become” a service account for local work and scripts.

Why downloaded service-account keys are discouraged

A service-account key is a downloadable JSON file containing a private key that authenticates as the service account. It works, but it is the highest-risk credential on Google Cloud, and Google now actively discourages it:

• It is a long-lived secret in a file — if it leaks (committed to git, pasted in a ticket, left in a Docker image), anyone holding it has that account’s permissions until the key is found and disabled. (This is exactly the class of incident behind leaked-credentials post-mortems.)
• It does not rotate automatically; you must manage rotation yourself.
• It encourages bad patterns — keys copied between laptops, baked into images, emailed around.

The alternatives, in order of preference:

1. Run on GCP and use the attached service account via the metadata server — no key at all.
2. For external/CI systems (GitHub Actions, on-prem, other clouds), use Workload Identity Federation — exchange the external system’s own token for short-lived Google credentials, again with no key.
3. For “become this SA” locally, use impersonation (above).
4. Only as a genuine last resort, create a key — and then guard it, rotate it, and prefer an Organisation Policy (iam.disableServiceAccountKeyCreation) that blocks key creation entirely except where justified.

The one-line rule for the exam and for life: prefer keyless authentication; treat a service-account key as a liability, not a convenience.

Core concept: Cloud Shell and the Cloud Shell Editor

Cloud Shell is a free, browser-based Linux command line, pre-loaded with the Cloud SDK (gcloud, gsutil, bq, kubectl), Docker, Python, Go, Java, Node and the major build tools — and pre-authenticated as your user account, so you can run gcloud immediately with nothing to install. Activate it from the terminal icon in the top bar of the Console.

Key facts to know (several are examinable):

The Cloud Shell Editor is a full browser-based code editor (based on the same technology as VS Code) launched with cloudshell edit <file> or the Open Editor button. It gives you a file tree, syntax highlighting, an integrated terminal, source control and even debugging — a genuine cloud workstation for editing Terraform, scripts and app code without anything installed locally. Because the home directory persists, your repo and dotfiles survive between sessions; because the VM does not, treat anything outside $HOME as disposable.

Cloud Shell is ideal for: following this course, quick admin tasks, demos, and any time you are on a machine where you cannot (or do not want to) install the SDK.

Core concept: the client libraries

When your application needs to call Google Cloud — read a Cloud Storage object, publish to Pub/Sub, query BigQuery — you use the Cloud Client Libraries: idiomatic, officially supported SDKs for Python, Go, Java, Node.js, C#, Ruby, PHP and more. They are preferred over hand-rolling REST calls because they provide language-native objects, automatic retries with back-off, pagination helpers, and — crucially — automatic ADC-based authentication.

A minimal Python example shows how little authentication code you write (none):

from google.cloud import storage

# No credentials in code — the library finds them via ADC:
# locally → your `application-default login`; on GCP → the attached SA.
client = storage.Client()
for bucket in client.list_buckets():
    print(bucket.name)

Install with the language’s package manager (pip install google-cloud-storage, go get cloud.google.com/go/storage, etc.). The same binary runs unchanged on your laptop and on Cloud Run because ADC resolves credentials from the environment. (An older generation, the Google API Client Libraries, still exists for some APIs; prefer the Cloud Client Libraries where available.)

Core concept: the specialised tools — gsutil and bq

Two product-specific CLIs ship with the SDK and appear constantly:

• gsutil — the long-standing CLI for Cloud Storage: copy, move, sync, set ACLs and lifecycle, manage buckets.

  gsutil mb -l europe-west2 gs://my-unique-bucket-name   # make bucket
  gsutil cp ./report.csv gs://my-unique-bucket-name/     # upload
  gsutil ls gs://my-unique-bucket-name/                  # list
  gsutil rsync -r ./site gs://my-unique-bucket-name/site # sync a tree
  

  Note: Google now also offers gcloud storage, a newer, often faster unified interface to Cloud Storage built into gcloud (e.g. gcloud storage cp …). For new work prefer gcloud storage; gsutil remains widely used and fully supported.

• bq — the CLI for BigQuery: run queries, load and export data, manage datasets and tables.

  bq query --use_legacy_sql=false 'SELECT COUNT(*) FROM `bigquery-public-data.samples.shakespeare`'
  bq ls                      # list datasets
  bq mk my_dataset           # make a dataset
  bq load ...                # load data into a table
  

Both honour your active gcloud configuration and authentication, so once you have run gcloud init they are ready to use.

From gcloud to Infrastructure as Code

gcloud is perfect for learning, exploring and one-off tasks — but typing commands (or, worse, clicking the Console) to build production infrastructure is not repeatable, reviewable or recoverable. The professional progression is:

1. Console — to discover and understand a service.
2. gcloud — to do it quickly and to read the “equivalent command line” the Console offers.
3. Infrastructure as Code — to define infrastructure declaratively in version control, so it is reviewed in pull requests, applied consistently, and reproducible across environments.

For IaC on Google Cloud you have:

A useful bridge: gcloud can emit a Terraform skeleton for some resources, and the Console’s “equivalent command line” plus --format=json make it easy to translate what you built by hand into code. The mindset shift to internalise: interactive tools for learning and break-glass; IaC for anything that must last. This course teaches gcloud so you understand the platform, then moves you to Terraform for everything you build to keep.

The diagram shows the four front doors — Console, gcloud CLI, Cloud Shell and the client libraries — all calling the same Google Cloud APIs, with the authentication layer (user login, ADC, the metadata server’s attached service account, impersonation and federation) sitting underneath every one of them.

Hands-on lab: drive gcloud, switch configurations, and authenticate code

You will run everything in Cloud Shell (zero install) using the Free Tier / $300 credit. Every step here is free — you create no chargeable resources.

Step 1 — Open Cloud Shell and confirm you are authenticated

In the Console, click the Activate Cloud Shell icon (top bar). When it opens:

gcloud auth list          # shows your account as ACTIVE (Cloud Shell is pre-authenticated)
gcloud config list        # shows the active configuration's properties
gcloud version            # SDK and component versions

Step 2 — Set the project and a default region

export PROJECT_ID=$(gcloud config get-value project)   # or: gcloud projects list
gcloud config set project "$PROJECT_ID"
gcloud config set compute/region europe-west2
gcloud config set compute/zone europe-west2-a
gcloud config list                                     # confirm they are set

Step 3 — Create and switch a named configuration

gcloud config configurations create lab          # creates and activates "lab"
gcloud config configurations list                # see [lab] ACTIVE alongside [default]
gcloud config set project "$PROJECT_ID"          # set project inside "lab"
gcloud config configurations activate default    # switch back
gcloud config configurations activate lab        # and back to lab

You now have two independent profiles you can flip between — exactly how you would separate dev and prod, or two clients.

Step 4 — Use --format and --filter as a data tool

# List all enabled APIs as bare values (machine-readable):
gcloud services list --enabled --format="value(config.name)"

# List your projects filtered and as a custom table:
gcloud projects list --filter="lifecycleState=ACTIVE" \
  --format="table(projectId, name, projectNumber)" --sort-by=projectId

# Pull a single field as JSON, then with a value() projection:
gcloud projects describe "$PROJECT_ID" --format=json | head -20
gcloud projects describe "$PROJECT_ID" --format="value(projectNumber)"

Step 5 — Set up Application Default Credentials for code

# Create ADC so client libraries (your code) can authenticate as you:
gcloud auth application-default login    # follow the link/consent flow

# A tiny Python program that uses ADC — no credentials in the code:
python3 - <<'PY'
import google.auth
creds, project = google.auth.default()
print("ADC resolved. Active project:", project)
PY

This proves the ADC flow: the library found credentials automatically. (In Cloud Shell, ADC may already resolve via the environment; the explicit login makes the mechanism visible.)

Step 6 — Try impersonation (read-only, safe)

If you have (or create, per the IAM lesson) a service account you may impersonate, list buckets as it without any key:

# Replace with a real SA you have Token Creator on; otherwise skip this step.
gcloud storage buckets list \
  --impersonate-service-account=SA_EMAIL 2>&1 | head

A PERMISSION_DENIED here simply means you lack roles/iam.serviceAccountTokenCreator on that SA — which is the correct, secure default.

Step 7 — Validation

gcloud config configurations list          # two configurations exist; one ACTIVE
gcloud config get-value project            # your project
gcloud auth list                           # your account is ACTIVE

Step 8 — Cleanup

No chargeable resources were created, so cleanup is just tidying CLI state:

gcloud config configurations activate default   # leave default active
gcloud config configurations delete lab         # remove the practice configuration
gcloud auth application-default revoke           # optional: remove local ADC

Cost note: every step in this lab is free. Cloud Shell itself is free, and you created no billable resources (no VMs, disks or buckets with data). The only things to “clean up” are local CLI configurations and credentials. The lab leaves nothing billing.

Common mistakes & troubleshooting

Best practices

• Use named configurations for each project/identity context and switch deliberately; never trust that the “current” project is what you assume — check gcloud config list.
• Prefer keyless authentication everywhere: attached service accounts on GCP, Workload Identity Federation for external/CI, and impersonation for local “become an SA” work. Treat downloaded keys as a last resort.
• Know your two logins: gcloud auth login for the CLI, gcloud auth application-default login for code. Most “credentials” errors are using the wrong one.
• Master --format and --filter — they make gcloud scriptable and turn ad-hoc questions into one-liners; use --quiet in automation.
• Learn from the Console’s “equivalent command line” when a service is new to you, then graduate the command into a script or Terraform.
• Keep the SDK current (gcloud components update) so you have new flags and security fixes; install alpha/beta only when you need pre-GA features.
• Move durable infrastructure to IaC (Terraform / Config Connector) early; reserve interactive gcloud for learning and break-glass.
• Use Cloud Shell for anything you would otherwise install locally just to try once — it is free, current and pre-authenticated.

Security notes

• Service-account keys are the highest-risk credential on the platform. Avoid them; if one exists, ensure it is rotated and tightly held, and prefer an Organisation Policy that disables key creation.
• ADC + the metadata server means no long-lived secret on GCP — short-lived tokens are minted per workload and expire quickly. This is why running on GCP is the most secure place for your code to authenticate.
• Impersonation requires Token Creator on the target SA — grant it narrowly and audit it; impersonation events are logged.
• Least privilege applies to service accounts too: grant a workload’s SA only the roles it needs, and never reuse the over-powered default service accounts for real workloads.
• gcloud auth login stores a token on the machine — on shared or untrusted machines, prefer Cloud Shell and revoke credentials when done (gcloud auth revoke).
• Cloud Audit Logs record admin and (optionally) data-access activity performed via any interface; ensure they are retained so CLI and API actions are attributable.
• Never commit credentials. ADC and impersonation exist precisely so that well-written code and scripts contain no secrets.

Interview & exam questions

1. What is the difference between gcloud auth login and gcloud auth application-default login? gcloud auth login authenticates your user for the gcloud/gsutil/bq CLI tools. gcloud auth application-default login creates Application Default Credentials that the client libraries (your code) discover automatically during local development. CLI tools use the first; application code uses the second.

2. Explain Application Default Credentials and the credential search order. ADC is the strategy client libraries use to find credentials automatically. The order is: (1) the GOOGLE_APPLICATION_CREDENTIALS env var, (2) user credentials from application-default login, (3) the attached service account via the metadata server. The first found is used — so the same code authenticates on a laptop and on GCP with no change.

3. Why are downloaded service-account keys discouraged, and what are the alternatives? They are long-lived secrets in a file that do not auto-rotate and are easily leaked, granting the SA’s permissions to anyone who finds them. Prefer keyless options: the attached SA on GCP (metadata server), Workload Identity Federation for external/CI systems, and impersonation for local use.

4. What is service-account impersonation and what permission does it require? Impersonation lets your authenticated user (or another SA) obtain a short-lived token to act as a target service account, with no key. It requires roles/iam.serviceAccountTokenCreator on the target SA. Use --impersonate-service-account or the auth/impersonate_service_account property.

5. What are gcloud configurations and properties, and what is the precedence between a flag, an env var and a config property? A configuration is a named set of properties (account, project, region, …); you keep several and switch with gcloud config configurations activate. Precedence, highest first: a command-line flag (--project) > an environment variable (CLOUDSDK_CORE_PROJECT) > the active configuration’s stored property.

6. How would you list only running VMs in one zone and output just their names? Combine --filter and --format: gcloud compute instances list --filter="status=RUNNING AND zone:europe-west2-a" --format="value(name)".

7. What is Cloud Shell, and what are its key limits? A free, pre-authenticated browser terminal with the SDK pre-installed. It runs on an ephemeral VM, persists only the 5 GB $HOME between sessions (everything else is wiped), times out when idle, and has a weekly usage quota.

8. What is the metadata server and why does it matter for authentication? Every GCP compute resource has a metadata server (metadata.google.internal) that vends short-lived OAuth tokens for the resource’s attached service account. Because tokens are minted on demand and expire, there is no long-lived secret to leak — the most secure way for on-GCP code to authenticate.

9. A teammate’s Python script fails with “could not determine credentials,” though gcloud compute instances list works for them. What is wrong and how do you fix it? They have CLI credentials (gcloud auth login) but no ADC. The client library needs ADC, so run gcloud auth application-default login (locally) or run the code on GCP with an attached service account.

10. When do you choose the Console vs gcloud vs Terraform? Console for discovery, dashboards and one-off visual tasks; gcloud for fast, scriptable, repeatable actions and learning via the “equivalent command line”; Terraform (IaC) for anything durable that must be reviewed, reproduced and version-controlled.

11. What is the difference between a Cloud Client Library and the gcloud CLI? The gcloud CLI is for interactive/administrative tasks from a shell; the client libraries are language SDKs your application uses to call GCP APIs idiomatically, with retries and ADC-based auth built in.

12. How do gsutil, gcloud storage and bq relate to the SDK? All ship with the Cloud SDK. gsutil is the established Cloud Storage CLI; gcloud storage is the newer, often faster unified Storage interface inside gcloud; bq is the BigQuery CLI. All honour your active gcloud configuration and authentication.

Quick check

1. True or false: after gcloud auth login, your Python client-library code is automatically authenticated.
2. Which command outputs only the value(s) of a field, ideal for scripts: --format=json, --format="value(...)", or --filter?
3. In ADC’s search order, what is checked last — the GOOGLE_APPLICATION_CREDENTIALS env var, or the attached service account via the metadata server?
4. How much of Cloud Shell persists between sessions, and where?
5. Which IAM role lets your user impersonate a service account?

Answers: 1. False — that authenticates the CLI; code needs ADC via gcloud auth application-default login (or an attached SA on GCP). 2. --format="value(...)" prints bare field values; --filter selects rows, --format=json prints full JSON. 3. The attached service account via the metadata server is last (env var first, then user ADC, then metadata). 4. The 5 GB $HOME directory persists; everything outside it is wiped. 5. roles/iam.serviceAccountTokenCreator on the target service account.

Exercise

Using Cloud Shell and your sandbox project, do the following and write down the command for each (no chargeable resources needed):

1. Create two configurations, dev and ops, each with the same project but different default zones; switch between them and prove which is active.
2. With one gcloud command, list all enabled APIs in the project as bare names, sorted.
3. With one gcloud command, output only your project number.
4. Set up ADC and run a three-line Python snippet that prints the project ADC resolved.
5. Explain, in two sentences each, when you would use (a) an attached service account, (b) Workload Identity Federation, and © a downloaded key — and why © should be rare.

Compare your answers against the precedence rule (flag > env > config) and the “prefer keyless authentication” principle.

Certification mapping

• Cloud Digital Leader (CDL): the value of the managed tooling and the basics of how you interact with Google Cloud (Console, CLI, Cloud Shell) and the principle of secure, identity-based access support the Infrastructure & application modernisation and trust & security areas.
• Associate Cloud Engineer (ACE): Setting up a cloud solution environment and Managing/operating resources — installing and configuring the Cloud SDK, using gcloud configurations and properties, the Console and Cloud Shell, service accounts, ADC, impersonation and keyless authentication are core, hands-on ACE skills that appear directly on the exam.

Glossary

• Cloud SDK / Google Cloud CLI — the downloadable bundle containing gcloud, gsutil, bq and the components manager.
• gcloud — the unified command-line tool for managing Google Cloud services.
• Configuration — a named set of CLI properties (account, project, region, …) you can switch between.
• Property — one CLI setting within a configuration, e.g. core/project or compute/zone.
• Cloud Shell — a free, pre-authenticated browser terminal with the SDK pre-installed and a persistent 5 GB home directory.
• Cloud Shell Editor — the browser-based code editor (VS Code-style) bundled with Cloud Shell.
• Client library — a language-native SDK (Python, Go, …) applications use to call GCP APIs, with ADC-based auth.
• Service account — a non-human Google identity that workloads use to authenticate and be authorised via IAM.
• Application Default Credentials (ADC) — the strategy client libraries use to find credentials automatically (env var → user ADC → metadata server).
• Metadata server — the per-resource endpoint (metadata.google.internal) that vends short-lived tokens for an attached service account.
• Impersonation — obtaining a short-lived token to act as a service account, requiring Token Creator; the keyless alternative to keys.
• Service-account key — a downloadable JSON private key authenticating as an SA; long-lived and high-risk, hence discouraged.
• Workload Identity Federation — exchanging an external system’s token for short-lived Google credentials, with no key.
• gsutil / gcloud storage — the established and the newer CLI for Cloud Storage. bq — the BigQuery CLI.
• Infrastructure as Code (IaC) — defining infrastructure declaratively in version control (Terraform, Config Connector).

Next steps

With the tooling and authentication model in hand, you are ready to provision real infrastructure. Continue to Google Compute Engine, In Depth: Machine Types, Disks, Images, Metadata & Every Option, where you will use the gcloud skills from this lesson to create and configure virtual machines end to end. The authentication concepts here — service accounts, ADC, impersonation and keyless access — recur in every later lesson on IAM, GKE, Cloud Run and CI/CD.