The Google Cloud Associate Cloud Engineer (ACE) certification validates your ability to deploy, secure, monitor, and maintain applications, services, and infrastructure on Google Cloud. The exam runs 2 hours with 50 to 60 multiple choice and multiple select questions across four areas: setting up a cloud solution environment (20%), planning and implementing a solution (30%), ensuring successful operation (30%), and configuring access and security (20%). Google recommends 6+ months of hands-on experience, and the current exam guide leans heavily on AI-assisted tooling like Gemini Cloud Assist, Gemini CLI, and Active Assist alongside the core console and gcloud skills. Unlike an architecture exam, ACE grades whether you can perform day-to-day platform tasks correctly, so the right answer is usually the Google-recommended way to accomplish a concrete task, not the most elaborate design.
What This Cheat Sheet Covers
This topic spans 38 focused tables and 338 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Resource Hierarchy and Organization Policies
ACE Exam Domain 1.1 (Setting up cloud projects and accounts): create a resource hierarchy of organization, folders, and projects; apply organization policies as guardrails across that hierarchy; and stand up a standalone organization. The hierarchy is the attachment point through which IAM roles and organization policies are inherited top-down.
| Concept | Example | Description |
|---|---|---|
Organization → Folders → Projects → Resources (VMs, buckets) | Structured tree that organizes all Google Cloud resources. Every resource except the root has exactly ONE parent. It binds a resource's lifecycle to its parent (ownership) and is the attachment point for IAM and org policies (inheritance). • Not just for billing: it drives IAM inheritance and policy too. | |
One root per company, e.g. organizations/34739118321 | Root node of the hierarchy, representing the company. IAM roles and org policies set here are inherited by every folder and project below. A project's lifecycle follows the org, not the employee who created it, so projects survive employee departure. | |
First-level folders = departments; subfolders = teams or apps | Optional grouping layer between the organization and projects; requires an organization to exist. Provides isolation boundaries and lets you delegate admin rights per department. Folders can nest inside folders. A role granted on a folder applies to all projects within it. | |
projectId (chosen, unique) + projectNumber (auto, read-only) | The core organizing and billing unit; you need a project to use any service, enable APIs, or manage permissions. Identified by a mutable display name, a globally unique project ID, and an auto-generated project number. The creator gets the Owner role. | |
Grant Network Admin at the org → team manages networks in every project | IAM roles AND organization policies flow DOWN the hierarchy. The effective policy at any node combines policies set directly on it with those inherited from ancestors. Grant high (org or folder) to avoid per-project setup; you cannot revoke an inherited role at a lower level. | |
Restrict resource locations; disable service account key creation | Centralized, programmatic guardrails on HOW resources can be configured, set on an org, folder, or project and inherited by children. Each policy enforces exactly one constraint. Guardrails apply even to a project Owner, enforcing compliance regardless of IAM. |