Prepare and test your skills
Prepare and test your skills
Organizing resources in Google Cloud means arranging the Organization resource, folders, and projects into a hierarchy that controls security, governance, and cost. The Resource Manager (opens in a new tab) provides this tree, while Identity and Access Management (IAM) and the Organization Policy Service provide the access grants and guardrails that flow through it. A well-designed hierarchy limits blast radius so a compromise or misconfiguration in one project does not spread to sibling projects.
The Google Cloud resource hierarchy is a tree with the Organization resource as the root, folders in the middle, and projects as leaves that hold service resources. Folders can contain both projects and other folders up to 10 levels deep, with up to 300 child folders under one parent, and they group related projects so IAM permissions and organization policies cascade to everything below. Projects contain virtual machines, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints, and each project is both a trust boundary and an IAM enforcement point. This structure lets a central team set a secure baseline at the top while delegating narrower control to environment, team, or application folders below.
A common pattern places Development and Production folders on the first level below the Organization, then App 1 and App 2 folders inside each environment, then separate projects for independent modules. The Bootstrap folder sits directly below the Organization and holds infrastructure-as-code, pipelines, and deployment foundations, so highly privileged deployer identities stay separated from every environment. Shared infrastructure such as central monitoring sits below the Organization when one instance serves all environments, while a separate shared folder sits inside each environment folder when production and non-production secrets and policies must remain distinct.
A Google Cloud project is the primary container for deployment, cost attribution, and capacity. Every service resource lives inside a project, every project links to a billing account for charges, and quotas are measured and enforced per project. Billing is assigned at the project level, not to folders, but costs can be aggregated upward in billing reports to show folder-level totals. Because quotas are per project, spreading clusters or applications across projects prevents one autoscaled workload from exhausting limits for an entire environment.
Projects isolate configuration, security, and quota at their boundary. IAM configuration is per project, a compromised workload in one project has limited impact on workloads in other projects by default, and quota exhaustion stays contained. A platform team can place one cluster per project inside a per-environment folder to roll out IAM changes progressively and apply folder-level aggregated log sinks, while a smaller organization can keep all clusters for an environment in one project to reduce overhead but loses that blast-radius protection. New projects are created under a selected Organization or folder parent with a name of 4 to 30 characters using only letters, numbers, single quotes, hyphens, spaces, or exclamation points, plus a billing link.
Organization policies are central guardrails defined as constraints and enforced by the Organization Policy Service at request time. A policy attaches at the organization, folder, or project level and flows to all descendants, so resource location limits, network rules, and allowed services protect every project beneath the node without per-project configuration. Inheritance for organization policies is replacement-based: a child policy supersedes the inherited parent policy for that branch. This differs from IAM allow policies, which are additive from parent to child, while IAM deny policies are evaluated before allow policies and can override them.
Standardized naming and labels support application-centric ownership on top of this hierarchy. Labels are key-value pairs on resources that flow into Cloud Billing reports and BigQuery export for chargeback when project-level reporting is not detailed enough, covering compliance scope, multi-cloud identity, and cost granularity. Application Hub (opens in a new tab) defines an application management boundary through a management project, where choosing a single project, folder, or set of projects shapes governance and discovery. Google Kubernetes Engine (opens in a new tab) multi-tenancy patterns use the same idea to align folder and project boundaries with team structures and to isolate tenants by project and tag when hierarchy alone is too coarse.
Exam tip: A lower-level organization policy replaces an inherited organization policy, while a lower-level IAM allow policy adds to an inherited allow policy — only an IAM deny policy overrides an allow policy.
Continue with this study guide: Organizing resources (e.g., application-centric, projects, folders)
Shared networking in Google Cloud connects workloads across projects and organizations while keeping central control of routing, firewalls, and service exposure. Shared VPC (opens in a new tab) centralizes the network in a host project, VPC Network Peering merges forwarding between two VPC networks, and Private Service Connect exposes one service through a private endpoint. The three models differ in trust scope, transitivity, and whether they share subnets or only a single service.
Shared VPC is a centralized model where one host project owns the Virtual Private Cloud (VPC) network and attached service projects own the workloads that use it. The host project holds the global VPC network, regional subnets, routes, and Cloud Firewall rules, while each service project holds instances such as Compute Engine virtual machines that receive internal IP addresses from the shared subnets. Traffic flows from instances in the service project into subnets owned by the host project, so the service project depends on the host project for routing, firewall evaluation, and hybrid connectivity.
IAM separation enforces least privilege between network owners and workload owners. Network administrators receive roles in the host project to create subnets, routes, and firewall rules, while instance administrators in service projects receive permission only to use authorized subnets. Granting the network user role at the subnet level limits a service project to only its assigned subnets, while granting it at the host-project level makes all subnets available. Provisioning follows a fixed order: first create the host project, enable the Compute Engine API, enable Shared VPC, create a custom-mode VPC network with regional non-overlapping subnets and Private Google Access, then create each service project, enable its Compute Engine API, attach it to the host, and grant subnet access.
VPC Network Peering connects two VPC networks so workloads communicate with internal RFC 1918 addresses over Google's private backbone without traversing the public internet. Peering works across projects and organizations and is often used for hub-and-spoke designs where spoke application networks reach common logging, authentication, or egress controls in a central hub. After peering is established, subnets, alias ranges, and internal forwarding rules in one network become reachable from the other with the same forwarding behavior as if all virtual machines were in one network at full VM bandwidth.
Peering is non-transitive and requires non-overlapping IP ranges. Routes learned from one peer are not passed to another peer, so traffic flows from a spoke to the hub and from the hub to a spoke but not from spoke to spoke through the hub. Peering also keeps firewalls separate: the distributed firewall in the source network evaluates outbound traffic and the firewall in the destination network evaluates inbound traffic, so both sides need allow rules. To enable spoke-to-spoke or transitive hybrid reach, place shared services directly in the hub, use Cloud VPN with custom route advertisement, deploy a network virtual appliance in the hub for inspection and forwarding, or use Network Connectivity Center (NCC) VPC spokes for scalable transitive exchange.
Private Service Connect (PSC) lets one VPC network consume a specific service in another network through a private internal IP address without exposing the entire producer network. The consumer creates a PSC endpoint, which is a forwarding rule with an internal IP address in the consumer network that represents the distant service. The producer hosts the service behind an internal load balancer and publishes it through a service attachment in the producer network. Traffic flows from consumer virtual machines to the consumer endpoint, then across Google's private backbone to the producer attachment and load balancer, so only the published service is visible.
Layer 4 and Layer 7 consumption differ in producer requirements. At Layer 4, the producer must create PSC-specific NAT subnets in each publishing region, and Private Service Connect performs source network address translation from those subnets, which allows overlapping consumer and producer addresses for TCP or UDP. At Layer 7, the consumer uses an internal Application Load Balancer with a URL map to choose services and paths by host and path for HTTP routing. For Google APIs such as Cloud Storage, BigQuery, and Cloud Logging, the consumer configures PSC endpoints plus Private Cloud DNS zones that map *.googleapis.com with a CNAME to restricted.googleapis.com and an A record to the endpoint IP, paired with firewall rules that allow TCP:443 to the endpoint and deny 0.0.0.0/0 to force traffic through the endpoint.
Exam tip: Grant the network user role at the subnet level for least privilege, and keep multi-network-interface bridging in a single host project because all bridged VPC networks must reside in the same project.
Multi-project monitoring and logging collects logs and metrics from many projects into central destinations for security, compliance, and operations. Log entries flow from workload projects through organization or folder sinks into a central log bucket, while time-series data stays in its source project but becomes visible through a metrics scope attached to a scoping project. Central IAM, retention locks, and alerting protect these destinations because they concentrate sensitive operational data.
The central Logging bucket is the recommended aggregation point for organization-level audit and operational logs. The bucket lives in a designated central project, and all child projects route copies of their logs to it through an aggregated sink created at the organization or folder level. An aggregated sink captures matching entries from that resource and all current and future child projects, applies its inclusion filter, and writes to one destination, so new projects are covered automatically. Building the path follows an ordered workflow: first create the central bucket or BigQuery dataset, then create the aggregated sink with an inclusion filter, then grant the sink writer identity write permission, then grant analysts separate read permission, then verify arrival from multiple projects.
Central destinations differ in routing path and analysis use. Observability Analytics in a Logging bucket receives entries directly through the sink for central search and log-based alerting, while a BigQuery dataset receives entries directly through the sink for long-term SQL joins and partitioned retention. Google Security Operations uses built-in direct ingest for a predefined security subset without a sink, while third-party SIEM export flows from projects through a sink to Pub/Sub or Cloud Storage and then to the external tool. By default logs are stored for 30 days, 365 days is recommended for large enterprises, custom retention ranges from 1 day to 3650 days, and storage beyond 30 days incurs retention cost.
A metrics scope is the Cloud Monitoring (opens in a new tab) construct that defines which Google Cloud projects and AWS accounts are visible to a scoping project. By default the console shows only time series stored in the selected scoping project, and visibility expands by configuring the scope to include other projects. The scoping project also stores dashboards, alerting policies, uptime checks, and synthetic monitors, while underlying metric data remains in each monitored project. Removing a project from the scope immediately removes its metrics from central view without deleting source data.
Once a project joins the scope, its system, agent, custom, derived, Prometheus, and log-based metrics become selectable in central charts and alerts, with project_id labels preserving source identity for filtering and comparison. A unified custom dashboard in the scoping project can show metric charts and tables from any scoped project, log data and error groups, alert charts and status, text runbooks, and operational events such as reboots. Queries can be built by menu selection or written in Prometheus Query Language (PromQL) or Monitoring filter syntax in the console and API, and one expression can aggregate CPU, latency, or custom metrics across development, staging, and production. A single alerting policy can then evaluate that scope, for example notifying when VM CPU exceeds 80% across environments through email, PagerDuty, or Slack, with each notification linking to an incident record.
Central observability access is limited by group-based IAM and immutable retention. Central administrators hold Logging Admin and Monitoring Admin through groups such as gcp-organization-admins or gcp-logging-monitoring-admins, while workload teams receive narrow view rights to their own data. Retention policies with Bucket Lock make the audit trail immutable so even privileged admins cannot delete evidence early. Hygiene guardrails require corporate credentials with multi-factor authentication, Google-managed service account keys with 90-day rotation, no Admin privileges on service accounts, private Cloud KMS keys with separation of managers and users, and restricted API keys.
Different audit log types have different enablement rules. Admin Activity, System Event, and Access Transparency logs are included by default when routed, while Data Access and Policy Denied logs export centrally only if enabled in source projects. Log-based alerts watch the aggregated Admin Activity stream for project ownership changes, audit configuration changes, custom role changes, firewall and route changes, storage IAM changes, and SQL configuration changes. Identity monitoring completes the loop by tracking group membership for non-corporate accounts, alerting on suspicious service account API calls, routing Essential Contacts to a monitored group alias, and streaming selected logs to Pub/Sub for external investigation with inclusion filters to control volume and cost.
Exam tip: Admin Activity logs cannot be disabled or excluded, while Data Access and Policy Denied logs must be explicitly enabled before a central sink can export them.
Continue with this study guide: Multi-project monitoring and logging
IAM roles and organization-level policies together enforce least privilege and compliance across the hierarchy. Identity and Access Management (IAM) (opens in a new tab) allow policies bind principals to roles on a resource node and inherit downward, while the Organization Policy Service constrains what configurations those identities can create. Troubleshooting effective access means walking the hierarchy path to find which level granted access and which deny policy, boundary, or constraint removed it.
The IAM access model binds a principal such as a user, service account, Google Group, or Cloud Identity domain to a role containing permissions through an allow policy attached to an organization, folder, or project. When granted, the principal receives all permissions in the role but nothing more, and the grant inherits to that node and all children unless constrained. Predefined roles such as Storage Admin, Organization Policy Administrator, Project Creator, and Billing Account User match known job functions, custom roles narrow a predefined set to fewer permissions, and basic roles such as Owner and Editor are broad legacy grants to avoid. Start with the predefined job-function role and create a custom role only when it remains too broad or mixes duties that must be separated.
Placement is itself a least-privilege control. Organization grants reach every folder and project, folder grants reach all projects beneath that folder, and project grants stay inside one project. Least privilege places each grant at the lowest node that covers the work: organization only for central admins, folder for team or environment administration, and project for workload operators. Assign roles to Google Groups rather than individuals, and harden automation by disabling automatic Editor grants to default service accounts with constraints/iam.automaticIamGrantsForDefaultServiceAccounts set to False, blocking user-managed key creation and upload, enforcing 90-day rotation, and using Workload Identity Federation instead of long-lived keys.
The Organization Policy Service evaluates every relevant create or update request against constraints attached to the target node and denies non-compliant requests. Managed constraints cover broad guardrails such as allowed regions, allowed services, allowed IAM members, and TLS versions, while custom constraints restrict specific resource fields such as Vertex AI or Workload Identity Federation pool fields when no managed constraint is precise enough. Central admins own guardrails at the organization or folder, project teams own workloads inside those boundaries, and enforcement happens at request time.
Location, service, and identity constraints use allowlists that default to deny, while the TLS constraint uses a denylist. Resource Location Restriction gcp.resourceLocations limits creation to approved regions for residency, gcp.restrictServiceUsage allowlists vetted services per folder with tighter production lists, and domain restricted sharing iam.allowedPolicyMemberDomains allowlists trusted customer IDs to block external accounts. Restrict TLS Versions gcp.restrictTLSVersion denies explicit old versions, so allowing only TLS 1.3 requires denying TLS_VERSION_1, TLS_VERSION_1.1, and TLS_VERSION_1.2 at the organization. Tags add conditional enforcement beyond hierarchy position by letting a policy check for a tag before allowing an operation, avoiding extra folders solely for policy boundaries.
Effective access reflects direct policies plus every inherited policy from parent folders and the organization, plus limits from deny policies, principal access boundary (PAB) policies, IAM Conditions, tags, and organization constraints. A parent folder can contain up to 300 folders nested up to 10 levels deep, so one high-level grant can reach a very large descendant set. IAM Conditions and tags conditionally allow or deny by resource attributes, deny policies constrain which permissions can be exercised or granted including pipeline setIamPolicy rights, and PAB policies set an organization-level upper bound that reduces blast radius of a compromised identity.
Policy changes do not remediate existing resources retroactively: a new organization policy blocks only future transitions from compliant to non-compliant values and leaves existing configurations valid but non-compliant until separately fixed. A child can override inherited organization policy with its own policy, so strict defaults belong high in the hierarchy with narrow exceptions below. An unexpected allow often comes from an inherited folder grant, group membership, default service account Editor rights, or a *.setIamPolicy permission that let a pipeline expand its own access, while an unexpected denial often comes from a deny or PAB policy, condition or tag mismatch, domain restriction, or disabled key creation. Cloud Audit Logs record high-risk grants such as Organization Admin and Super Admin to support diagnosis.
Exam tip: Granting any *.setIamPolicy permission has the effect of granting full access to that resource unless an IAM deny policy constrains it.
Creating and managing service accounts means deciding where workload identities live, controlling how they are created, and securing how they authenticate. A service account is both a principal that can receive IAM roles on resources and a resource that other principals can be given permission to use. Least privilege must apply on both sides: limit what the account can reach and limit who can use the account.
Service account placement determines ownership for the account's lifetime. Each account lives in one project, cannot be moved after creation, and is limited per project by quota. Same-project accounts place the account with the resources that use it for easy start but harder tracking, while centralized accounts place accounts in a small number of dedicated projects for easier management but require cross-project attachment. When a centralized account in my-service-accounts accesses a Cloud SQL instance in my-application, the Cloud SQL API must be enabled in both projects and the account must be attached to the resource in the other project.
Organization policy controls where accounts can be created and what they receive by default. The constraints/iam.disableServiceAccountCreation constraint blocks creation on an organization, folder, or project to support centralization, while constraints/iam.automaticIamGrantsForDefaultServiceAccounts set to False stops automatic Editor grants to default accounts. Compute Engine (opens in a new tab) default accounts illustrate the risk: without the constraint, a new default account receives roles/editor automatically so one workload compromise can control the whole project. Consistent display names capturing purpose and owner prevent confusion as inventory grows, and unused accounts are disabled before deletion to shrink lateral movement paths without breaking unknown dependencies.
Authentication security replaces long-lived user-managed keys with short-lived credentials. User-managed keys stay valid until deleted or rotated, so a leaked key retains access indefinitely without rotation. The iam.disableServiceAccountKeyCreation constraint set to True blocks new user-managed keys and iam.disableServiceAccountKeyUpload blocks external public keys, while constraints/iam.serviceAccountKeyExpiryHours with <= 2160 enforces rotation at least every 90 days where keys remain. Tags allow narrow exceptions by attaching disableServiceAccountKeyCreation=enforced at the organization by default and not_enforced on exempt folders or projects with a tag-scoped policy.
Workload Identity Federation is the preferred keyless replacement for hybrid and multi-cloud workloads. A workload identity pool trusts an external provider, the workload obtains its native credential, exchanges it with the Security Token Service for a federated token, then impersonates a service account for a short-lived Google access token. The impersonated account should live in the same project as the resources it accesses with a dedicated account per application, and roles/iam.workloadIdentityUser must be granted only to specific external identities, never to all pool members. Inside Google Cloud, an attached service account lets a virtual machine inherit identity directly, while containers on GKE use Workload Identity Federation for GKE to map pods to Google accounts without keys.
Service account impersonation occurs when an authenticated principal acts as a service account to gain its permissions, with requests flowing to Google APIs under the service account identity. Service Account User with iam.serviceAccounts.actAs allows attaching the account to a resource so code on that resource runs as the account, while Service Account Token Creator with iam.serviceAccounts.getAccessToken allows requesting short-lived tokens directly via CLI, libraries, or the Service Account Credentials API. Manage access on each individual account rather than at the project level, because Token Creator on a project lets the holder impersonate every account in that project and reach all resources those accounts can access.
Temporary elevation with the Service Account Credentials API avoids standing privilege by using a supervisor account and token broker. First create dedicated single-purpose accounts per job, then create a supervisor with Token Creator on those accounts, then allow only the broker to use the supervisor, then have the broker mint short-lived tokens per job with Credential Access Boundaries for further downscoping. Monitoring with Cloud Audit Logs links activity to abuse by enabling data-access logs for token creation and getIamPolicy or setIamPolicy calls, using single-purpose accounts and per-account bindings for attribution, and correlating with CI/CD history. Do not rely on coarse Compute Engine access scopes instead of IAM, avoid basic Owner or Editor roles, and avoid domain-wide delegation that could impersonate any user including super-admins.
Exam tip: Key creation and key upload are blocked by two separate constraints — iam.disableServiceAccountKeyCreation stops new user-managed keys, while iam.disableServiceAccountKeyUpload stops upload of external public keys.
Continue with this study guide: Creating and managing service accounts
Data residency is the physical location of data plus the local laws that govern how that data is stored, encrypted, and accessed. In Google Cloud, residency is enforced through three linked controls: configuring where data rests, controlling where encryption keys live, and controlling where data can be reached from. Prevention blocks non-compliant provisioning before resources exist, while detection finds drift after deployment.
Geographic constraints are enforced with the Organization Policy Service constraint constraints/gcp.resourceLocations set on an organization, folder, or project. The policy declares allowed Google Cloud locations, then every new creation request for supported services is compared to those values and denied if it does not match. The check applies only to newly created resources, while resources created before enforcement continue unchanged. Because the location property identifies where a service deploys a resource and for some resources where data is stored, the constraint creates a compliant footprint for future deployments but is not a data storage commitment.
The constraint does not cover global resources such as Compute Engine global addresses, resources without a selectable location, or every product type, and it does not control sub-resource creation for services such as Cloud Storage in the same way. Location types form a hierarchy from multi-region such as us or europe down to region such as us-west1 or europe-west1 and zone such as us-east1-b, plus specialized AI zones. Value groups with the in: prefix express geography without listing every location, but an invalid group name fails the policy change. Inheritance flows downward, so an organization policy restricts all children while a folder policy narrows enforcement for testing or jurisdictional boundaries. Apigee shows the dependency: without data residency the effective constraint must allow global for the global control plane, while with data residency it must not exclude the selected control plane region.
Compliant storage keeps regulated data in an approved physical location while meeting availability and recovery needs. Cloud Storage (opens in a new tab) bucket location determines footprint: single-region stores in one administrator-chosen region for strictest locality, dual-region stores in an administrator-chosen pair for bounded recovery, and multi-region stores across a broad area for highest durability at the broadest footprint. Objects in dual and multi-region are stored in at least two geographically separate areas with asynchronous replication. When strict recovery proof is required, two single-region buckets with dual-write or explicit copy provide auditable control.
Cloud SQL pins managed relational data at rest to the chosen creation region for MySQL, PostgreSQL, and SQL Server, with backups kept inside the same boundary, while a cross-region read replica adds a second residency location that must be allowed. BigQuery residency is set by dataset location, regional for one jurisdiction or multi-regional for availability, with backups kept inside the boundary and multi-region backups avoiding regions inside that multi-region scope. Firestore regional confines data to one region while multi-region replicates across zones and regions, and Bigtable production uses at least two clusters in unique zones of one region with automatic replication and failover. Cryptographic separation adds control: Cloud External Key Manager keeps keys persistently outside Google for BigQuery and Compute Engine, while customer-supplied encryption keys are supplied per operation for Cloud Storage and Compute Engine and purged afterward, so data outside the approved area remains unreadable but depends on key-manager availability for recovery time.
Automated compliance is a two-layer system with preventive policy-as-code and detective inventory monitoring. Prevention declares allowed regions in constraints/gcp.resourceLocations, defines infrastructure with Terraform, and validates plans in Cloud Build pipelines with security gates that reject non-compliant code before apply. Assured Workloads control packages preset allowed values at the folder level, where loosening the list would allow creation outside the compliant boundary with difficult-to-reverse effects. Effective policies start from explicit requirements for data at rest, encryption mitigation, in-place versus external processing, multi-region redundancy, and access locality.
Detection compares actual runtime location against the allowed policy with Cloud Asset Inventory feeding Security Command Center posture findings mapped to ISO 27001 and NIST 800-53. Two high-severity detectors illustrate a Europe-only boundary: RESOURCE_LOCATION_NOT_ALLOWED validates that the policy permits only europe-west3, europe-west4, europe-west6, and europe-west8, while RESOURCE_LOCATION_OUTSIDE_EUROPE flags deployed resources running outside those regions. Both operate in Detective and Audit modes for organization, folder, and project targets. Remediation migrates, redeploys, or deletes the violating resource into an allowed region and hardens prevention to deny future creation there, sustained by VPC isolation, firewall rules, IAM allow policies, GKE scheduling, version-controlled pipelines, enabled audit logging, and regular review with automated analysis.
Exam tip: constraints/gcp.resourceLocations blocks creation of new resources in disallowed regions but does not move existing violating resources — existing resources must be migrated, redeployed, or deleted.
Continue with this study guide: Data residency
*.setIamPolicy permission has the effect of granting full access to that resource unless constrained by an IAM deny policy, and a service account lives in one project and cannot be moved after creation.Organization policy inheritance is replacement-based, so a child policy supersedes the inherited parent policy for that branch, while Identity and Access Management allow policies are additive from parent to child. Only an Identity and Access Management deny policy overrides an allow policy because deny policies are evaluated before allow policies.
Use Shared Virtual Private Cloud when one host project should own the Virtual Private Cloud network, subnets, routes, and firewall rules while attached service projects own workloads that use it. Use VPC Network Peering when two VPC networks need private connectivity with internal addresses, remembering that peering is non-transitive and keeps firewalls separate, and use Private Service Connect when one VPC network should consume only a specific service in another network through a private internal IP address without exposing the entire producer network.
Aggregated sinks created at the organization or folder level capture matching log entries from all current and future child projects and write them to a central Logging bucket in a designated central project. A metrics scope attached to a scoping project makes time-series data from other projects visible for central charts and alerts while the underlying metric data remains in each monitored project.
Last updated