# Tutorials

💸 Put a real hard cap on GCP spending

A GCP budget only sends alerts — it never stops usage. This wires a budget to a function that actually disables billing when you cross the line. Use it on sandbox/learning projects where an overrun is worse than an outage.

1. Create a budget with a threshold. Billing → Budgets & alerts → Create budget, scope it to the project, set the amount and alert thresholds (e.g. 50/90/100%).
2. Give the budget a Pub/Sub topic. On the budget's last step, expand Manage notifications and connect it to a new Pub/Sub topic (e.g. billing-alerts). This publishes a message every time spend updates.
3. Deploy a function subscribed to that topic that calls the Cloud Billing API to detach the billing account:
   copy# the function's core call (Node/Python client shown in the docs) billing.projects.updateBillingInfo({ name: 'projects/PROJECT_ID', requestBody: { billingAccountName: '' } // '' = disable billing })
4. Grant the function's service account the billing role. It needs roles/billing.projectManager (or Billing Account Admin) to detach billing.
5. Test with a low budget. Temporarily set a tiny amount, confirm the function fires and billing detaches, then reset. Re-enabling billing later is a one-click console action.

Docs: disable billing with notifications · related fix: budgets don't cap spending.

🔐 Create a least-privilege service account (no keys)

The safe default for workloads: a dedicated service account with only the roles it needs, attached to the resource — never a downloaded JSON key.

1. Create the service account:
   copygcloud iam service-accounts create my-app-sa \ --display-name="My app runtime SA"
2. Grant only the roles it needs, scoped as tightly as possible (project shown; prefer resource-level where supported):
   copygcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:my-app-sa@PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/storage.objectViewer"
3. Attach the SA to the workload instead of exporting a key. For Cloud Run: --service-account=my-app-sa@…; for a VM: set it as the instance service account; for GKE: use Workload Identity.
4. Let the client libraries find it automatically. On Google infrastructure, Application Default Credentials use the attached SA with zero config — no key file to leak.
5. Verify what it can do with the Policy Troubleshooter or:
   copygcloud projects get-iam-policy PROJECT_ID \ --flatten="bindings[].members" \ --filter="bindings.members:my-app-sa@PROJECT_ID.iam.gserviceaccount.com"

Docs: best practices for service accounts · Workload Identity Federation.

⚡ Deploy a container to Cloud Run (without the PORT error)

The #1 Cloud Run failure is "container failed to start and listen on the port." Get it right the first time.

1. Listen on 0.0.0.0:$PORT. Read the port from the environment — never hardcode 3000/8080 or bind to 127.0.0.1:
   copyconst port = process.env.PORT || 8080; app.listen(port, '0.0.0.0');
2. Enable the APIs once:
   copygcloud services enable run.googleapis.com \ artifactregistry.googleapis.com cloudbuild.googleapis.com
3. Deploy straight from source (Cloud Build builds & pushes the image for you):
   copygcloud run deploy my-service \ --source . --region REGION \ --service-account=my-app-sa@PROJECT_ID.iam.gserviceaccount.com
4. Choose access. Add --allow-unauthenticated for a public site; omit it and grant callers roles/run.invoker for a private service.
5. If it still fails to start, read the startup stack trace in Cloud Logging, test the image locally with docker run -e PORT=8080 -p 8080:8080 IMAGE, and raise the startup timeout if init is slow.

Docs: deploying to Cloud Run · container runtime contract · related fix: PORT error.

☸️ Connect kubectl to a new GKE cluster

Fresh cluster, and kubectl says "you must be logged in." You just need credentials and the auth plugin.

1. Install the auth plugin (required since kubectl 1.26):
   copygcloud components install gke-gcloud-auth-plugin
2. Fetch cluster credentials into kubeconfig:
   copygcloud container clusters get-credentials CLUSTER \ --region REGION --project PROJECT_ID
3. Verify connectivity:
   copykubectl get nodes
4. If you get 403s, grant your identity roles/container.developer (or container.admin) and make sure the Kubernetes Engine API is enabled.

Docs: cluster access for kubectl.

📧 Set up Workspace email on a brand-new domain

Get mail flowing to Gmail in the right order so you don't chase a "not receiving mail" ghost.

1. Verify domain ownership. Admin console setup tool gives you a google-site-verification TXT record — paste the exact value into your registrar's DNS (host @).
2. Replace MX records. Delete any legacy MX entries and add Google's single MX host (smtp.google.com, priority 1 on new setups). Only Google's MX should remain.
3. Activate Gmail from the setup tool once records are in place. DNS can take up to 72 hours to propagate.
4. Confirm delivery by sending a test message in and out. If inbound fails, re-check that no old MX record is still present.
5. Then set up email authentication (next tutorial) before you send anything at volume.

Docs: verify your domain · set up MX records.

✉️ Set up SPF, DKIM & DMARC (in the right order)

Order matters. Authenticate first, enforce last — or you'll bounce your own mail. Since Feb 2024 Gmail requires this for reliable delivery.

1. SPF — publish exactly one TXT record listing every sender:
   copyv=spf1 include:_spf.google.com ~all
   Keep total DNS lookups under 10. No Admin-console step needed.
2. DKIM — Admin console → Apps → Gmail → Authenticate email → generate a 2048-bit key → add the TXT record at your host → return and click Start authentication.
3. Let both settle for at least 48 hours and confirm they pass (check message headers: spf=pass, dkim=pass).
4. DMARC — start at monitor only:
   copyv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
5. Review reports, then tighten to p=quarantine and eventually p=reject once you've confirmed all legitimate mail aligns.

Docs: SPF · DKIM · DMARC · related fixes: email auth.

🔒 Roll out 2-Step Verification without mass lockouts

Enforcing 2SV before people enroll locks everyone out at once. Sequence it.

1. Prep admins first. Ensure 2+ super admins have recovery email/phone set, so a bad rollout can't lock you out of the console.
2. Turn on allowance, not enforcement. Security → Authentication → 2-Step Verification → allow users to turn it on.
3. Announce + set an enrollment period. Give users a deadline (e.g. 2–4 weeks) to enroll a second factor.
4. Enforce per-OU after the window, starting with a pilot OU. Prefer a grace period for new users.
5. Plan for lost factors. Admins can issue backup codes (Directory → Users → Security). Note: "only security key" mode disables self-service backup codes — the admin must generate them.

Docs: deploy 2SV · avoid lockouts · related fix: 2SV lockouts.

📂 Use shared drives so files survive offboarding

My Drive files are owned by the person — delete the account and they can orphan. Shared drives are owned by the org. Set teams up this way from day one.

1. Enable shared drives for the right OU: Admin console → Apps → Google Workspace → Drive and Docs → Sharing settings / Manage shared drives.
2. Create a shared drive per team and add members by group (not individuals) so membership tracks your directory.
3. Set member roles deliberately — Manager, Content manager, Contributor, Commenter, Viewer.
4. Move existing team files in. Ownership transfers to the shared drive (org-owned) so departures don't orphan anything.
5. For any remaining My Drive files, transfer ownership before deleting a user — the delete flow offers a data transfer step.

Docs: set up shared drives · manage shared drives.