Org Policies are how you set rules that apply across an entire Google Cloud organization. This article covers what they are, how they flow through the resource hierarchy, the constraints that come up most often, and how the Associate Cloud Engineer exam tests them.
It does not cover every available constraint, custom org policies, or the deeper compliance frameworks that build on top of Org Policies. The goal is to give you the mental model for the ACE exam, which means understanding what Org Policies do, where they sit in the hierarchy, and the few constraints that show up in exam questions.
You cannot understand Org Policies without understanding the GCP resource hierarchy. At the top is the Organization, which represents your company. Below that you can have Folders, which are optional containers for grouping projects. Below that are Projects, where actual resources live. Resources like VMs, buckets, and BigQuery datasets sit inside projects.
The important property of this hierarchy is that policies set at a higher level flow down to everything beneath. A policy applied at the Organization level applies to every folder, every project, and every resource in the company by default. A policy applied to a folder applies to every project inside that folder. You can override at lower levels in some cases, but the inheritance is the default behavior.
An Org Policy is a rule defined by a constraint. The constraint is the thing being controlled. Whether VMs can have external IPs, what regions resources can be created in, whether service account key creation is allowed, which domains can be granted IAM roles. Google publishes a list of available constraints, and you pick the ones relevant to your organization.
A policy attaches a constraint to a part of the hierarchy and says "enforce this." For example, you might attach the constraint that restricts resource locations to "us-central1, us-east1" at the Organization level. From that moment, nobody in any project under that organization can create a resource in europe-west2 unless an exception is granted at a lower level.
A few constraints come up far more often than others, both in real organizations and in exam questions. Rank these as the most important to know.
The first is restricting resource locations. Many companies have data residency requirements. European customer data has to stay in European regions. Government workloads have to stay in specific zones. The location restriction constraint enforces this at the platform level so an engineer cannot accidentally create a bucket in the wrong region.
The second is the constraint that disables external IPs on VMs. A lot of security policies require that VMs only be reachable through internal networks, VPN, or load balancers. Setting this constraint at the organization level means no one can spin up a Compute Engine instance with a public IP, even by accident.
The third is restricting which domains can be granted IAM roles. This stops a project owner from sharing access with an external Gmail account, which is a common mistake and a common compliance failure. Policies that limit IAM grants to "@yourcompany.com" close that gap.
The fourth is restricting service account key creation. Service account keys are a long-lived credential and Google would prefer you use Workload Identity or short-lived credentials instead. The constraint that disables key creation at the org level forces teams toward better patterns.
One thing worth being clear on is the relationship between Org Policies and IAM. They are different mechanisms doing different jobs.
IAM controls who can do what. It answers "is this user allowed to create a VM in this project." Org Policies control how things can be configured. They answer "if a VM gets created, what properties is it allowed to have."
You need both. IAM alone lets a project owner create any kind of VM they want, including ones with external IPs in regions you do not want resources in. Org Policies alone do not stop random people from getting access to your projects. Used together, they form the governance framework that the exam describes.
If you see a question about preventing certain configurations across an organization, regardless of who has IAM access, the answer is an Org Policy. If you see a question that mentions data residency, region restrictions, or compliance with location requirements, the answer is the resource location restriction Org Policy.
If you see a question about VMs that cannot have external IPs, or a security requirement that all compute be private, the answer is the constraint that disables external IPs, often combined with a load balancer or Cloud NAT for egress.
If you see a question that describes someone needing to manage these constraints, the role is Organization Policy Administrator. That is a separate role from Organization Administrator, and the exam occasionally tests the distinction.
Org Policies set platform-level rules through constraints, and those rules flow down the resource hierarchy from organization to folder to project. The constraints that matter most for the Associate Cloud Engineer exam are restricting resource locations, disabling external IPs, restricting domains for IAM grants, and restricting service account keys. They complement IAM rather than replace it.
If you see "enforce this rule across the entire company" in the question, think Org Policy. If you see a specific configuration constraint, think which constraint maps to it.
My Associate Cloud Engineer course covers Org Policies alongside the resource hierarchy and IAM, so you can see how the three layers fit together for governance scenarios on the exam.
