Google Cloud Professional Cloud Architect: Design for security and compliance Practice Questions

constraints/gcp.resourceLocations is an Organization Policy constraint that prevents GCP resources from being created or replicated outside specified locations. Setting this to EU regions ensures no storage or compute resources are provisioned outside the EU at the infrastructure level. Assured Workloads for EU provides a managed compliance framework that enforces data residency through technical controls including resource location restrictions, personnel access restrictions, and compliance monitoring, making it a strong complementary control. VPC Service Controls with IP-based access levels controls who can access the perimeter, not where data is stored or processed — it does not prevent resource creation outside the EU. Cloud DLP detects sensitive data patterns but cannot enforce where data is stored or processed; it is a detective control, not a preventive one for residency. Cloud Armor geographic restrictions block HTTP traffic at the load balancer level but do not prevent backend resources from being deployed or replicating data to non-EU regions.

Organization policy constraints are the correct mechanism for blanket, organization-wide restrictions. The iam.disableServiceAccountKeyCreation boolean constraint, applied at the organization node, prevents service account key creation in all child folders and projects, regardless of IAM roles held by users — including org admins. It cannot be overridden by individual project owners.

A (IAM deny policy) is plausible but wrong — An IAM deny policy can restrict specific principals, but you would need to enumerate all principals or use a complex binding. More importantly, org policy constraints are the idiomatic, scalable tool for this type of blanket resource restriction.

C (Removing IAM roles) is wrong — You would need to audit and modify every project individually, it doesn't scale, and new users granted those roles in the future would bypass the control.

D (Cloud Functions reactive deletion) is wrong — This is a compensating control, not a preventive one. There is a window during which the key exists and could be used or exfiltrated.

Binary Authorization is the correct answer. It enforces deploy-time policies on GKE (and Cloud Run) that require container images to be attested — cryptographically signed — before they are allowed to run. You configure an attestor linked to your internal build pipeline (e.g., Cloud Build), and the policy blocks any unsigned or improperly signed image.

A (Cloud Armor) is wrong — Cloud Armor is a WAF/DDoS protection layer for HTTP(S) traffic; it has no concept of container image signing.

C (Container Analysis) is wrong — Container Analysis provides vulnerability scanning metadata but does not itself enforce deployment policies; it can feed into Binary Authorization but is not the enforcement mechanism.

D (Security Command Center) is wrong — SCC detects threats and misconfigurations after the fact; it does not gate deployments based on image signatures.

IAM Conditions allow you to attach attribute-based logic to role bindings. The request.time attribute supports date/time expressions (using CEL — Common Expression Language), enabling you to restrict a binding so it is only effective during a specified time window (e.g., weekdays 09:00–17:00 UTC). The condition is scoped to the specific Cloud Storage bucket resource.

A (Workforce Identity Federation with ABAC) is wrong — Workforce Identity Federation manages external identity providers and ABAC maps identity attributes to roles, but it doesn't natively enforce time-of-day access windows at the binding level by itself.

C (VPC Service Controls access level) is wrong — VPC-SC access levels can include time conditions, but they apply to the entire service perimeter, not to individual IAM role bindings on a specific resource, and they require the contractor to be inside a perimeter.

D (Org policy constraint) is wrong — Organization policies enforce resource configuration constraints (e.g., allowed locations, key settings); they cannot restrict when IAM bindings are effective for specific users.

Creating dedicated, minimally-privileged service accounts for each workload is the primary best practice for service account security, as it limits the blast radius of any single compromise and makes permissions auditable. Setting constraints/iam.automaticIamGrantsForDefaultServiceAccounts prevents GCP from automatically assigning the Editor role to the default service account in new projects, which is a proactive org-wide control. Rotating the service account key does not reduce the scope of the Editor role and addresses a different risk (key leakage, not over-privilege). Deleting the default service account can break existing workloads and services without a proper migration plan; it is disruptive and not a best practice recommendation. Adding IAM Conditions to the Editor role is complex, error-prone, and does not eliminate the fundamental problem of overly broad permissions; creating a minimally-privileged role is always preferred.