Exam Professional Cloud Security Engineer topic 1 question 221 discussion

As other mentions, Org policies are not retroactive. But, the external IP assignment would be done after the Org policy was set. It is then, when the policy will prevent the VM to get assigned an External IP. That's why option A is not the right answer. However, as option C mentions, you can override the policy at project level to be more permissive, which would allow you to create new instances with external IP associated.

- :Enforcement of most organization policies is not retroactive - The policies are merged and the DENY value takes precedence (https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy#reconciling_policy_conflicts)

- :Enforcement of most organization policies is not retroactive - The policies are merged and the DENY value takes precedence (https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy#reconciling_policy_conflicts)

https://cloud.google.com/resource-manager/docs/organization-policy/creating-managing-policies#creating_and_editing_policies Enforcement of most organization policies is not retroactive. If a new organization policy sets a restriction on an action or state that a service is already in, the policy is considered to be in violation, but the service will not stop its original behavior. Organization policy constraints that are retroactive note this property in their description.

When you define an organizational policy in Google Cloud, it applies to future actions and configurations, not to resources that already exist or were configured before the policy was set. If a static external IP address had been reserved in the project prior to the policy being applied, it could be assigned to a new VM after the policy enforcement starts. This would result in a VM with an external IP address, despite the organizational policy. C. A project-level organizational policy control has been overwritten with an "allow" value. Organizational policies propagate from the top (organization) to the bottom (project), unless specifically overridden. However, the question specifies the policy was applied at the folder level, which would affect all projects under that folder. This is less likely unless explicitly overridden at the project level, which the question does not suggest.

Tricky one tbh. dry-run mode for org policies now exist and so technically speaking, answer B could now be the answer to the Q. Either way its between B or C in my opinion. https://cloud.google.com/resource-manager/docs/organization-policy/dry-run-policy

"under that folder"...

Answer A: f a static external IP address was reserved before the organizational policy to deny the assignment of external IP addresses to VMs was enacted, creating a VM and attaching this pre-reserved static external IP address would not violate the policy.

in this scenario, the alert is triggered because the VM creation violates the folder-level "deny" policy, but that restriction is nullified by the overriding "allow" value inherited from the organization-level policy.

According to this link https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address#disableexternalip

I think A is correct answer. Because this policy organization is not retroactive. https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address#disableexternalip

The correct answer is C. At a project level, the organizational policy control has been overwritten with an “allow” value. Policies can be overridden at a lower level (like a project). So, if an “allow” policy was set at the project level, it would override the “deny” policy set at the folder level. This could allow a VM with an external IP address to be created under that folder, despite the folder-level policy. Changes to organizational policies can take time to propagate and be enforced across all resources, but in this case, the alert was received two days after the policy was set, which should have been sufficient time for the policy to take effect. Therefore, options A, B, and D are less likely.

A:Enforcement of most organization policies is not retroactive. If a new organization policy sets a restriction on an action or state that a service is already in, the policy is considered to be in violation, but the service will not stop its original behavior.https://cloud.google.com/resource-manager/docs/organization-policy/creating-managing-policies#creating_and_editing_policies

https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy#reconciling_policy_conflicts Says "The policies are merged and the DENY value takes precedence" So.. How can C be the answer?

Here's why option C is the likely cause: Overriding Policy at the Project Level: Google Cloud allows for policies to be set at different levels of the resource hierarchy, such as the organization, folder, or project level. If a policy is set at the organization or folder level to deny external IP addresses but is then overridden with an "allow" value at the project level, it would take precedence, allowing VMs within that project to have external IP addresses. Alert Trigger: When an organizational policy constraint is overridden at a lower level (e.g., project), it can lead to situations where the policy is not enforced as expected. This can result in alerts or notifications when policy violations occur.

A. Even if IP created after org policy was set it wont allow to use it B. we can preview the org policy function using dry run (Preview mode) in this policy won't deny the usage, but it will notify. C. we cant put deny org policy at org policy and expect it will override with allow value

C should be correct https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy