Foundations
Set Up Your Cloud Home Base
One GCP project, done right, that every later phase builds on.
You build
The account, project, and guardrails.
Core concept
Cloud basics, IAM, keyless auth (Workload Identity Federation).
Phase 0 is the part most tutorials skip and most people regret skipping. Before writing a line of application code, you'll stand up a Google Cloud account, claim the free $300 credit, create a clean project, and put the guardrails and tooling in place. Do this once, carefully, and the next four phases are smooth.
This track is generalizable — make it yours. Everywhere you see YOUR_NAME, PROJECT_ID, YOUR_REGION, or your-github-user/your-repo, substitute your own values. Build the site around your real resume and interests so the result is something you'd actually put on LinkedIn.
Why it matters in industry
Companies run on repeatable, reviewable infrastructure — not on someone clicking around a console and forgetting what they did. Leaked cloud credentials are one of the most common causes of real breaches, so keyless authentication is now standard practice.
Example — A fintech startup describes its entire production environment in code. A new engineer can recreate the whole stack from the repo, every change goes through a pull request, and CI/CD deploys automatically — with zero long-lived keys stored anywhere.
Reference for this phase
A few terms, in plain English
- Project
- The top-level container in GCP. Everything (services, databases, billing, permissions) lives inside a project. You'll make exactly one for this whole track.
- Region
- Which physical datacenter your stuff runs in (e.g. us-central1). Pick one near you and reuse it everywhere to avoid latency and cross-region charges.
- IAM
- Identity and Access Management: who (or what) is allowed to do what. “Least privilege” means giving each identity the minimum it needs.
- Service account
- A non-human identity that programs use to act on GCP, instead of your personal login. Your CI/CD pipeline will use one.
- gcloud CLI
- The command-line tool for talking to Google Cloud from your terminal.
Step 1 · Account
Create the account and claim $300
New Google Cloud customers get $300 in free credit, valid for 90 days, plus an always-free tier on many products. You won't be charged, and billing only starts if you manually upgrade — the trial account auto-closes at 90 days or when the credit runs out. A card is required only to verify identity.
Go to cloud.google.com/free and click Get started for free. Sign in with a Google account. Accept the terms, add a card for verification, and confirm the $300 / 90-day credit is showing. In the console top bar, create a New Project and note its PROJECT_ID (permanent and globally unique; yourname-portfolio works well). Make sure billing is linked to it.
Step 2 · Tools
Install your local tools — with Claude's help
You'll drive most of this from an AI coding tool that can run commands in a terminal. First install that tool itself, then let it help you install the rest: the Google Cloud CLI (gcloud), Git + GitHub CLI (gh), and Docker.
Once your AI tool is installed, you don't have to look up install steps — ask it to detect what's missing and install it, then authenticate.
“Check which of these are installed on my machine — gcloud, git, gh, docker — and walk me through installing whatever's missing for my OS.”
It can detect your system, tell you what's missing, and run the installs. Review each step before approving.
“Log me into gcloud, set my project to PROJECT_ID, and set up application-default credentials. Explain what each command does as you go.”
Under the hood: gcloud auth login, gcloud config set project, and gcloud auth application-default login.
gcloud auth login # your personal login
gcloud config set project PROJECT_ID # target this project
gcloud auth application-default login # creds for local codeStep 3 · Guardrails
Set a budget before you build anything
The single most important habit for staying inside the free credit is a budget alert. It won't stop spending on its own, but it emails you the moment you cross a threshold, so nothing surprises you.
In the console: Billing → Budgets & alerts → Create budget. Scope it to your project, set an amount (e.g. $50), and add alert thresholds at 50%, 90%, and 100%. Or do it from the terminal:
“Help me create a GCP billing budget of $50 on PROJECT_ID with email alerts at 50, 90, and 100 percent.”
It can use the gcloud billing budgets commands — review what it proposes before running it.
gcloud billing budgets create \
--billing-account=BILLING_ACCOUNT_ID \
--display-name="portfolio budget" \
--budget-amount=50USD \
--threshold-rule=percent=0.5 \
--threshold-rule=percent=0.9 \
--threshold-rule=percent=1.0Habits that keep it free
Everything in one region · scale services to zero when idle (Cloud Run does this by default) · tear down anything you're done experimenting with · check the billing dashboard weekly. The database in Phase 3 is the main thing that bills continuously.
Step 4 · Enable Services
Turn on the APIs you'll need
GCP services are off by default; you enable the ones you use. Turn on the core set now (later phases enable a couple more when they need them).
“Enable these GCP APIs on PROJECT_ID and tell me what each one is for: run, artifactregistry, cloudbuild, iam, iamcredentials, sts.”
These cover hosting (Cloud Run), image storage, building, and the identity pieces Workload Identity Federation needs in Step 5.
gcloud services enable \
run.googleapis.com \
artifactregistry.googleapis.com \
cloudbuild.googleapis.com \
iam.googleapis.com \
iamcredentials.googleapis.com \
sts.googleapis.comStep 5 · Keyless CI/CD Auth
Set up Workload Identity Federation
In Phase 1, GitHub Actions will deploy your site to GCP. The old way was to create a service-account JSON key and paste it into GitHub — a long-lived credential that can leak. The modern best practice is Workload Identity Federation (WIF): GitHub proves its identity with a short-lived token, GCP trusts it directly, and no key is stored anywhere.
What gets created: a workload identity pool and provider that trust GitHub's OIDC issuer; a deploy service account with least-privilege roles; and a binding that lets only your specific repo impersonate that service account.
GitHub Actions
your repo, on merge
OIDC token
short-lived, per run
WIF pool + provider
trusts GitHub · scoped to your repo
Deploy service account
least-privilege, impersonated
Cloud Run
site deploys
No key is ever stored. GitHub proves its identity on each run; GCP trusts that short-lived token and lets only your one repo impersonate the deploy account.
“Set up Workload Identity Federation between GCP project PROJECT_ID and my GitHub repo your-github-user/your-repo, so GitHub Actions can deploy without any stored keys. Create a least-privilege deploy service account, and restrict impersonation to ONLY that one repo. Then give me the two values I'll need as GitHub secrets: the provider resource name and the service account email. Explain each piece as you create it.”
The “restrict to only that repo” part is the security-critical bit — don't skip it. Save the two output values for Phase 1.
Why this matters beyond this project
Keyless federation is exactly what real teams use, and “can you set up WIF between GitHub and GCP” is a genuine interview-grade skill. You're building the production pattern, not a toy.
Done when
- GCP account created, $300 credit confirmed, budget alerts set.
- One project with a memorable PROJECT_ID, billing linked.
- Your AI coding tool, gcloud, Git/gh, and Docker installed and authenticated.
- Core APIs enabled.
- Workload Identity Federation configured and scoped to your repo, with the two secret values saved for Phase 1.
1.In the Workload Identity Federation setup, which detail is the security-critical one?
2.What does a GCP budget alert actually do?
Answer every question correctly to complete this phase.