Google ACE: Resource Hierarchy, IAM and Billing Administration — Study Guide

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Part of the Google Associate Cloud Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Resource hierarchy, identity and access management (IAM), and billing administration form the control plane of Google Cloud operations. A resilient design starts with a clear hierarchy (organization, folders, projects) to scope policy and accountability; applies least-privilege IAM with group-centered administration and short-lived credentials for workloads; uses budgets, exports, and labels for cost attribution; and enforces governance with organization policies and comprehensive audit logging. Operational excellence comes from standardizing on inheritance, centralizing billing and logs, and using service account impersonation rather than long-lived keys. This section details the core constructs, their intended use, and common failure modes to avoid.

Resource Hierarchy and Identity Model

• Resource hierarchy

  • Organization: Root node, created with Cloud Identity or Google Workspace. Owns global policy (IAM, org policies, tags).
  • Folders: Optional grouping for departments, environments (e.g., dev, prod), or applications. Useful for delegated admin and policy scoping.
  • Projects: Administrative boundary for resources, APIs, quotas, IAM, and billing association. Most Google Cloud resources are children of projects.
  • Inheritance: IAM policies and organization policies inherit top-down. Denies and constraints at higher levels take precedence. Plan placement (org → folders → projects) to minimize exceptions and break-glass needs.

• Principals

  • Google accounts (users), Google groups, service accounts, and external identities via Workload Identity Federation.
  • Google groups should be the primary binding target for human access to simplify lifecycle changes and reviews.
  • Service accounts represent applications or services; prefer workload identity to keys.

• Workload identities

  • In Google Cloud: GCE/GAE/Cloud Run/GKE use metadata server to mint short-lived tokens for the attached service account.
  • Outside Google Cloud: Workload Identity Federation maps external identities (OIDC/SAML/AWS) to service accounts without static keys.

• Design trade-offs and failure modes

  • Sprawling projects without folder structure cause policy duplication and drift.
  • Granting roles directly to users increases toil; prefer group-based bindings.
  • Using the Compute Engine default service account with broad permissions elevates risk; create least-privileged service accounts per workload.
  • Misplacing a project under the wrong folder inherits incorrect policies; use tags or move projects carefully with change control.

IAM Roles and Policy Design

• Role types

  • Basic roles (Viewer, Editor, Owner): Broad, legacy. Avoid except for tightly controlled break-glass.
  • Predefined roles: Curated per service; prefer for most use cases.
  • Custom roles: Organization- or project-scoped aggregation of permissions for bespoke needs.
  • Conditional roles: IAM Conditions (CEL) add context such as resource name, folder, tags, or time; use to constrain powerful roles.

• Policy principles

  • Least privilege: Grant only the minimal role at the narrowest scope (resource/project/folder).
  • Separation of duties: Split duties (e.g., network admin vs. security admin vs. billing admin). Do not couple deploy and approve actions in a single principal.
  • Inheritance awareness: A binding at org/folder level affects all descendants; document intended blast radius before applying.

• Deny policies

  • IAM Deny explicitly blocks permissions even if granted elsewhere; use for guardrails (e.g., deny iam.serviceAccountKeys.create).
  • Deny takes precedence; ensure documented break-glass with time-bound exception processes.

• Examples

  • Copy a custom role from dev to prod: gcloud iam roles copy ROLE_ID
    –source=projects/DEV_PROJECT
    –destination=projects/PROD_PROJECT
  • Grant group-based SSH admin with OS Login: gcloud projects add-iam-policy-binding PROJECT_ID
    –member=group:ops-admins@example.com
    –role=roles/compute.osAdminLogin

• Failure modes

  • Editor granted at org or folder unintentionally cascades to all projects.
  • Conditional roles with overly strict conditions can silently break automations; test with Policy Troubleshooter before rollout.
  • Custom roles lag new permissions; review periodically.

Billing and Cost Administration

• Billing accounts and association

  • A project must be linked to exactly one billing account for billable services.
  • Roles: Billing Account Administrator manages account and payment methods; Billing Account User links projects; Project Billing Manager manages a project’s billing link.
  • Centralize to a corporate billing account; migrate projects by updating the project’s billing association.

• Budgets, alerts, and attribution

  • Budgets generate alerts, not spend caps. Use programmatic remediation with Pub/Sub and Cloud Functions/Cloud Run if enforcement is needed.
  • Export billing data to BigQuery for daily/monthly cost analytics and forecasting; combine with resource labels and tags for attribution.
  • Labels and tags: Standardize keys (e.g., cost_center, env, app). Missing labels reduce attribution accuracy.

• Cost analysis

  • Use BigQuery export to compute rolling forecasts by SKU/service with SQL. Join with resource metadata (e.g., GCE labels) for granular reporting.
  • For multi-project analysis, aggregate across all project exports or export to a single central dataset.

• Common pitfalls

  • Budgets not configured for new projects; establish a policy to auto-create budgets on project creation.
  • No BigQuery export means limited historical insight; enable early to build history.
  • Personal credit cards on projects fragment accountability; consolidate under the corporate billing account with appropriate IAM and payment profiles.
  • Cost anomalies in shared services projects require tagging and cross-charging policy.

Secure Workload Authentication and Access Patterns

• Service account impersonation

  • Prefer impersonation over keys. Grant roles/iam.serviceAccountTokenCreator to a caller identity; the caller obtains short-lived tokens to act as the service account.
  • Example: gcloud auth print-access-token
    –impersonate-service-account sa-deployer@PROJECT_ID.iam.gserviceaccount.com

• Keys and rotation

  • Avoid user-managed keys. If required, store in Secret Manager, rotate at least every 90 days, monitor usage, and restrict with VPC Service Controls and CMEK.
  • Enforce constraints to block key creation: constraints/iam.disableServiceAccountKeyCreation = true

• OS Login and SSH

  • Use OS Login with group-based IAM roles (compute.osLogin, compute.osAdminLogin). Each user uploads their public SSH key to their Google account for attributable access. Audit via Admin Activity and Data Access logs.
  • Avoid baking shared SSH keys in images.

• Workload Identity Federation

  • For on-prem or other clouds, configure identity federation to grant access to Google Cloud without creating keys, reducing exfiltration risk.

• Failure modes and mitigations

  • Storing keys in repos or CI/CD variables leads to compromise; switch to impersonation or federation.
  • Default service accounts with broad roles are risky; restrict with constraints/iam.allowedPolicyMemberDomains and remove primitive roles.
  • Missing scope on legacy GCE instances can block API access; prefer using per-API IAM plus default application credentials.

Governance, Organization Policies, Audit, and Troubleshooting

• Organization policies and constraints

  • Enforce guardrails using constraints: disallow external IPs on VMs, restrict regions, prevent key creation, restrict allowed services, require uniform bucket-level access, restrict domain sharing.
  • Target by resource hierarchy, and refine with tags for environment-specific exceptions.

• Cloud Identity and lifecycle

  • Cloud Identity provides the user directory, SSO, and administrative roles. Delegate narrowly (e.g., Group Admin, User Management Admin) and automate joiner-mover-leaver workflows to update group membership and access.
  • Use Access Approvals and Access Transparency for sensitive environments.

• Audit logging

  • Admin Activity and System Event logs are always on; Data Access logs must be explicitly enabled and can incur cost.
  • Centralize by routing aggregated sinks from folders/org to a security project. Protect with CMEK and restricted access.
  • Monitor Policy Denied logs to detect org policy conflicts.

• Multi-project troubleshooting toolkit

  • Policy Troubleshooter: Diagnose why access is allowed or denied given effective IAM and denies.
  • Cloud Asset Inventory: Query IAM bindings and policy history across org/folders/projects. Example: gcloud asset search-all-iam-policies
    –scope=organizations/ORG_ID
    –query=‘policy:roles/storage.objectAdmin AND “bucket-name”’
  • Logs Explorer: Filter by principal, method, and resource to trace actions across projects.
  • gcloud configurations for operator context switching: gcloud config configurations activate PROD
  • Common failure modes: conflicting org policies blocking deployments, missing Data Access logs hindering investigations, and IAM granted at the wrong scope. Establish runbooks and pre-change previews to reduce incident MTTR.

Practical Problem Scenario

Aurelia Retail consolidates multiple teams and projects after an acquisition. They must centralize billing, enforce consistent IAM and SSH administration across hundreds of Compute Engine VMs, and establish governance with minimal disruption.

1. Create a corporate billing account and link projects

• Rationale: A single billing account centralizes payment methods, credits, and budgets. Grant Billing Account User to a project migration group and Project Billing Manager to team leads to relink projects without over-privileging.
• Action: In the console, create the billing account. For each project, update its billing association. Immediately enable Billing export to BigQuery in a central analytics project.

2. Standardize resource hierarchy with folders and tags

• Rationale: Placing projects under env folders (prod, nonprod) supports inheritance of guardrails and targeted exceptions. Tags allow fine-grained org policy targeting without duplicating folder trees.
• Action: Create folders for prod and nonprod; move projects accordingly. Define tags env=prod|nonprod and app identifiers.

3. Implement group-based IAM with least privilege and separation of duties

• Rationale: Groups simplify lifecycle and auditing. Splitting roles among deployers, security, and network admins reduces blast radius.
• Action: Create Google groups for app-operators, net-admins, sec-admins, and billing-managers. Bind predefined roles at folder/project scope as needed; avoid basic roles.

4. Enforce OS Login-based SSH administration

• Rationale: Individual SSH keys attached to user accounts provide attributable, revocable access. OS Login roles manage Linux accounts via IAM, eliminating shared keys.
• Action: In each project, enable OS Login metadata. Grant compute.osAdminLogin to the ops-admins group. Example: gcloud compute project-info add-metadata
  –metadata enable-oslogin=TRUE

5. Replace service account keys with impersonation

• Rationale: Short-lived credentials mitigate key exfiltration risk and simplify rotation. Audit logs capture who impersonated whom, improving traceability.
• Action: Grant roles/iam.serviceAccountTokenCreator to CI/CD runner identities on workload service accounts. Remove user-managed keys and apply an org policy to block new keys.

6. Apply organization policies for guardrails

• Rationale: Constraints prevent risky configurations across all projects while allowing tagged exceptions where justified.
• Action: Enforce constraints to disallow external IPs in prod, restrict regions to approved locations, and disable service account key creation. Use tags to permit exceptions for specific projects with documented approvals.

7. Establish cost governance

• Rationale: Budgets alert owners before overspend; BigQuery export enables attribution and forecasting. Labels and tags map resource spend to cost centers.
• Action: Create budgets per folder and major application with Pub/Sub notifications. Enforce label policies via deployment templates and policy validation in CI.

8. Centralize audit and accelerate troubleshooting

• Rationale: Aggregated logging and asset inventory across the org speeds investigations and compliance reporting.
• Action: Create aggregated sinks to a security project with CMEK-protected buckets. Enable Data Access logs for critical services (Cloud Storage, BigQuery). Use Cloud Asset Inventory to routinely scan IAM bindings. Train operators to use Policy Troubleshooter when access fails and Logs Explorer to trace Admin Activity/Data Access.

9. Operationalize change with previews and staged rollout

• Rationale: Validating IAM and policy effects before enforcement reduces outages.
• Action: Test IAM and org policies in nonprod first. Use dry-runs and policy simulation where available. For deployment automation, implement canaries and backout plans.

This approach yields centralized billing and cost insight, attributable SSH administration via OS Login, least-privilege IAM with impersonation, strong preventive controls through org policies, and robust audit and troubleshooting across the new multi-project environment.

All domains · Compute Engine and Virtual Machine Operations →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Google →