Org Policies are one of those topics on the Professional Data Engineer exam that look simple on paper and then get surprisingly tricky in scenario questions. The exam likes to put you in the shoes of a data engineer who needs to enforce compliance across an entire organization, and it expects you to reach for Org Policies instead of writing a memo and hoping every team follows it.
In this post I want to walk through what Org Policies actually do, the specific constraints I see show up most often on the Professional Data Engineer exam, and how inheritance and exceptions work across the resource hierarchy.
Picture running a business with real compliance and security requirements. You might need to keep all your data inside the United States, block traffic from certain countries, or guarantee that every VM is encrypted to a certain standard. The question is how you enforce those rules without manually auditing every project and every resource.
That is the job Org Policies do. They are the centralized governance tool inside Google Cloud Platform that lets you enforce organization-wide rules on resource usage and configuration. You set the rule once, and it applies everywhere underneath the level where you set it.
The other piece I want you to internalize is how Org Policies relate to IAM. IAM controls who can do things with your resources. Org Policies control how those resources can be configured and used. The two work together. IAM hands out the keys, and Org Policies define which doors those keys are even allowed to unlock.
There are a handful of specific constraint names that have a way of appearing in exam scenarios. If you only memorize four for the Professional Data Engineer exam, make it these.
The pattern across all four is the same. The exam describes a governance worry, and the right answer is a constraint that bakes the rule into the platform so engineers cannot accidentally violate it.
Org Policies can be set at three levels of the resource hierarchy: Organization, Folder, and Project. Policies flow downhill. If you set a policy at the Organization level, every Folder and every Project under it inherits that policy by default.
This is what makes Org Policies so useful for governance. You do not have to chase down every project owner and ask them to apply the same rule. You set the rule at the Organization level once, and the entire tree picks it up automatically.
The exam loves to test this. If a question describes a company that wants a single rule enforced across all current and future projects, the answer is almost always to set the Org Policy at the Organization level and let inheritance do the work.
Inheritance would be brittle on its own, because real organizations always have one team that legitimately needs an exception. Maybe a data science group needs to spin up VMs in a region that is otherwise restricted, or a partner integration project needs to allow members from an outside domain.
Lower levels can override inherited policies. You can override a policy at the Folder level or at the Project level, and the exception only applies to that subtree. The exception can either relax the inherited policy, making it less restrictive, or tighten it, making it more restrictive than what was inherited.
The mental model I want you to carry into the exam is this. The Organization level is your baseline. Folders and Projects can deviate from the baseline in either direction. So if a question describes a setup where one project needs an exception to a company-wide rule, you do not change the company-wide rule. You override the policy at that specific project.
Exam scenarios on Org Policies tend to come in two flavors. The first flavor describes a compliance requirement and asks you to pick the right constraint. The trick there is knowing the four constraints above well enough to recognize them on sight. The second flavor describes a hierarchy of folders and projects and asks where to set or override a policy. The trick there is remembering that inheritance flows downhill and that exceptions live at the level where the deviation is needed.
If you can answer both flavors quickly, you have probably squeezed everything out of this topic that the Professional Data Engineer exam is going to ask. The depth of knowledge required is real but bounded.
My Professional Data Engineer course covers Org Policies and the rest of the governance and compliance topics that show up on the exam, including how IAM, Org Policies, and the resource hierarchy fit together.
