Configuring Access and Security practice questions

Answer: A) A leaked key in project metadata could open every VM that accepts project keys; this VM now accepts only its own instance-level keys

Project-wide SSH keys are accepted by every VM that doesn't block them, so one leaked key can expose the whole project. Blocking them on a sensitive VM limits SSH access to keys added to that VM's own metadata.

• ACorrect. Keys stored in project metadata are accepted by every VM in the project that doesn't block them, so one compromised project key exposes all of those VMs. With block-project-ssh-keys set to TRUE, the VM ignores project metadata keys and accepts only keys added to its own instance metadata, which shrinks the blast radius.
• BIncorrect. Blocking project-wide keys does not turn on OS Login or 2-step verification. Those are separate settings (enable-oslogin and related metadata). The VM still accepts SSH keys from its own instance metadata.
• CIncorrect. This setting only controls which metadata SSH keys the VM accepts. It does not change network interfaces, external IP addresses, or firewall and IAP access paths.
• DIncorrect. Service account authorization comes from IAM roles and access scopes, not SSH key metadata. Blocking project-wide SSH keys has no effect on the VM's API permissions.

Answer: A) Enforce the storage.publicAccessPrevention organization policy constraint at the organization node

Enforcing constraints/storage.publicAccessPrevention at the organization node blocks public access for all buckets under it, new and existing. Uniform bucket-level access, per-bucket scripts and audit-log alerts each miss either IAM-based public access, future buckets or prevention.

• ACorrect. When this boolean constraint is enforced at the organization level, every bucket under it, new and existing, inherits public access prevention. Requests authorized through allUsers or allAuthenticatedUsers fail with 401 or 403, and attempts to add those principals to an IAM policy or ACL fail with 412.
• BIncorrect. This constraint forces uniform bucket-level access, which turns off object ACLs. But a bucket-level IAM policy can still grant access to allUsers, so buckets can still be made public.
• CIncorrect. This protects only the buckets that exist when the script runs. Buckets created later aren't covered, so it isn't a central, organization-wide control.
• DIncorrect. An alert only tells the team after the public binding exists, so data can be exposed until someone fixes it. It detects the problem but doesn't prevent it.

Answer: A) An egress rule on perimeter A and an ingress rule on perimeter B, scoped to that Cloud Storage access

Google recommends ingress and egress rules over perimeter bridges for sharing between VPC Service Controls perimeters. An egress rule on the source perimeter plus an ingress rule on the destination can allow exactly one identity, service, and method, while a bridge opens bidirectional access.

• ACorrect. Ingress and egress rules give fine-grained control over access between perimeters. For cross-perimeter access, the source perimeter needs an egress rule and the destination perimeter needs an ingress rule. Both can be limited to specific identities, projects, services, and methods. Google recommends these rules over perimeter bridges.
• BIncorrect. A perimeter bridge is bidirectional. It gives the bridged projects equal access to each other's protected services within the bridge's scope, so it cannot limit access to one bucket, one service, or one direction. Google recommends ingress and egress rules instead.
• CIncorrect. A project can belong to only one regular service perimeter. Communication across the perimeter boundary has to be allowed with ingress and egress rules (or, in older designs, a bridge).
• DIncorrect. VPC accessible services limits which services can be reached from networks inside a perimeter. It does not let a client in another perimeter access protected resources across the boundary.

Answer: A) Limit bucket IAM access to the CI/CD service account and a few admins, enforce public access prevention, and add customer-managed encryption

Terraform state can hold secrets in plaintext, so protect the state bucket as strictly as the secrets themselves: tight IAM access, public access prevention, and stronger encryption, with state kept out of version control.

• ACorrect. Google recommends that only the build system and highly privileged administrators can access the remote state bucket. It also recommends enforcing public access prevention, using uniform bucket-level access so IAM controls access, and adding customer-supplied or customer-managed encryption keys on top of default encryption at rest.
• BIncorrect. Giving broad read access exposes any plaintext secrets in the state to everyone with that role. Default encryption at rest does not stop authorized readers from seeing the contents.
• CIncorrect. Google recommends a remote Cloud Storage backend specifically to keep state and sensitive information out of version control. Committing state to Git spreads secrets to everyone with repository access.
• DIncorrect. A retention policy blocks deletion and overwriting, which would get in the way of normal Terraform state updates. It does nothing to restrict who can read the objects, so it does not protect the secrets.

Answer: A) A custom security policy rule that matches on origin.region_code and denies requests from countries outside the approved list

Cloud Armor geo-based access control uses the origin.region_code attribute in custom rules to allow or deny requests by the client's country. WAF rules, Adaptive Protection and named IP lists solve other problems.

• ACorrect. The origin.region_code attribute holds the ISO 3166-1 alpha-2 country code linked to the client IP. A custom rule can match on it to allow or deny traffic by country, which is geo-based access control.
• BIncorrect. Preconfigured WAF rules detect attack patterns in request contents, such as the OWASP Top 10. They do not filter requests by the client's country.
• CIncorrect. Adaptive Protection looks for Layer 7 DDoS-style anomalies and suggests mitigations. It does not apply a fixed country allowlist or denylist.
• DIncorrect. Named IP address lists hold the IP ranges of particular providers, such as CDNs. They identify those providers, not the country of an arbitrary client.

Answer: A) Editor grants far more access than the app needs, violating least privilege

Where the Compute Engine default service account holds Editor, attaching it to VMs grants far more access than most workloads need, which violates least privilege. Google recommends user-managed service accounts with narrowly scoped roles. New organizations block the automatic Editor grant by default.

• ACorrect. Editor is a broad basic role that allows modifying most resources in the project. If the VM were compromised, an attacker would get all of that access. Google recommends a user-managed service account granted only the roles the workload needs, such as read access to the single bucket. That is also why the iam.automaticIamGrantsForDefaultServiceAccounts constraint, enforced by default for organizations created on or after May 3, 2024, blocks the automatic Editor grant.
• BIncorrect. The default service account is a normal IAM principal and can be granted roles on Cloud Storage buckets. The concern is excessive privilege, not a lack of access.
• CIncorrect. Many VMs in a project can use the same service account at the same time. Sharing one broadly privileged identity across many VMs actually makes the least-privilege problem worse.
• DIncorrect. A VM with an attached service account gets short-lived credentials from the metadata server. Google manages these, so no user-managed key needs to be stored or rotated.

Answer: A) Access Transparency, which writes logs of Google personnel actions on customer content

Access Transparency logs record when Google personnel access customer content and why. Cloud Audit Logs cover the customer's own principals and Google's automated system events, and Access Approval controls access but does not log it.

• ACorrect. Access Transparency logs record actions that Google personnel take when accessing Customer Data. Each entry includes the affected resource and action, the time, the justification, and information about who accessed it. The logs are delivered through Cloud Logging.
• BIncorrect. Access Approval lets the company approve or dismiss requests from Google personnel before they access data. It is a control on access, not the feature that records the access. The log of what Google personnel actually did comes from Access Transparency, which is often used together with Access Approval.
• CIncorrect. Data Access audit logs record API calls made by principals in the customer's environment that read or modify data. They don't record Google support or engineering staff accessing content.
• DIncorrect. System Event audit logs cover automated actions by Google systems that change resource configuration, such as live migration. They don't record human Google personnel accessing customer content or the reason for that access.

Answer: A) Create a Cloud KMS key with the EXTERNAL protection level using Cloud External Key Manager (Cloud EKM), and use it as the CMEK for those services

Cloud EKM keys use the EXTERNAL protection level: the key material stays in a key manager the customer controls and is never stored or cached in Google Cloud. Software, HSM, and imported keys, as well as default encryption, all keep key material inside Google's infrastructure.

• ACorrect. With Cloud EKM, the key material is created and stored in the company's own external key management system. It never leaves that system and is never cached or stored in Google Cloud. The Cloud EKM key is still used as a customer-managed encryption key (CMEK) for supported services.
• BIncorrect. Cloud HSM keys are generated and stored in hardware security modules that Google operates in its own data centers. The key material therefore resides in Google's infrastructure, which breaks the requirement.
• CIncorrect. Creating the key on premises gives the company control over how it is generated. However, importing it copies the key material into Cloud KMS, so it ends up stored in Google's infrastructure.
• DIncorrect. Default encryption uses keys that Google creates and manages inside its own infrastructure. The company has no control over that key material.

Answer: A) Create the perimeter in dry run mode and review its logged violations

A VPC Service Controls perimeter in dry run mode logs requests that would violate it without denying them. Teams use it to test a configuration safely before enforcing it.

• ACorrect. In dry run mode, requests that violate the perimeter are logged as if it were enforced, but they aren't denied. The team can analyze the logs, fix the configuration, and then enforce it.
• BIncorrect. An enforced perimeter blocks violating requests immediately, so production traffic would be disrupted before the team could adjust the configuration.
• CIncorrect. VPC Flow Logs record network flows to and from VM interfaces. They don't evaluate Google API requests against a service perimeter's rules, so they can't show which requests a planned perimeter would block.
• DIncorrect. Policy Troubleshooter explains IAM allow and deny decisions. It doesn't simulate a planned service perimeter that hasn't been created yet.

Answer: A) Use user-managed replication with europe-west1 and europe-west4 as replica locations

Only user-managed replication lets you choose an exact set of regions for a global secret's replicas. Automatic replication doesn't restrict locations, and a regional secret lives in just one region.

• ACorrect. User-managed replication copies the payload only to the locations you configure, and you can list several regions. That meets both the location limit and the two-region availability requirement.
• BIncorrect. With automatic replication, the payload is replicated without restriction to locations Google chooses. A customer-managed encryption key controls who can decrypt the data, not where the replicas are stored.
• CIncorrect. A regional secret is stored in a single location and isn't replicated to another region. It meets the residency rule but not the requirement to keep copies in both regions.
• DIncorrect. Labels are metadata for organizing and filtering resources. They have no effect on where Secret Manager stores replicas, so automatic replication still replicates without restriction.