Getting Started with Google Cloud

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

See the section bibliography for the reference material consulted while preparing these pages.

Examples on this page target the gcloud CLI (release 586.0.0 of 2026-09-22 at the time of writing, verified against the official release notes) and the Google Cloud Client Libraries for Java. Command names and flags are stable across releases, but run gcloud components update (or update through your package manager) before following along if a command reports itself as missing. Free program terms, limits and prices change from time to time, so re-check the linked official pages before relying on them. Official documentation now lives on docs.cloud.google.com; older cloud.google.com links redirect there.

From account to configuration

Getting productive on Google Cloud is a short chain of steps. Each one has a decision attached, and each one is reused by every later page of this section:

  1. Sign in with a Google Account (or a Cloud Identity / Google Workspace account managed by your organization) and accept the terms.

  2. Create a billing account, which also starts the free trial if you are eligible. A billing account pays for usage; it holds no resources.

  3. Create a project, the unit that owns resources, APIs, IAM policy and quotas, and link it to the billing account.

  4. Install the gcloud CLI, sign in with gcloud init, and keep the project, region and zone in a named configuration.

  5. Run gcloud auth application-default login once so that code on your machine can use Application Default Credentials (ADC).

flowchart LR A["Google Account\nor Cloud Identity user"] --> B["Billing account\n(free trial, payment profile)"] B --> C["Project\n(ID, name, number)"] C --> D["Enable APIs\n(gcloud services enable)"] D --> E["gcloud init\n(named configuration:\nproject, region, zone)"] E --> F["gcloud auth login\n(CLI credentials)"] E --> G["gcloud auth application-default login\n(ADC for local code)"] F --> H["gcloud, bq, kubectl\ncommands"] G --> I["Client libraries\nand frameworks"]

Projects, folders and organizations are covered in depth in Resource Hierarchy and Projects, and the identities used throughout in Identity and Access.

Creating an account and the first project

Anyone with a Google Account can use Google Cloud. Companies normally sign up through a Cloud Identity or Google Workspace domain instead, so that users, groups and the organization resource are managed centrally. A personal account has no organization: its projects sit directly at the top of the resource hierarchy, which is fine for learning but not for a team.

Three identifiers describe a project and they are easy to confuse:

  • The project name is a free-form label you can change.

  • The project ID is globally unique, chosen at creation, and cannot be changed. This page uses the placeholder my-project-id; it is what gcloud and Terraform expect.

  • The project number is assigned by Google and appears in service-agent and default service account names.

Create one project per application per life-cycle stage (for example one for Bookshelf development and another for production). Quotas, IAM bindings, enabled APIs and billing then stay isolated, and deleting a throwaway project removes everything inside it.

In the Google Cloud console

  1. Open the Google Cloud console at console.cloud.google.com and sign in. On the first visit, accept the terms of service.

  2. If the Get started for free banner appears, choose it, review the country and account type, add a payment method and confirm. A card is required to prove you are not a robot; you are not charged during the trial.

  3. Open the project picker at the top left of the console and choose New project.

  4. Enter a project name, check the generated project ID (choose Edit if you want a different one), select the organization or folder if you have one, and choose Create.

  5. Open the navigation menu, then Billing, and verify the project is linked to your billing account. If not, choose Link a billing account.

With the gcloud CLI

Account sign-up is console-only, but projects and the billing link can be scripted once the CLI is installed (see below):

# Create a project (the ID must be globally unique) and make it the default for the active configuration
PROJECT_ID=my-project-id
gcloud projects create "$PROJECT_ID" --name="Bookshelf Dev"
gcloud config set project "$PROJECT_ID"

# Link it to a billing account (listing billing accounts needs the Billing Account Viewer role or better)
gcloud billing accounts list
gcloud billing projects link "$PROJECT_ID" --billing-account=BILLING_ACCOUNT_ID

# Show the project ID, name and number
gcloud projects describe "$PROJECT_ID" --format="value(projectId,name,projectNumber)"

References: gcloud projects create, gcloud billing projects link, Creating and managing projects.

The free trial and the Always Free tier

Google Cloud has two separate free programs, both described on the official Free Program page.

Program What it gives you

Free trial

A $300 credit valid for 90 days, for new customers. You are not charged automatically when it ends: resources stop unless you upgrade to a paid billing account, and Google keeps the data for a further 30 days before it is deleted. Some things are excluded: GPUs, Windows Server VMs, Google Cloud Marketplace purchases, some generative AI partner models and quota increases.

Always Free

Monthly usage allowances for selected products that never expire and are available on a paid account too. They include one e2-micro VM in selected US regions, a small amount of Cloud Storage, Cloud Run requests and compute time, 1 TiB of BigQuery queries per month, Firestore, Pub/Sub and Secret Manager allowances, and a free-of-charge cluster management fee for one GKE Autopilot or zonal cluster.

Allowances are per billing account and usually restricted to specific regions and units, so read the fine print of each product. Every later page of this section states the free tier of the product it covers. A few habits keep a learning account cheap:

  • Stay inside Always Free limits where you can, and prefer small or serverless resources that scale to zero.

  • Add a budget alert on day one (below). Budgets alert; they do not cap spending. Spend-cap budgets exist only as a Preview feature.

  • Follow the Clean up section of every hands-on page, or delete the whole throwaway project.

Billing is per second for many compute products. The cost-estimation tools, billing reports and committed-use discounts are covered in Cost Management and Billing.

Setting a first budget alert

A budget with email alerts is the cheapest safety net you can install.

In the Google Cloud console

  1. Open the navigation menu, then Billing, choose your billing account, then Budgets & alerts.

  2. Choose Create budget and give it a name such as learning-budget.

  3. Under Scope, leave all projects selected (or choose only your learning project), then choose Next.

  4. Under Amount, choose Specified amount and enter, for example, 10 in your billing currency.

  5. Under Actions, keep the default alert thresholds (50%, 90% and 100% of the budget) and make sure email notifications to billing administrators are enabled, then choose Finish.

With the gcloud CLI

# Requires the Billing Budgets API and the Billing Account Administrator role on the billing account
gcloud services enable billingbudgets.googleapis.com

gcloud billing budgets create \
  --billing-account=BILLING_ACCOUNT_ID \
  --display-name="learning-budget" \
  --budget-amount=10USD \
  --threshold-rule=percent=0.5 \
  --threshold-rule=percent=0.9 \
  --threshold-rule=percent=1.0

References: Create, edit, or delete budgets and budget alerts, gcloud billing budgets create.

The Google Cloud console

The console is a good place to explore a service, inspect what a command created, and read logs and charts. These are the parts worth knowing on day one:

  • The navigation menu (the hamburger icon) lists every product grouped by category. Pin the products you use often so they stay at the top.

  • The search bar finds products, resources, documentation and even gcloud commands. It is usually faster than the menu.

  • The project picker next to the logo shows the active project. Many "I can’t find my resources" problems are the wrong project selected here.

  • The notifications icon shows the status of long-running operations, and the Activity page lists recent actions in the project.

  • The Cloud Shell button opens a terminal and editor in the browser (next section).

  • Gemini Cloud Assist can answer questions and help investigate issues from within the console. At the time of writing it is a Preview feature, so check the launch stage before relying on it.

  • A Dashboard with cards such as project info, resources and the billing summary is available from the home page.

Most create flows end with an Equivalent command line or Equivalent REST link. Use it to learn the matching gcloud command, then move repeatable work into scripts and Terraform as shown in Infrastructure as Code.

Products and features move through launch stages (Preview, then General Availability, with deprecation and shutdown at the end of life). Preview features have no SLA and may change incompatibly. Every page of this section notes the stage of anything that is not yet generally available.

Cloud Shell and Cloud Shell Editor

Cloud Shell is a free, preauthenticated Linux shell that runs on a Google-managed VM and opens in the browser. It comes with the gcloud CLI, kubectl, bq, Git, Docker, Terraform, Java, Python, Node.js and more already installed, and it is already signed in as you.

Limit Value (verify on the quotas page)

Weekly usage

50 hours per week. After that, wait for the quota to reset or move to Cloud Workstations.

Home directory

5 GB of persistent disk. It is deleted if you do not use Cloud Shell for 120 days.

Session

Idle sessions are ended, the VM itself is temporary (only $HOME persists), and a session lasts at most 12 hours.

Editor

Cloud Shell Editor is a Code OSS based IDE in the browser. It does not support installing arbitrary extensions.

Cloud Shell is excellent for tutorials and one-off administration, and it needs nothing installed locally. For daily development, Cloud Workstations is the step up: managed, configurable development environments with your own images, IDEs and no weekly cap. Neither replaces a local installation for scripting against your own machine.

In the Google Cloud console

  1. Choose the Activate Cloud Shell icon (a terminal prompt) at the top right of the console. A terminal opens at the bottom of the page the first time you do this and provisions a VM.

  2. Choose Authorize if the shell asks for permission to use your credentials.

  3. Choose Open Editor to open Cloud Shell Editor, or Open in new window for a full-size terminal.

  4. In the terminal, run gcloud config list to see which project the shell is using.

With the gcloud CLI

# Inside Cloud Shell the CLI is already installed and authenticated; just check the context
gcloud auth list
gcloud config list

# Cloud Shell can also be driven from your own terminal, using the installed CLI
gcloud cloud-shell ssh

References: Use Cloud Shell, Cloud Shell quotas and limits, Cloud Shell Editor, Cloud Workstations.

Compute Engine VMs started from the console or CLI run as the default Compute Engine service account unless you attach another one. Code that runs in Cloud Shell or on a VM therefore may have far more access than you intend, which is why the identity page recommends dedicated service accounts with minimal roles.

Installing the gcloud CLI

The gcloud CLI is the command line for almost every Google Cloud product. It requires a supported Python version (a bundled one is included in the standard installers), and it installs the companion tools bq and the Cloud Storage commands in gcloud storage. Pick the installer that suits your platform:

# macOS or Linux, interactive installer script (downloads the archive and offers to update PATH)
curl https://sdk.cloud.google.com | bash
exec -l "$SHELL"

# macOS with Homebrew
brew install --cask gcloud-cli

# Debian/Ubuntu from the Google apt repository (after adding the repository and key as documented)
sudo apt-get update && sudo apt-get install google-cloud-cli

# RHEL/Fedora from the Google yum/dnf repository (after adding the repository as documented)
sudo dnf install google-cloud-cli

On Windows, download and run the Google Cloud CLI installer from the install page (it can also install Python and a PowerShell shortcut). Containers can use the gcr.io/google.com/cloudsdktool/google-cloud-cli image. Always follow the exact repository and key steps on the official install page for your distribution, because they change over time.

# Verify the installation and see the installed components
gcloud version

# Update the CLI itself (when installed with the archive or installer) and manage optional components
gcloud components update
gcloud components list
gcloud components install kubectl gke-gcloud-auth-plugin

References: Install the gcloud CLI, gcloud CLI release notes, Managing gcloud CLI components.

When the CLI is installed through a package manager (apt, yum, Homebrew), gcloud components is disabled and you update and add components through the package manager instead, for example sudo apt-get install kubectl google-cloud-cli-gke-gcloud-auth-plugin.

Signing in, configurations and defaults

gcloud init is the guided first-run setup. It signs you in through the browser, asks which project to use, and offers a default Compute Engine region and zone. Under the hood it creates a named configuration, which is a set of properties (account, project, region, zone, and more) stored on your machine.

# First-run wizard: sign in, pick the project, choose default region and zone
gcloud init

# Or step by step
gcloud auth login
gcloud config set project my-project-id
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

# Inspect the active configuration and the credentialed accounts
gcloud config list
gcloud auth list

Named configurations let you switch between projects or accounts without retyping properties, for example a personal learning project and a customer project:

# Create and switch configurations
gcloud config configurations create bookshelf-dev
gcloud config set project my-project-id
gcloud config set account you@example.com

gcloud config configurations list
gcloud config configurations activate default

# Apply a configuration to a single command without activating it
gcloud compute instances list --configuration=bookshelf-dev

# Override one property for one command
gcloud storage ls --project=my-project-id

References: Initializing the gcloud CLI, Managing gcloud CLI configurations, gcloud config, gcloud auth login.

Values are resolved from the most specific source: a command flag (--project), then the CLOUDSDK_* environment variables (for example CLOUDSDK_CORE_PROJECT), then the active configuration. The same ordering lets scripts and CI override a developer’s defaults. On a machine without a browser, use gcloud auth login --no-browser and follow the instructions it prints,.

For automation, do not use gcloud auth login with a downloaded service-account key. Organizations created on or after 2024-05-03 have secure-by-default organization policies that block service-account key creation. Use Workload Identity Federation in CI, attached service accounts on Google Cloud, and impersonation locally (see below and Identity and Access).

Using the gcloud CLI effectively

The command grammar

Commands follow the pattern gcloud <service> <resource> <verb> [positional] [--flags], with an optional release track before the service:

gcloud compute instances list                  # service: compute, resource: instances, verb: list
gcloud run services describe catalog-api --region=us-central1
gcloud storage buckets create gs://my-bucket-name --location=us-central1
gcloud iam service-accounts list
gcloud beta run services list                  # beta release track
gcloud alpha storage --help                    # alpha release track

Discoverability is built in: gcloud help, gcloud <group> --help, gcloud <command> --help, and gcloud interactive for a shell with auto-completion and inline help. Standard verbs are list, describe, create, update, delete, add-iam-policy-binding and get-iam-policy. The alpha and beta command groups mirror launch stages: beta commands are close to GA, and alpha commands are early and can change without notice. Most services need their API enabled before the first use, which is why each page of this section begins with gcloud services enable:

gcloud services enable run.googleapis.com artifactregistry.googleapis.com
gcloud services list --enabled --format="value(config.name)"

References: gcloud CLI overview, gcloud reference, Enabling and disabling services, gcloud CLI cheat sheet.

Formatting, filtering and scripting

Every list and describe command accepts --format (output shape) and --filter (server-side or client-side selection). Together with --quiet for non-interactive scripts, they replace most uses of grep and awk:

# Table with selected columns
gcloud compute instances list \
  --format="table(name, zone.basename(), status, networkInterfaces[0].networkIP)"

# A single value, ready for a shell variable
PROJECT_ID=$(gcloud config get-value project)
REGION=us-central1

# Filter, then print one value per line
gcloud run services list --region="$REGION" \
  --filter="metadata.name~^catalog" --format="value(metadata.name)"

# JSON or YAML for further processing with jq or yq
gcloud projects describe "$PROJECT_ID" --format=json
gcloud projects describe "$PROJECT_ID" --format=yaml

# Skip confirmation prompts in scripts
gcloud storage buckets delete gs://my-bucket-name --quiet

References: gcloud topic formats, gcloud topic filters, gcloud topic projections.

Companion tools

Cloud Storage: gcloud storage instead of gsutil

Older books and tutorials use gsutil. It is now described as a legacy tool in minimal maintenance mode, it lacks newer Cloud Storage features such as soft delete and managed folders, and after March 2027 it will no longer ship with the gcloud CLI (it will remain available from PyPI). Use gcloud storage, which is faster and enables parallel composite uploads automatically for large files, so the -m flag and .boto tuning from older guides are unnecessary.

Legacy gsutil Current gcloud storage

gsutil mb gs://my-bucket-name

gcloud storage buckets create gs://my-bucket-name

gsutil ls gs://my-bucket-name

gcloud storage ls gs://my-bucket-name

gsutil -m cp -r ./site gs://my-bucket-name

gcloud storage cp --recursive ./site gs://my-bucket-name

gsutil rsync -r ./site gs://my-bucket-name

gcloud storage rsync --recursive ./site gs://my-bucket-name

gsutil rm -r gs://my-bucket-name

gcloud storage rm --recursive gs://my-bucket-name

References: Discover object storage with the gcloud CLI, gsutil tool, gcloud storage reference.

Buckets are covered in Cloud Storage.

BigQuery: bq

bq is the BigQuery command line, installed with the gcloud CLI and sharing its credentials:

gcloud services enable bigquery.googleapis.com

# Run a query against a public dataset (standard SQL is the default)
bq query --use_legacy_sql=false \
  'SELECT name, SUM(number) AS total FROM `bigquery-public-data.usa_names.usa_1910_2013` GROUP BY name ORDER BY total DESC LIMIT 5'

bq ls
bq mk --dataset --location=US bookshelf_analytics

References: Use the bq command-line tool, BigQuery client libraries.

BigQuery is introduced in AI, Data and Analytics Overview.

Kubernetes: kubectl and get-credentials

kubectl talks to a GKE cluster through the gke-gcloud-auth-plugin, which turns your gcloud credentials into cluster tokens. gcloud container clusters get-credentials writes the cluster endpoint and the plugin into your kubeconfig:

gcloud components install kubectl gke-gcloud-auth-plugin   # or use your package manager

gcloud container clusters get-credentials bookshelf-gke --region=us-central1
kubectl config current-context
kubectl get nodes

References: Install kubectl and configure cluster access, gcloud container clusters get-credentials.

Creating clusters is the subject of GKE Clusters.

Client libraries and Application Default Credentials

Application code should use the Google Cloud client libraries (or a framework such as Spring Cloud GCP, which wraps them) rather than calling REST endpoints by hand. They authenticate through Application Default Credentials, a strategy that searches for credentials in a fixed order, so the same code runs unchanged on a laptop, in CI and on Google Cloud:

flowchart TD S["Client library creates a client"] --> E{"GOOGLE_APPLICATION_CREDENTIALS\nset?"} E -- yes --> F["Use that credential configuration file\n(Workload Identity Federation config,\nor a service account key)"] E -- no --> U{"Local ADC file exists?\n(gcloud auth application-default login)"} U -- yes --> L["Use your user credentials\n(or the impersonated service account)"] U -- no --> M{"Running on Google Cloud\nwith an attached service account?"} M -- yes --> A["Use the service account from the\nmetadata server"] M -- no --> X["Fail: could not find\ndefault credentials"]

Note that the CLI and ADC are separate credential stores: gcloud auth login signs in the CLI, while gcloud auth application-default login creates the local ADC file that libraries read (at $HOME/.config/gcloud/application_default_credentials.json on Linux and macOS). Running one does not run the other.

# Create local ADC from your own user credentials
gcloud auth application-default login

# Better for least privilege: ADC that impersonates a dedicated service account
# (requires the Service Account Token Creator role on that service account)
gcloud auth application-default login \
  --impersonate-service-account=catalog-api-sa@my-project-id.iam.gserviceaccount.com

# Set the quota/billing project used by ADC calls
gcloud auth application-default set-quota-project my-project-id

# Impersonate for a single gcloud command only
gcloud storage ls --impersonate-service-account=catalog-api-sa@my-project-id.iam.gserviceaccount.com

References: How Application Default Credentials works, Set up ADC for a local development environment, Service account impersonation.

User ADC on a laptop is powerful: code you run locally acts with everything your user can do, in every project you can access. Prefer impersonating a service account that holds only the roles the application needs, and never download a service-account key to make local code work. On Google Cloud, attach a user-managed service account to the resource (Cloud Run service, VM or GKE workload through Workload Identity Federation for GKE) and let ADC pick it up from the metadata server. See Identity and Access for all of this in depth.

A minimal Java example for the Bookshelf uploads bucket, using the Google Cloud libraries BOM so versions stay aligned (use the current libraries-bom release from the official page):

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.google.cloud</groupId>
      <artifactId>libraries-bom</artifactId>
      <version>LIBRARIES_BOM_VERSION</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>
<dependencies>
  <dependency>
    <groupId>com.google.cloud</groupId>
    <artifactId>google-cloud-storage</artifactId>
  </dependency>
</dependencies>
package com.example.bookshelf;

import com.google.cloud.storage.Blob;
import com.google.cloud.storage.Bucket;
import com.google.cloud.storage.Storage;
import com.google.cloud.storage.StorageOptions;

public class ListUploads {
    public static void main(String[] args) {
        // No credentials appear in code: Application Default Credentials are resolved automatically,
        // and the project comes from the environment (GOOGLE_CLOUD_PROJECT) or the gcloud configuration.
        Storage storage = StorageOptions.getDefaultInstance().getService();

        String projectId = System.getenv("GOOGLE_CLOUD_PROJECT");
        Bucket bucket = storage.get("bookshelf-uploads-" + projectId);
        for (Blob blob : bucket.list().iterateAll()) {
            System.out.println(blob.getName());
        }
    }
}

References: Google Cloud Libraries BOM, Cloud Storage client libraries, Set up a Java development environment.

Spring Boot applications use Spring Cloud GCP (8.x for Spring Boot 4 and 7.4.x for Spring Boot 3), which builds on the same credential chain, as shown on later pages. Other languages follow the same pattern: for Python, google-cloud-storage with storage.Client(); for Node.js, @google-cloud/storage; ADC is resolved the same way.

Cloud Code and IDE support

Cloud Code is a set of IDE plug-ins for Visual Studio Code and the JetBrains IDEs (including IntelliJ IDEA), and it is also built into Cloud Shell Editor and Cloud Workstations. It adds a Google Cloud explorer, Cloud Run and Kubernetes (GKE) run and debug configurations, local emulation with Minikube, YAML schema help and snippets, and Gemini Code Assist support for AI-assisted coding. It reuses your ADC and gcloud configuration, so the setup on this page is all it needs. It is a convenience, not a requirement: everything it does can be done with the CLI.

References: Cloud Code documentation, Gemini Code Assist overview.

Coming from another cloud

If you already know AWS or Azure, Google publishes service-mapping guides ("Google Cloud for AWS professionals" and "Google Cloud for Azure professionals") in the Architecture Center. The most visible differences for newcomers are that a project is the main resource boundary (rather than an AWS account or an Azure subscription), that VPC networks are global with regional subnets, and that the same gcloud and ADC setup serves the CLI, libraries and IaC tools. Compare with Getting Started with AWS and Getting Started with Azure as you go.

References: Compare AWS and Azure services to Google Cloud, Get started with Google Cloud.

Clean up

Everything on this page is free or negligible, but tidy up what you created:

# Remove the learning configuration (switch to another one first)
gcloud config configurations activate default
gcloud config configurations delete bookshelf-dev

# Revoke local ADC if you no longer need it
gcloud auth application-default revoke

# Delete a throwaway project; it is scheduled for deletion and can be restored for about 30 days
gcloud projects delete my-project-id

References: gcloud projects delete, gcloud auth application-default revoke.

Where to go next

References