Exam Professional Cloud Security Engineer topic 1 question 133 discussion

Answer = C "The folder structure can contain multiple data residency locations" suggest that restriction should be applied on projects level

Org policies can't be applied on resources ...

Reference: https://cloud.google.com/resource-manager/docs/organization-policy/defining-locations#overview A policy that includes this constraint will not be enforced on sub-resource creation for certain services, such as Cloud Storage and Dataproc. https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy#inheritance Cloud Storage is a resource eligibile for location constraints. All other options would be viable with the use of value groups, at either org, folder or project level, however, the only clue here is their data to be stored, which points to cloud storage. https://cloud.google.com/resource-manager/docs/organization-policy/defining-locations#value_groups

"The folder structure can contain multiple data residency locations" suggest that restriction should be applied on projects level

A Why not C?: Project-level constraints wouldn't offer the desired level of granularity. You might have data in a single project that needs to be stored in different locations based on regulations. Why no D?: Organization: An organization-level constraint would restrict all resources within the organization to a single residency location, which wouldn't meet the need for differentiated locations for various data sets.

Agree with C

https://cloud.google.com/assured-workloads/docs/data-residency#:~:text=Organizations%20with%20data%20residency%20requirements,select%20your%20desired%20compliance%20program. Organizations with data residency requirements can set up a Resource Locations policy that constrains the location of new in-scope resources for their whole organization or for individual projects. Answer C is a better choice, though this documenttalks about folders. But the questions says there are multiple data residency locations in that folders, so project level seems to be the best.

These restrictions can be applied at Org level, Folder Level or Project Level, but not resource level. Also, these policies are inherited, which means they need to be applied at the lowest child possible in the hierarchy where this is needed, not higher. This makes the answer specific to the use case rather than textbook knowledge. According to the given: "The folder structure can contain multiple data residency locations". This means that applying location restrictions at the Folder level or above will violate the requirement.This means you must apply the constraint at Project level. Quotes from the references below: "You can also apply the organization policy to a folder or a project with the folder or the project flags, and the folder ID and project ID, respectively." - no mention of resource level References: https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy https://cloud.google.com/resource-manager/docs/organization-policy/using-constraints

"C" Project Level These restrictions can be applied at Org level, Folder Level or Project Level, but not resource level. Also, these policies are inherited, which means they need to be applied at the lowest child possible in the hierarchy where this is needed, not higher. This makes the answer specific to the use case rather than textbook knowledge. According to the given: "The folder structure can contain multiple data residency locations". This means that applying location restrictions at the Folder level or above will violate the requirement.This means you must apply the constraint at Project level. Quotes from the references below: "You can also apply the organization policy to a folder or a project with the folder or the project flags, and the folder ID and project ID, respectively." - no mention of resource level References: https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy https://cloud.google.com/resource-manager/docs/organization-policy/using-constraints

C is the ans

C it is ----> Imp line to read from Question to understand why At Project level : 1. business data must be stored in specific locations due to regulatory requirements & The folder structure can contain multiple data residency locations. --- > Since Folder is going to contain multiple data residency locations and requirement is to restrict in specific location , so Constraints should be set at project level.

Project level seems to be reasonable.

As "The folder structure can contain multiple data residency locations." it has to be at project level

A lot of madness in these answers. It is C. You cant apply it at the org level since that effects everything. You cant apply it at the folder level since can contain locations. You CAN apply it at the project level. For those who say you cant apply these policies at the org level I suggest you spend more time reading docs and testing things in a lab. https://cloud.google.com/blog/products/identity-security/meet-data-residency-requirements-with-google-cloud To strengthen these controls further, Google Cloud offers Organization Policy constraints which can be applied at the organization, folder, or project level

the answer should be B https://cloud.google.com/resource-manager/docs/organization-policy/defining-locations

Different Locations therefore needs to be applied at Project Level.

To set an organization policy including a resource locations constraint: https://cloud.google.com/resource-manager/docs/organization-policy/defining-locations