Setting up a cloud solution environment

Resource hierarchy

Google Cloud resources sit in a tree. Policies (IAM and organization policies) are inherited downward and can only be added to, never subtracted from, by a lower level (except where an organization policy is explicitly overridden).

Organization  (tied to a Cloud Identity or Google Workspace domain)
 └─ Folders   (optional, nestable; teams, departments, environments)
     └─ Projects   (the unit of billing, quotas, API enablement and IAM)
         └─ Resources   (VMs, buckets, datasets, topics...)

Everything must belong to a project. A project is the boundary for API enablement, quotas, billing association and default service accounts.

Creating the hierarchy

gcloud organizations list
gcloud resource-manager folders create --display-name="Finance" --organization=ORG_ID
gcloud resource-manager folders create --display-name="Prod" --folder=FOLDER_ID
gcloud projects create my-app-prod-001 --name="My App Prod" --folder=FOLDER_ID
gcloud projects list
gcloud projects describe my-app-prod-001
gcloud projects move my-app-prod-001 --folder=OTHER_FOLDER_ID
gcloud projects delete my-app-prod-001          # soft delete, 30-day recovery
gcloud projects undelete my-app-prod-001
gcloud config set project my-app-prod-001

Design guidance the exam likes: separate environments (dev, test, prod) into separate projects or folders; group by team or business unit with folders; apply IAM and policy at the highest level where it makes sense and avoid per-project snowflakes. Use a Shared VPC host project for central networking (see the plan-implement notes).

Organization policies

An organization policy is a set of constraints that restrict what can be configured for resources, independent of who is allowed. IAM says who can act; org policy says what is allowed.

• Set at organization, folder or project; inherited by children. A child can override unless the parent enforces strictly; policies can merge with parent or replace it.
• Needs the role Organization Policy Administrator (roles/orgpolicy.policyAdmin) to set.
• Boolean constraints are on/off; list constraints allow or deny a set of values.
• Common constraints (they are named constraints/<service>.<name>):

gcloud org-policies list --organization=ORG_ID
gcloud org-policies set-policy policy.yaml --folder=FOLDER_ID
gcloud resource-manager org-policies enable-enforce compute.requireOsLogin --project=my-proj   # older command form

Trap: an org policy does not remove existing violations; it blocks new configuration. Dry-run mode lets you see what would be blocked first. Use tags on resources to apply a policy conditionally.

Granting IAM roles in a project

IAM is covered fully in the access-security notes; here you only need the setup basics.

gcloud projects add-iam-policy-binding my-proj \
    --member="user:ana@example.com" --role="roles/viewer"
gcloud projects remove-iam-policy-binding my-proj \
    --member="user:ana@example.com" --role="roles/viewer"
gcloud projects get-iam-policy my-proj

• Grant to groups, not individuals. Membership changes then happen in the directory, not in every policy.
• Member types: user:, group:, serviceAccount:, domain:, allAuthenticatedUsers, allUsers.
• Basic roles (Owner, Editor, Viewer) are too broad for production; use predefined or custom roles.
• Effective permissions are the union of bindings on the resource and all its ancestors.

Cloud Identity and managing users and groups

Cloud Identity is Google’s identity-as-a-service: it provides user accounts, groups, the organization node, 2-step verification enforcement and device management, without Workspace apps. Google Workspace includes the same directory plus Gmail, Docs and so on. Either gives you the organization resource once the domain is verified.

gcloud identity groups create devs@example.com --organization=ORG_ID \
    --display-name="Developers" --labels="cloudidentity.googleapis.com/groups.discussion_forum="
gcloud identity groups memberships add --group-email=devs@example.com --member-email=ana@example.com

Keep super admin accounts few, protected with security keys, and not used day to day. Don’t create resources with them.

Workforce Identity Federation gives external workforce users (from an IdP) access to Google Cloud without syncing accounts; Workload Identity Federation does the same for external workloads (AWS, Azure, GitHub, on-premises), so no service account keys are needed.

Enabling APIs

Most Google Cloud services are disabled in a project until you enable their API. A call to a disabled API returns an error that tells you to enable it.

gcloud services list --available | grep compute
gcloud services list --enabled
gcloud services enable compute.googleapis.com container.googleapis.com
gcloud services disable compute.googleapis.com --force   # --force disables dependents too

• Needs serviceusage.services.enable (role Service Usage Admin).
• Enabling an API in a project also links it to billing for paid services; billing must be linked first for most.
• The service usage consumer role (roles/serviceusage.serviceUsageConsumer) lets a principal use enabled APIs of a project, which matters for requests that bill to a different project.
• An org policy (serviceuser.services constraint style restrictions, or VPC Service Controls) can restrict which APIs can be used.

Quotas and limits

• View in IAM & Admin > Quotas & system limits or the Quotas page for a service. Filter by region and metric.
• Request an increase from the Quotas page (edit, supply the new limit and justification). Increases can be auto-approved or reviewed; needs serviceusage.quotas.update (Quota Administrator role). Free-trial and new billing accounts have low defaults.
• Quota exceeded errors for CPUs are regional (for example CPUS in us-central1) and usually mean you request an increase or pick another region.
• Set quota overrides/preferences to cap your own usage (useful for stopping a runaway job from spending money).

gcloud compute project-info describe --project=my-proj     # shows project-level quotas
gcloud compute regions describe us-central1                # shows regional quotas and usage

Google Cloud’s operations suite

The operations suite (formerly Stackdriver) is Cloud Monitoring, Cloud Logging, Error Reporting, Cloud Trace, Cloud Profiler (Debugger is retired) and Managed Service for Prometheus.

• Logging is on by default for most services: Admin Activity audit logs and platform logs flow without setup. VM guest logs and metrics need the Ops Agent.
• Monitoring automatically has system metrics (the compute.googleapis.com ones) for every project. To see several projects in one view, create a metrics scope: a scoping project that hosts monitoring and has other projects added to it (formerly a Workspace).
• Setting up for production: choose a scoping project, add monitored projects, install the Ops Agent on VMs, create notification channels (email, SMS, Slack, PagerDuty, Pub/Sub, webhook) and alerting policies, and create uptime checks.
• Alerts, custom metrics, log routing and agents are in the ensure-operation notes.

gcloud services enable monitoring.googleapis.com logging.googleapis.com
gcloud monitoring dashboards list

Billing configuration

gcloud billing accounts list
gcloud billing projects link my-proj --billing-account=0X0X0X-0X0X0X-0X0X0X
gcloud billing projects describe my-proj          # shows billingEnabled
gcloud billing projects unlink my-proj             # disables paid services; resources stop

Trap: unlinking billing makes paid services stop working for that project; the exam may ask “how do you stop spending on a project quickly” (unlink billing, or delete the project, or disable the APIs).

Billing is separate from the resource hierarchy: the billing account is not a parent of projects. You can have several billing accounts (per department, per cost centre) and link projects to the one that should pay.

Budgets and alerts

• A budget tracks spend (or forecast) for the whole account or filtered by projects, services, labels or credits. Set threshold rules (for example 50%, 90%, 100% of actual and forecasted).
• Budgets do not stop spending. They notify by email to billing admins and users, and can publish to a Pub/Sub topic so a Cloud Run function can react (for example disable billing on the project).
• Create with console or gcloud billing budgets create --billing-account=ID --display-name="Monthly" --budget-amount=1000USD --threshold-rule=percent=0.9.
• Use labels on resources and filter budgets and reports by label to attribute spend.

Billing export

Exports send detailed cost data to BigQuery for analysis (and Looker Studio dashboards).

You enable exports in Billing > Billing export, choose a BigQuery dataset, and data appears going forward only (no backfill). The detail needed for “which team spent what” is BigQuery export plus labels.