Interfaces & gcloud

Exam guide§1

Interfaces

There are four ways to reach the same resources - pick the one that fits the task, they all drive the same APIs underneath.

The four interfaces to Google Cloud

Cloud console

The console is the web GUI at console.cloud.google.com - a point-and-click view of every resource in your projects (VMs, buckets, billing, and so on).

Navigation menu → Compute Engine → VM instances

Cloud Shell + CLI

The gcloud CLI does the same as the console from a terminal (e.g. gcloud compute instances list) - see the gcloud section below for its command families and configuration model. Cloud Shell is a browser terminal you open from the console - a temporary VM with 5 GB of persistent disk and the CLI pre-installed, so you never install anything locally. It also offers web preview to test web apps running on the Shell VM over a temporary URL.

Same resources, two views: console GUI and gcloud CLI

⚠GotchaCloud Shell is ephemeral - only $HOME persists

The VM is recycled after 1 hour of inactivity, and closing the terminal resets it. Only the /home directory (5 GB) survives; env vars, installed packages, and system config are lost. A new VM is allocated each session.

REST API + libraries

Beyond the CLI, client libraries let your code create and manage resources. They expose two kinds of API:

• App APIs - access to services, optimised per language (Node.js, Python, …).
• Admin APIs - resource management, for building your own automation tools.

The libraries wrap Google Cloud's RESTful API (GET/POST/PUT/DELETE, JSON), and OAuth 2 handles authentication.

The console's APIs Explorer lists every available API and version and lets you call them interactively in the browser - including calls that require user authentication - which is handy for learning an API before you write code.

Your code reaches Google Cloud through the CLI or client libraries - both call the same REST API

Cloud Mobile App

Manage Google Cloud from an Android or iOS device: start, stop, and SSH into Compute Engine instances, manage database instances and App Engine apps, read logs, chart key metrics (CPU, network, requests/sec, server errors) on a customizable project dashboard, handle incident management, and get billing and budget alerts. Free from Google Play or the App Store.

Cloud Marketplace

Cloud Marketplace deploys pre-configured, ready-to-run solutions (a LAMP stack, WordPress, Jenkins, and so on) with no manual VM, network, or storage setup. It gets its own page - see Cloud Marketplace.

gcloud

The gcloud CLI is the primary command-line tool for Google Cloud: a set of command families, named configurations that bundle your defaults, and its own authentication model.

Command families

gcloud <group> <command> # most GCP services

gsutil # Cloud Storage (legacy, still tested)

gcloud storage # newer Cloud Storage CLI

bq # BigQuery

kubectl # Kubernetes / GKE (configured via gcloud)

⇄Comparegsutil is the storage tool, gcloud is everything else

gsutilBuckets and objects (or `gcloud storage`).

bqBigQuery.

kubectlGKE workloads.

gcloudEverything else - and it wires the others together.

Picking the wrong tool for the resource is a classic distractor.

Configurations

A configuration is a named bundle of account, project, and default region/zone. Switching configs is how you jump between projects or identities without retyping flags.

CommandsSet up and switch

gcloud init # interactive first-time setup

gcloud auth login # authenticate a user

gcloud auth list # show accounts, * marks the active one

gcloud config set project my-proj-id

gcloud config set compute/zone us-central1-a

gcloud config get-value project # read one setting from the active config

gcloud config configurations create staging # a second named config

gcloud config configurations activate staging

gcloud config list # show the active config

CommandsMake env vars survive Cloud Shell recycling

# store values once, in a file under $HOME

mkdir -p ~/infraclass

echo INFRACLASS_REGION=us-central1 >> ~/infraclass/config

echo INFRACLASS_PROJECT_ID=my-proj-id >> ~/infraclass/config

 

# auto-load on every new shell: add to ~/.profile

echo 'source ~/infraclass/config' >> ~/.profile

Without the .profile line you'd have to re-source the file every session. Env vars cut typos in repeated gcloud flags (region/zone/project).

Authentication

⇄CompareAuth: user vs service account

User`gcloud auth login` - interactive credentials (your laptop, Cloud Shell).

Service account`gcloud auth activate-service-account --key-file=key.json` - for scripts/CI.

Prefer attached service accounts or Workload Identity over downloaded keys.

Recap

?DECISIONWhich tool for the task?

Explore a service you've never used→Console

Quick command with nothing installed locally→Cloud Shell

Scripted / repeatable / CI→gcloud (+ service account)

Inside application code→Client library

Pick this when: match the task shape to the tool