Domain 1: Setting Up a Cloud Solution Environment (~20%)

Domain 1 accounts for approximately 20% of the Associate Cloud Engineer exam, translating to roughly 10-12 questions. This is a foundational domain: every other domain builds on the concepts tested here. You must know the resource hierarchy cold, understand billing mechanics, and be able to configure projects, IAM, and operational tooling using both the Console and gcloud CLI. The exam tests two sub-domains -- setting up cloud projects/accounts and managing billing configuration.

1.1 Setting Up Cloud Projects and Accounts

The Google Cloud Resource Hierarchy

The resource hierarchy organizes all Google Cloud resources into a tree structure. Every resource has exactly one parent. Policies and permissions flow downward through this tree via inheritance.

Four levels, top to bottom:

Organization (example.com)
├── Folder: Engineering
│   ├── Folder: Production
│   │   ├── Project: prod-web-app
│   │   └── Project: prod-database
│   └── Folder: Development
│       └── Project: dev-sandbox
├── Folder: Finance
│   └── Project: finance-reporting
└── Project: shared-services

Organization Node

The organization resource is the root of the hierarchy. It is automatically created when a Google Workspace or Cloud Identity account exists and a member of that domain creates a Google Cloud project.

Key facts:

• One organization per domain: A Google Workspace domain example.com maps to exactly one organization node.
• Super admin: The Google Workspace or Cloud Identity super admin automatically gains the ability to assign IAM roles on the organization, including the Organization Administrator role.
• Central control: The organization node prevents "shadow projects" -- every project created by domain members appears under the organization, ensuring centralized visibility.
• Lifecycle protection: Resources survive individual employee departures because they belong to the organization, not the individual.

Exam trap: Without an organization node, projects are "orphaned" -- they exist with no parent and cannot use organization-level policies or folders. If the exam describes a company that needs centralized policy enforcement, the first step is establishing an organization via Cloud Identity or Google Workspace.

Folders

Folders provide an additional grouping mechanism between the organization and projects. They are optional but essential for any non-trivial environment.

• Folders can contain projects and other folders (nesting is supported).
• IAM policies and organization policies applied to a folder are inherited by all projects and sub-folders beneath it.
• Folders model your organizational structure: departments, teams, environments (prod/dev/staging), or applications.
• Folder Admin (roles/resourcemanager.folderAdmin) can create, move, and delete folders within a parent resource.

Use cases for the exam:

Projects: The Fundamental Building Block

Projects are required. Every Google Cloud resource must belong to a project. Projects serve as the boundary for:

• Billing: Each project is linked to exactly one billing account.
• API enablement: APIs are enabled per project.
• IAM: Permissions can be scoped to a specific project.
• Resource quotas: Quotas are applied per project.

Three project identifiers:

# Create a project
gcloud projects create my-project-id --name="My Project" --folder=FOLDER_ID

# Create a project under the organization (no folder)
gcloud projects create my-project-id --name="My Project" --organization=ORG_ID

# List all projects
gcloud projects list

# Describe a specific project
gcloud projects describe my-project-id

# Set the active project for gcloud commands
gcloud config set project my-project-id

# Delete a project (30-day recovery period)
gcloud projects delete my-project-id

# Undelete a project (within the 30-day window)
gcloud projects undelete my-project-id

Exam trap: Project ID is chosen at creation and cannot be changed afterward. Project Name can be changed anytime. Project Number is auto-assigned and read-only. The exam tests whether you know which identifier is immutable. Also: deleted projects enter a 30-day shutdown period during which they can be recovered with gcloud projects undelete.

Labels and Tags

Labels and tags are both used for organizing resources, but they serve different purposes.

Exam trap: If a question asks about controlling access based on resource classification (e.g., "only allow deletion of resources tagged as non-production"), the answer is tags with IAM Conditions or deny policies -- not labels. Labels are for cost tracking and filtering, not access control.

Organization Policies and Constraints

The Organization Policy Service enforces governance constraints across the resource hierarchy. Organization policies are evaluated before IAM -- even if IAM allows an action, an organization policy can block it.

Key concepts:

Commonly tested constraints:

# List available constraints
gcloud org-policies list --organization=ORG_ID

# Describe a specific constraint
gcloud org-policies describe constraints/compute.vmExternalIpAccess \
  --organization=ORG_ID

# Set a boolean constraint (enforce it)
gcloud org-policies set-policy policy.yaml --organization=ORG_ID

# Reset a policy to the default (remove customization)
gcloud org-policies reset constraints/compute.vmExternalIpAccess \
  --project=PROJECT_ID

Policy inheritance for organization policies:

• Organization policies inherit downward (organization to folder to project).
• A child node can restrict further (tighten the constraint) but generally cannot relax a constraint set by a parent unless the parent policy explicitly allows overrides.
• The Restore default option removes any custom policy at that level, reverting to the inherited policy from the parent.

Exam trap: Organization policies override IAM. A user with roles/compute.instanceAdmin.v1 can normally create VMs with external IPs, but if constraints/compute.vmExternalIpAccess is set to deny all, they cannot. The policy constraint wins.

Granting IAM Roles Within a Project

IAM is covered in depth in Domain 5, but Domain 1 requires understanding how to grant roles during project setup.

Role types (quick reference):

# Grant a predefined role on a project
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:alice@example.com" \
  --role="roles/compute.viewer"

# Grant a role to a group
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="group:dev-team@example.com" \
  --role="roles/editor"

# View the IAM policy for a project
gcloud projects get-iam-policy PROJECT_ID

# Remove a role binding
gcloud projects remove-iam-policy-binding PROJECT_ID \
  --member="user:alice@example.com" \
  --role="roles/compute.viewer"

Exam trap: roles/editor cannot modify IAM policies or manage billing. If the exam asks how an Editor can grant access to another user, the answer is: they cannot. They need roles/owner or a role with resourcemanager.projects.setIamPolicy.

Managing Users and Groups in Cloud Identity

Cloud Identity is Google's identity-as-a-service (IDaaS) platform. It provides the user and group directory that underpins IAM in Google Cloud. Google Workspace includes Cloud Identity features; Cloud Identity Free is available for organizations that do not use Workspace.

Manual management:

• Create users and groups in the Google Admin console (admin.google.com).
• Users: Individual accounts with email addresses in your domain.
• Groups: Collections of users (and other groups). Groups are the preferred way to manage access at scale -- assign IAM roles to groups rather than individual users.

Automated management:

Exam trap: Google Cloud Directory Sync (GCDS) is one-way: on-premises Active Directory to Cloud Identity. It does not sync changes back from Cloud Identity to Active Directory. If the exam mentions bidirectional sync, GCDS is not the answer.

Enabling APIs Within Projects

Google Cloud APIs are disabled by default in new projects. You must enable each API before using the corresponding service.

# Enable the Compute Engine API
gcloud services enable compute.googleapis.com

# Enable multiple APIs at once
gcloud services enable \
  compute.googleapis.com \
  storage.googleapis.com \
  bigquery.googleapis.com

# List enabled APIs
gcloud services list --enabled

# List all available APIs (enabled and disabled)
gcloud services list --available

# Disable an API
gcloud services disable compute.googleapis.com

Key facts:

• Enabling an API is per-project. Enabling Compute Engine in project-a does not enable it in project-b.
• Some APIs have dependencies. For example, enabling the GKE API (container.googleapis.com) also enables the Compute Engine API.
• Disabling an API does not delete resources, but those resources become inaccessible until the API is re-enabled.
• The Service Usage Admin role (roles/serviceusage.serviceUsageAdmin) grants permission to enable and disable APIs.

Exam trap: If you try to create a resource and get a "API not enabled" error, you need to enable the API first. The exam may present this as a troubleshooting scenario.

Provisioning Cloud Operations Suite Products

The Cloud Operations suite (formerly Stackdriver) provides observability tools. For the ACE exam, know what each product does and basic setup steps.

Monitoring setup essentials:

# Create an alerting policy (example: CPU utilization > 80%)
gcloud alpha monitoring policies create \
  --notification-channels=CHANNEL_ID \
  --display-name="High CPU Alert" \
  --condition-display-name="CPU > 80%" \
  --condition-filter='resource.type = "gce_instance" AND metric.type = "compute.googleapis.com/instance/cpu/utilization"' \
  --condition-threshold-value=0.8 \
  --condition-threshold-comparison=COMPARISON_GT \
  --condition-threshold-duration=60s

# Create a notification channel (email)
gcloud alpha monitoring channels create \
  --type=email \
  --display-name="Ops Team Email" \
  --channel-labels=email_address=ops@example.com

Logging setup essentials:

# List log entries
gcloud logging read "resource.type=gce_instance" --limit=10

# Create a log sink to BigQuery
gcloud logging sinks create my-bq-sink \
  bigquery.googleapis.com/projects/PROJECT_ID/datasets/my_dataset \
  --log-filter='resource.type="gce_instance"'

# Create a log sink to Cloud Storage
gcloud logging sinks create my-gcs-sink \
  storage.googleapis.com/my-log-bucket \
  --log-filter='severity>=ERROR'

Metrics Scopes (multi-project monitoring):

A Metrics Scope defines which projects' metrics a monitoring project can see. One project (the scoping project) can monitor multiple monitored projects. This is how you create a centralized monitoring dashboard that aggregates data from many projects.

Exam trap: Cloud Monitoring and Cloud Logging are enabled by default in every project -- no manual API enablement needed for basic functionality. However, setting up cross-project monitoring requires configuring Metrics Scopes, and log routing to external destinations requires creating log sinks with appropriate IAM permissions on the destination.

Assessing and Requesting Quota Increases

Quotas limit how much of a particular resource you can create in a project. They protect against runaway resource consumption and abuse.

Types of quotas:

# List quotas for a project
gcloud compute project-info describe --project=PROJECT_ID

# List quotas for a specific region
gcloud compute regions describe us-central1 --project=PROJECT_ID

# Request a quota increase (via Console or gcloud)
# Console: IAM & Admin > Quotas > Select quota > Edit Quotas
# gcloud: Use the Service Usage API
gcloud alpha services quota update \
  --service=compute.googleapis.com \
  --consumer=projects/PROJECT_ID \
  --metric=compute.googleapis.com/cpus \
  --unit=1/project/region \
  --value=48 \
  --force

Key facts:

• Quota increases are not instant. Requests are reviewed and may take 24-48 hours (or longer for large increases).
• Some quotas cannot be increased and are hard limits.
• Quotas are enforced per project. If you hit a quota in one project, creating another project gives you a fresh quota allocation.
• You can use the Quota page in the Cloud Console to monitor current usage vs. limits.
• Set up quota alerts in Cloud Monitoring to be notified when usage approaches limits.

Exam trap: If the exam describes a scenario where a deployment fails with a "quota exceeded" error, the answer is usually to request a quota increase or to spread resources across multiple regions. The answer is never to bypass quotas.

1.2 Managing Billing Configuration

Billing Account Types

A billing account defines who pays for the Google Cloud resources consumed by linked projects.

Key facts:

• A billing account can be linked to one or more projects.
• A project can be linked to only one billing account at a time.
• Billing accounts exist outside the resource hierarchy but can be associated with an organization.
• When a billing account is disabled or removed from a project, resources in that project stop running (Compute Engine instances are stopped, etc.).

# List billing accounts
gcloud billing accounts list

# Describe a billing account
gcloud billing accounts describe BILLING_ACCOUNT_ID

# Link a project to a billing account
gcloud billing projects link PROJECT_ID \
  --billing-account=BILLING_ACCOUNT_ID

# Unlink a project from its billing account
gcloud billing projects unlink PROJECT_ID

# Check which billing account a project uses
gcloud billing projects describe PROJECT_ID

Exam trap: Billing accounts are not part of the resource hierarchy (org/folder/project). They are separate resources. A billing account can pay for projects across multiple organizations. However, organization policies can restrict which billing accounts a project within the organization can use.

Billing Account Roles and Permissions

Common role combinations:

Exam trap: roles/billing.user can link projects to a billing account but cannot manage the billing account (no changing payment methods, no viewing invoices beyond the linked project). If the exam asks who can modify billing settings, the answer is Billing Account Administrator -- not Billing Account User.

Establishing Billing Budgets and Alerts

Billing budgets set spending thresholds on a billing account or specific projects. Budgets do not cap spending -- they only generate notifications.

Budget configuration:

# Create a budget (via gcloud or Console)
gcloud billing budgets create \
  --billing-account=BILLING_ACCOUNT_ID \
  --display-name="Monthly Budget" \
  --budget-amount=1000USD \
  --threshold-rule=percent=0.5 \
  --threshold-rule=percent=0.9 \
  --threshold-rule=percent=1.0

# List budgets
gcloud billing budgets list --billing-account=BILLING_ACCOUNT_ID

Programmatic budget responses (using Pub/Sub):

Connect a budget to a Pub/Sub topic, and use a Cloud Function subscriber to take automated action when thresholds are exceeded:

• Disable billing on non-critical projects.
• Send notifications to Slack or PagerDuty.
• Cap spending by stopping VMs or scaling down resources.

Exam trap: Budgets do NOT automatically stop spending. They only generate alerts. If the exam asks how to prevent overspending, budgets alone are insufficient -- you need budgets + Pub/Sub + Cloud Functions to take automated action. Alternatively, you can set a quota limit on the billing account for hard spending caps on specific services.

Setting Up Billing Exports

Billing export sends detailed cost and usage data to external destinations for analysis.

BigQuery export setup:

# 1. Create a BigQuery dataset for billing data
bq mk --dataset --location=US PROJECT_ID:billing_export

# 2. Enable billing export in Console:
#    Billing > Billing Export > BigQuery Export > Edit Settings
#    Select the dataset and enable the desired export types

# BigQuery export cannot be fully configured via gcloud alone;
# use the Console or the Billing Budgets API.

Key facts:

• BigQuery export is the recommended method. It provides the most granular data and supports SQL queries for analysis.
• For regional datasets, billing export data starts from the date you enable export (not retroactive). For multi-region datasets (US or EU), Google provides a partial backfill from the start of the previous month.
• The BigQuery dataset must be in the same billing account's region or a multi-region location.
• File export (to Cloud Storage) is a legacy option. Google recommends BigQuery for all new setups.

Exam trap: BigQuery billing export is generally not retroactive for regional datasets -- data starts from the date you enable it. Multi-region datasets (US/EU) receive a partial backfill from the start of the previous month. If the exam asks how to analyze costs from several months ago and export was not enabled, the answer is to use the Billing Reports in the Console (which have historical data) -- not BigQuery export.

Cost Management Tools

Pricing Calculator key points:

• Use it to estimate monthly costs for a proposed architecture.
• Input resource specifications (VM type, disk size, network egress, etc.) and the calculator produces a cost estimate.
• Export estimates as a shareable link or CSV.
• The exam may present a scenario and ask which tool to use for cost estimation -- Pricing Calculator is the answer for pre-deployment estimates; Billing Reports for post-deployment analysis.

Exam trap: Sustained Use Discounts (SUDs) are automatic -- no action needed. Committed Use Discounts (CUDs) require a 1-year or 3-year commitment and must be purchased explicitly. The exam tests whether you know the difference. SUDs apply to N1, N2, N2D, C2, M1/M2, and sole-tenant node vCPU/memory (including the sole-tenant premium) but NOT to E2, Tau, A2, or A3 machine types. Maximum discount varies: up to 30% for N1, up to 20% for N2/N2D/C2.

Quick-Reference: Decision Tree

Common Exam Traps Summary

1. Project ID is immutable -- chosen at creation and cannot be changed. Project Name can be changed. Project Number is auto-assigned and read-only.
2. Deleted projects have a 30-day recovery window -- use gcloud projects undelete within 30 days. After that, the project and all resources are permanently deleted.
3. Organization policies override IAM -- even with full permissions, a user cannot violate an organization policy constraint. Policies are evaluated before IAM.
4. Billing budgets do not cap spending -- they only send alerts. Automated spending controls require budgets + Pub/Sub + Cloud Functions.
5. BigQuery billing export is mostly not retroactive -- regional datasets start from enablement date; multi-region (US/EU) datasets get a partial backfill from the previous month's start.
6. roles/billing.user cannot manage billing accounts -- it can only link projects to a billing account. roles/billing.admin is needed for account management.
7. GCDS is one-way -- syncs from on-premises Active Directory to Cloud Identity. It does not write back to AD.
8. APIs are disabled by default -- you must enable each API per project before using the service. Some APIs have dependencies that are auto-enabled.
9. Folders require an organization -- you cannot create folders without an organization node. Without an organization, projects are flat/orphaned.
10. Labels vs. Tags -- labels are for cost tracking and filtering. Tags are for IAM access control via conditions and organization policies.
11. SUDs are automatic; CUDs require commitment -- Sustained Use Discounts apply automatically to eligible VMs. Committed Use Discounts require explicit purchase of a 1-year or 3-year contract.
12. One billing account per project -- a project can only be linked to one billing account at a time, but a billing account can serve many projects.
13. Billing accounts are outside the resource hierarchy -- they are not children of an organization, folder, or project. They are separate entities associated with the organization.
14. Disabling billing stops resources -- when a project's billing is disabled, Compute Engine instances are stopped and services become unavailable.

References

• Resource Hierarchy Overview
• IAM Overview
• Cloud Billing Concepts
• Cloud Billing Budgets
• Billing Export to BigQuery
• Cloud Monitoring Overview
• Cloud Logging Overview
• Enabling and Disabling APIs
• Quotas Overview
• Cloud Identity Overview
• Organization Policy Service
• Google Cloud Pricing Calculator
• GCP Associate Cloud Engineer Certification