Set Up a Cloud Solution Environment
What this domain really tests
Setup questions are about the mechanics of getting a working environment: projects, billing, the gcloud CLI, and Identity and Access Management (IAM) at the organization/folder/project hierarchy. Understand that resources inherit policy from parent nodes, that a project belongs to exactly one organization or folder, and that billing is attached to a project, not to a user.
Concepts to master
- Resource hierarchy: organization → folders → projects → resources. Policies flow downward and are additive.
- Billing accounts: separate from projects; linking enables paid APIs. Budgets and alerts are configured on the billing account.
- gcloud configuration: named configurations,
gcloud config set project, and--projectflags for one-off commands. - APIs: most services must be enabled per project before use.
Traps
- A question says "the user has the role but still gets permission denied" - check for a deny policy or an org policy, since inherited grants are additive but deny overrides allow.
- "Enable an API for the whole organization" is a distractor; APIs are enabled per project.
- Confusing
gcloud auth login(user credentials) withgcloud auth application-default login(ADC for code). - Assuming a new project inherits billing automatically - it does not.
Rule of thumb
Grant at the highest node that still satisfies least privilege, and prefer predefined roles over primitive Owner/Editor. If a task says "for all current and future projects," grant at the folder or organization.
Worked example
A team needs BigQuery access for every project under folders/analytics. Grant roles/bigquery.dataViewer at the folder, not per project; new projects inherit it automatically.