Set up the gcloud CLI, organize work into projects, and control who can do what with IAM: grant roles to users, create service accounts for apps, and attach a service account to a VM so it needs no keys.
gcloud is how you drive Google Cloud from a terminal. Why first: every command runs as your signed-in identity against one project, so you authenticate before doing anything else. gcloud init walks you through login and picking defaults.
Sign in (opens a browser)
gcloud auth loginWalk through interactive setup (account, project, default region)
gcloud initConfirm who you are and the active config
gcloud config listA project is the top-level container that holds all your resources, billing, and permissions. Why it matters: every resource belongs to exactly one project, and IAM, quotas, and billing are all per-project. Deleting a project removes everything in it — the clean way to end an experiment.
Create a project (the id must be globally unique)
gcloud projects create learn-gcp-7f3k --name "Learning GCP"Make it the active project for all later commands
gcloud config set project learn-gcp-7f3kList your projects
gcloud projects listEach Google Cloud service is an "API" that is off until you enable it for the project. Why: a fresh project can do almost nothing until you turn on the services you need — Compute, Storage, etc. You enable them once per project.
Enable the services used across this course
gcloud services enable \
compute.googleapis.com \
storage.googleapis.com \
run.googleapis.comSee what's enabled
gcloud services list --enabledIAM controls access by binding a role (a bundle of permissions like roles/viewer or roles/editor) to a "member" (a user, group, or service account) on a resource. Why "principle of least privilege": grant the narrowest role that works, at the smallest scope, so a leaked credential can do little.
See the predefined roles available
gcloud iam roles list --query "displayName" 2>/dev/null | headGrant a user the Viewer role on the whole project
gcloud projects add-iam-policy-binding learn-gcp-7f3k \
--member="user:teammate@example.com" \
--role="roles/viewer"A service account is a non-human identity that apps, scripts, and VMs use to authenticate to Google Cloud. Why: you never put a person's login in automation — you create a service account with exactly the roles it needs. It is identified by an email address.
Create a service account
gcloud iam service-accounts create app-runner \
--display-name "App runtime identity"Grant it a role (read objects from Cloud Storage)
gcloud projects add-iam-policy-binding learn-gcp-7f3k \
--member="serviceAccount:app-runner@learn-gcp-7f3k.iam.gserviceaccount.com" \
--role="roles/storage.objectViewer"Instead of downloading a service-account key file (a secret you must guard), you attach the service account to a resource like a VM. Why: the VM then gets short-lived credentials automatically, rotated by Google — the single biggest security win, equivalent to AWS IAM roles. Avoid key files unless you truly need them.
Launch a VM that runs AS the service account (no key file anywhere)
gcloud compute instances create id-demo \
--zone us-central1-a \
--service-account app-runner@learn-gcp-7f3k.iam.gserviceaccount.com \
--scopes cloud-platformCode on that VM can now call Storage with no stored secret.