[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-18。"],[],[],null,["# Understanding hierarchy evaluation\n\n\u003cbr /\u003e\n\nWhen you set an [organization policy](/resource-manager/docs/organization-policy/overview) on a resource, all descendants\nof that resource inherit the organization policy by default. If you set an\norganization policy on your organization resource, then those restrictions are\ninherited by all child resources.\n\nYou can set the same organization policy with a different configuration on child\nresources, which will overwrite or merge with the inherited policy based on the\nrules of hierarchy evaluation.\n\nBefore you begin\n----------------\n\n- Read the [Understanding constraints](/resource-manager/docs/organization-policy/overview#constraints) page to learn\n about what a constraint is.\n\n- Read the [overview of the Organization Policy Service](/resource-manager/docs/organization-policy/overview) to learn about how\n organization policy works.\n\nExample hierarchy\n-----------------\n\nIn the following resource hierarchy diagram, each resource sets an organization\npolicy and defines whether it inherits its parent resource's policy. The colored\nshapes represent the values that the organization policy allows or denies.\n\nA **Constraint** is a definition of the behaviors that are controlled by an\norganization policy. In the preceding example, the **Constraint** represents the\n*constraint default* , which defines the behavior when there is no organization\npolicy for the constraint. The constraint default in this example allows\nall_inclusive all\nvalues. The nodes below it define organization policies that override\nthe constraint default by allowing or denying values.\n\nThe effective policy on each node is evaluated based on the rules of\ninheritance. If an organization policy is not set, the resource inherits\nthe default constraint behavior. If you set an organization policy, your\npolicy is used instead. In the preceding example, the **Organization Node**\ndefines a policy that allows square red\nsquare and circle green\ncircle.\n\nThe resources that are in the hierarchy below the **Organization Node**\nare evaluated as follows:\n\n1. **Resource 1** defines a policy that sets `inheritFromParent` to `TRUE` and\n allows square\n blue diamond. The policy from the **Organization Node** is\n inherited and merged with the policy set on **Resource 1** . The effective\n policy evaluates to allow square red\n square, circle green\n circle, and\n square\n blue diamond.\n\n2. **Resource 2** defines a policy that sets `inheritFromParent` to `TRUE` and\n denies circle green\n circle. Deny values always take precedence during policy\n reconciliation. The policy from the **Organization Node** is inherited and\n merged with the policy set on **Resource 2** . The effective policy evaluates\n to allow only square red\n square.\n\n3. **Resource 3** defines a policy that sets `inheritFromParent` to `FALSE` and\n allows hexagon yellow\n hexagon. The policy from the **Organization Node** is not\n inherited, so the effective policy evaluates to only allow\n hexagon yellow\n hexagon.\n\n4. **Resource 4** defines a policy that sets `inheritFromParent` to `FALSE` and\n includes the `restoreDefault` value. The policy from the\n **Organization Node** is not inherited, and the default constraint behavior\n is used, so the effective policy evaluates to allow all_inclusive all\n values.\n\nHierarchy evaluation rules\n--------------------------\n\nThe following rules govern how an organization policy is evaluated at a\ngiven resource. You need the\n[**Organization Policy Administrator**](/resource-manager/docs/organization-policy/using-constraints#add-org-policy-admin)\nrole to set organization policy.\n\n### No organization policy set\n\nIf you don't set an organization policy, then a resource inherits from its\nlowest ancestor with a policy set. If there is no policy set anywhere in the\nancestor hierarchy, then the default behavior of the constraint is enforced.\n\n### Inheritance\n\nA resource that has an organization policy set by default supersedes any\npolicy set by its parent resources in the hierarchy. However, if a resource has\nset `inheritFromParent = true`, then the effective Policy of the parent resource\nis inherited, merged, and reconciled to evaluate the resulting effective\npolicy. For example:\n\n- A folder denies the value `projects/123`.\n- A project underneath that folder denies the value `projects/456`.\n\nThe two policies are merged, and in this case result in an effective policy that\ndenies both `projects/123` and `projects/456`.\n\n#### Inheriting default behavior\n\nDefault behavior is never merged. When a policy is set, it always replaces any\ndefault behavior. For example:\n\n- The `constraints/iam.allowServiceAccountCredentialLifetimeExtension` is set to `DENY` by default at organization level.\n- For this constraint, a project directly underneath that organization allows the value `SomeServiceAccount`.\n\nSince the default behavior is never merged and always replaced, this results in\nan effective policy which allows `SomeServiceAccount`. In contrast, if the\npolicy were set *explicitly* to `DENY` at the organization level, the \"`DENY`\nvalue takes precedence\" rule would apply and the effective policy would be\n`DENY`.\n\n### Disallow inheritance\n\nIf a resource has a policy that includes `inheritFromParent = false`, it doesn't\ninherit the organization policy from its parent. Instead, the resource inherits\nthe constraint's default behavior unless you set a policy with allowed or denied\nvalues.\n\n### Reconciling policy conflicts\n\nWhen a resource inherits organization policies, the inherited policies are\nmerged and reconciled with the organization policy of the parent resource. When\nevaluating organization policies with list rules, `DENY` values always take\nprecedence. For example:\n\n- A folder denies the value `projects/123`.\n- A project underneath that folder allows the value `projects/123`.\n\nThe policies are merged and the `DENY` value takes precedence. The effective\npolicy denies all values, and evaluates the same way whether the parent or\nchild resource denies the value. We recommend not including a value in both the\nallowed and denied lists. Doing so can make it harder to understand your\npolicies.\n\nOrganization policies with boolean rules don't merge and reconcile\npolicies. If a policy is specified on a resource, that `TRUE` or `FALSE` value\nis used to determine the effective policy. For example:\n\n- A folder sets `enforced: true` for\n `constraints/iam.managed.disableServiceAccountCreation`.\n\n- A project underneath that folder sets `enforced: false` for\n `constraints/iam.managed.disableServiceAccountCreation`.\n\nThe `enforced: true` value set on the folder is ignored because\n`enforced: false` is defined on the project itself. The organization policy\nis not enforced on that project.\n\nReset to default policy\n-----------------------\n\nBy invoking `RestoreDefault`, the organization policy uses the default\nbehavior of the constraint for this resource. Child resources also inherit this\nbehavior."]]