# Answers and teaching explanations

Contains all 200 questions, keys, rationale for each option and official references. Open after completing the relevant set. Independent proposed keys, not Google grading.

## Set 1

<a id="q001"></a>
### PCSE200-001 — Choose ONE

A Cloud SQL for PostgreSQL instance uses built-in database passwords and direct client connections. A control requires encryption in transit and rejection of clients without a trusted client certificate, even if a password is known. The current ENCRYPTED_ONLY setting passes an encryption test, but a client without a certificate can still connect using valid credentials. Client applications already support certificate management. What should the engineer configure? Choose ONE answer.

**A.** Keep ENCRYPTED_ONLY and configure clients to validate the server certificate without supplying client certificates.

**B.** Configure each approved client to present a certificate but leave the server's ENCRYPTED_ONLY policy unchanged.

**C.** Require trusted client certificates at the instance and deploy the trusted certificate material to approved clients.

**D.** Keep ENCRYPTED_ONLY and limit authorized networks to the application's source addresses.

**Answer: C**

ENCRYPTED_ONLY requires encrypted transport but does not validate client certificates. TRUSTED_CLIENT_CERTIFICATE_REQUIRED adds the requested client-certificate requirement for this built-in-password/direct-connect scenario.

**Guide mapping:** 3.2; Require client authentication as well as encrypted SQL transport. **Editorial difficulty:** medium.

- **A:** Server identity validation is useful but does not make the instance require client certificates.
- **B:** Well-behaved clients presenting certificates does not make the server reject a client that omits one.
- **C:** This adds the missing transport-level client authentication.
- **D:** Source-address restrictions do not establish the required trusted-client-certificate control.

- [Configure SSL/TLS certificates](https://docs.cloud.google.com/sql/docs/postgres/configure-ssl-instance) — ENCRYPTED_ONLY encrypts connections without requiring validated client certificates.

Sources checked 2026-11-03. Original author ID: `DATA-031`.

---

<a id="q002"></a>
### PCSE200-002 — Choose ONE

A team maps Google API names to restricted.googleapis.com and permits egress only to its VIP. They successfully call Cloud Storage and conclude that no object can leave their organization through Google APIs. However, no VPC Service Controls perimeter has been configured, and the workload has permissions on a test bucket in an external project. The requirement is to prevent unauthorized cross-project managed-service transfers. What additional action is necessary? Choose ONE.

**A.** Configure and enforce the appropriate service perimeter and exceptions; the restricted VIP alone limits reachable services, not the approved resource boundary.

**B.** Remove Cloud NAT and leave the current API configuration unchanged because NAT is the only way to reach an external project's bucket.

**C.** Replace the restricted VIP with private.googleapis.com because the private name automatically limits access to the client's organization.

**D.** Allow egress only to the four restricted-VIP addresses and treat that destination-IP restriction as the external-project boundary.

**Answer: A**

The restricted VIP narrows access to services supporting perimeter controls; it does not create a perimeter or decide the organization's allowed resource relationships by itself.

**Guide mapping:** 2.2; Separate restricted API reachability from resource perimeter enforcement. **Editorial difficulty:** hard.

- **A:** The missing resource-boundary control must be configured explicitly.
- **B:** Google API resource access can occur without Cloud NAT.
- **C:** The private VIP does not automatically authorize only organization-owned resources.
- **D:** Restricting the API frontend addresses still does not identify which managed-service resource projects are approved.

- [Set up private connectivity to Google APIs and services](https://docs.cloud.google.com/vpc-service-controls/docs/set-up-private-connectivity) — Restricted VIP routing uses the default internet gateway privately; DNS and hybrid custom advertisements are separate requirements.
- [Overview of VPC Service Controls](https://docs.cloud.google.com/vpc-service-controls/docs/overview) — Service perimeters constrain supported data-service access and cross-perimeter data transfers.

Sources checked 2026-11-03. Original author ID: `NETWORK-032`.

---

<a id="q003"></a>
### PCSE200-003 — Choose ONE

An Agent Platform assistant helps employees review tasks in an external project-management service. The service supports three-legged OAuth, and users must see only tasks they themselves are authorized to access. The deployment has Agent Identity and auth manager available. A shared machine credential currently lets the assistant read every team's tasks, with a prompt asking it to filter by employee name. Which replacement best enforces the intended authority model? Choose ONE answer.

**A.** Grant the agent broader Google Cloud IAM roles so its workload identity automatically becomes each external user.

**B.** Keep the machine credential but put each employee's name in a separate system prompt.

**C.** Use two-legged OAuth client credentials for all employees and label requests with the user's email.

**D.** Configure a scoped three-legged OAuth auth provider and invoke the tool with the consenting user's delegated authority.

**Answer: D**

User-delegated OAuth supplies the external service with the user's consent and permissions. Agent identity still identifies the workload; it is not a substitute for end-user authorization.

**Guide mapping:** 3.3; Use user-delegated authority for personal tool data. **Editorial difficulty:** hard.

- **A:** Google Cloud roles do not create the external user's delegated permission.
- **B:** Prompt filtering does not constrain the external service's authorization decision.
- **C:** Machine-to-machine authority is not transformed into user authority by request labels.
- **D:** The documented auth provider supports calls on a particular user's behalf.

**Service assumption/limitation:** Assumes the documented Agent Identity/auth-manager integration is available in the deployment's region.

- [Authenticate using 3-legged OAuth with auth manager](https://docs.cloud.google.com/iam/docs/auth-with-3lo-v2) — A 3-legged OAuth auth provider manages user consent and tokens for calls on that user's behalf.
- [Identity delegation architecture](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/identity-delegation-architecture) — Delegated tool calls must satisfy both agent governance and the user's permissions and consented scopes.

Sources checked 2026-11-03. Original author ID: `DATA-044`.

---

<a id="q004"></a>
### PCSE200-004 — Choose ONE

A telemetry processor publishes messages to one Pub/Sub topic in a project containing several independent applications. It never reads subscriptions, changes topic settings, or publishes to the other topics. The topic already exists and supports a resource-level IAM policy. Security wants the permission to remain limited even when new topics are added to the same project. Which grant best matches the workload requirement? Choose ONE.

**A.** Grant the processor the Pub/Sub Publisher role on the one topic.

**B.** Grant the processor the Pub/Sub Editor role on the topic.

**C.** Grant the processor the Pub/Sub Publisher role on the project.

**D.** Grant the processor the Pub/Sub Viewer role on the project.

**Answer: A**

Scope and permissions both matter. Topic-level Publisher gives the required operation on the intended resource without extending to sibling or future topics.

**Guide mapping:** 1.4; Choose the narrowest useful resource binding. **Editorial difficulty:** medium.

- **A:** Correct: it matches both the operation and the resource.
- **B:** Editor adds management capabilities the workload does not need.
- **C:** Project scope unnecessarily includes other topics.
- **D:** Viewer does not supply the publishing permission.

- [Using resource hierarchy for access control](https://docs.cloud.google.com/iam/docs/resource-hierarchy-access-control) — Effective IAM allow access combines local and inherited grants.

Sources checked 2026-11-03. Original author ID: `ACCESS-034`.

---

<a id="q005"></a>
### PCSE200-005 — Choose ONE

A company exposes an HTTPS customer API directly from VM external addresses. It now needs managed filtering for SQL-injection patterns in HTTP requests and wants clients to use one public entry point. It can terminate TLS at a managed load balancer, and backend access can be limited to that load-balancer path. Which design best supplies the requested web application protection while closing the direct path? Choose ONE.

**A.** Use a global external proxy Network Load Balancer with a TCP backend and expect its connection-level policy to inspect HTTP SQL-injection patterns.

**B.** Use a passthrough Network Load Balancer with destination-port firewall rules and rely on those rules to identify SQL-injection payloads.

**C.** Use a global external Application Load Balancer with a Cloud Armor backend security policy and restrict direct access to the VM backends.

**D.** Keep the VM public addresses and attach a Cloud Armor HTTP WAF policy directly to each VM network interface.

**Answer: C**

Cloud Armor application security integrates with supported HTTP load-balancing paths. Restricting backend ingress prevents clients from bypassing the new WAF entry point.

**Guide mapping:** 2.1; Place web attack filtering on an appropriate load balancer. **Editorial difficulty:** medium.

- **A:** Connection-level controls on this TCP path do not provide the requested HTTP WAF inspection.
- **B:** Port filtering lacks the requested HTTP payload detection.
- **C:** This establishes a supported HTTP inspection point and closes the bypass path.
- **D:** Cloud Armor HTTP WAF policies are not directly attached to VM interfaces.

- [Security policy overview](https://docs.cloud.google.com/armor/docs/security-policy-overview) — HTTP application security policies and rate limiting capabilities depend on load balancer and policy type.
- [Identity-Aware Proxy overview](https://docs.cloud.google.com/iap/docs/concepts-overview) — Backend access paths must be secured independently of enabling IAP on a load balancer.

Sources checked 2026-11-03. Original author ID: `NETWORK-014`.

---

<a id="q006"></a>
### PCSE200-006 — Choose ONE

A payroll VM has only an internal IPv4 address. A newly peered engineering VPC has routes to it, and an existing broad ingress rule allows the engineering subnet to reach every TCP port. Payroll's owner says the VM is already isolated because it lacks a public address. The required state is that only the application tier may reach the payroll service, while the peering remains for other systems. What is the best correction? Choose ONE.

**A.** Replace the broad ingress permission with a narrowly scoped application-tier rule and verify that other applicable policy layers do not permit engineering access.

**B.** Keep the broad ingress permission but remove the payroll hostname from engineering DNS, preserving its internal IP address.

**C.** Retain the broad ingress rule and restrict the payroll VM's service account to read-only Google API access.

**D.** Keep the broad ingress rule and enable Private Google Access because private addressing already isolates application ports.

**Answer: A**

An internal address prevents ordinary direct internet addressing, but reachable private networks still need explicit authorization boundaries. The stated exposure is an overly broad ingress permission.

**Guide mapping:** 2.1; Distinguish private addressing from access control. **Editorial difficulty:** medium.

- **A:** Narrowing effective ingress implements the required application boundary.
- **B:** Engineering clients can still use the reachable internal address, so DNS omission does not enforce the required boundary.
- **C:** Restricting the VM's API identity does not restrict incoming engineering network connections.
- **D:** Private Google Access concerns Google APIs, not protection from routed engineering clients.

- [VPC Network Peering](https://docs.cloud.google.com/vpc/docs/vpc-peering) — Peering is nontransitive, does not exchange firewall rules, and requires nonoverlapping IPv4 subnet ranges.
- [VPC firewall rules](https://docs.cloud.google.com/firewall/docs/firewalls) — VPC firewall decisions depend on rule priority, target and source scope; tracked connections are stateful.

Sources checked 2026-11-03. Original author ID: `NETWORK-011`.

---

<a id="q007"></a>
### PCSE200-007 — Choose TWO

A media company grants production read access through a Google group rather than individual bindings. Team leads can add members, and an investigation finds that unrestricted external membership could indirectly admit outside users to production. The company wants to retain group-based administration and avoid rewriting every project policy for staff changes. Which TWO controls best address the actual authorization path? Choose TWO.

**A.** Audit only project IAM edits and assume stable group bindings imply that the same people retain access.

**B.** Retain unrestricted membership changes but require each project owner to review the group's address quarterly.

**C.** Restrict and audit who may change the access group's membership, including external membership rules.

**D.** Retain narrowly scoped group IAM bindings and reconcile membership with approved joiner, mover, and leaver events.

**Answer: C, D**

Anyone who can change an access group's effective membership can influence access conferred by its IAM binding. Both IAM scope and directory membership governance therefore matter.

**Guide mapping:** 1.4; Govern membership of an IAM access group. **Editorial difficulty:** hard.

- **A:** Group membership can change effective access without a change to the project binding.
- **B:** Reviewing a group address without controlling membership does not close the outsider admission path.
- **C:** Correct: membership administration is part of the access boundary.
- **D:** Correct: lifecycle reconciliation preserves the group model while controlling approved access.

- [Use IAM securely](https://docs.cloud.google.com/iam/docs/using-iam-securely) — Least privilege, separation of duties and group-based grants reduce unnecessary privileges.
- [Directory API: Group Members](https://developers.google.com/workspace/admin/directory/v1/guides/manage-group-members) — The Directory API manages group memberships programmatically.

Sources checked 2026-11-03. Original author ID: `ACCESS-040`.

---

<a id="q008"></a>
### PCSE200-008 — Choose ONE

A production GKE cluster has Binary Authorization enabled. The project default admission rule requires the security attestor and uses block-and-audit enforcement. A test image without that attestation still deploys. The image is not exempt and no breakglass annotation is present. The policy also contains a cluster-specific rule created during an earlier pilot that allows all images. Other clusters correctly reject the test image. Which correction best targets the cause? Choose ONE.

**A.** Remove Artifact Registry read permission from the deployer and retain the production allow rule for image pulls by the node identity.

**B.** Change the default rule from block-and-audit to dry-run for one test and assume the narrower rule will inherit the default evaluation mode.

**C.** Remove or correct the production cluster-specific allow rule so the intended attestation requirement applies.

**D.** Add another attestor to the existing default rule without changing the cluster-specific allow rule.

**Answer: C**

The default rule applies when no more specific matching rule governs deployment. A cluster-specific allow rule can explain why only that cluster bypasses the intended default requirement.

**Guide mapping:** 4.1; Identify a more specific GKE admission rule that overrides the default. **Editorial difficulty:** medium.

- **A:** Registry permissions control artifact access, not the missing release-approval requirement at admission.
- **B:** The matching cluster-specific allow rule remains the governing rule; dry-run also weakens default enforcement elsewhere.
- **C:** This removes the specific exception responsible for the observed behavior.
- **D:** Strengthening a default does not fix a matching allow rule that takes precedence.

- [Binary Authorization concepts](https://docs.cloud.google.com/binary-authorization/docs/key-concepts) — The default rule applies when no specific rule matches; GKE supports cluster-specific admission rules.

Sources checked 2026-11-03. Original author ID: `OPS-038`.

---

<a id="q009"></a>
### PCSE200-009 — Choose ONE

Pine Health sends inline inspection requests to Sensitive Data Protection's global endpoint with the approved region in the request path. Its revised architecture standard requires Customer Data handling, including TLS termination and in-transit handling by the service, within that region. Regional endpoint support is available, and the client originates inside the approved region. Quotas and latency have been tested successfully for the regional endpoint. Which change addresses the remaining service-endpoint requirement? Choose ONE.

**A.** Keep the global endpoint and add the approved region to the inspection template's display name.

**B.** Configure the supported regional hostname with the matching location in the request path, and verify that the client uses it.

**C.** Keep the global endpoint and rely on the processing location because it also fixes the global frontend's TLS termination location.

**D.** Keep the global endpoint and enable CMEK on the bucket storing the inspection results.

**Answer: B**

The global endpoint's processing-location selector does not guarantee in-transit locality. The supported regional endpoint addresses the stated service handling requirement.

**Guide mapping:** 5.1; Distinguish processing locality from regional endpoint transport locality. **Editorial difficulty:** hard.

- **A:** Display metadata does not choose the endpoint.
- **B:** This changes the service endpoint and matching request location.
- **C:** The processing selector does not impose the required TLS/in-transit boundary.
- **D:** Encryption of stored results does not control the request frontend.

**Service assumption/limitation:** The regional endpoint guarantee excludes Service Data. This scenario does not assume arbitrary external client networks are confined by the API setting.

- [Global and regional endpoints for Sensitive Data Protection](https://docs.cloud.google.com/sensitive-data-protection/docs/api-endpoints) — A location on a global endpoint controls processing but not in-transit locality; supported regional endpoints regionalize TLS termination and Customer Data handling.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-019`.

---

<a id="q010"></a>
### PCSE200-010 — Choose ONE

A central security team has attached a deny policy to a production folder. It denies a supported destructive permission to a contractor principal set, and the rule's condition is true. A project administrator then grants a contractor a custom role containing that permission on a resource beneath the folder. The contractor reports that the operation still fails. No exception principal applies. Which explanation best describes the result? Choose ONE.

**A.** Custom roles automatically bypass deny rules because their permissions were explicitly selected.

**B.** Deny policies apply only to the folder resource itself, so the failure must be unrelated.

**C.** The inherited deny prevents use of the permission despite the new allow binding.

**D.** The resource-level allow is more specific and should override the folder deny after another login.

**Answer: C**

A deny policy inherited from an ancestor prevents the covered principal from using a denied permission, regardless of local allow roles.

**Guide mapping:** 1.4; Apply an inherited deny despite local allow. **Editorial difficulty:** hard.

- **A:** Custom roles are still subject to applicable deny policies.
- **B:** Folder deny policies apply to descendants.
- **C:** Correct: the conditions in the stem establish an applicable inherited deny.
- **D:** IAM deny does not use a most-specific-allow override model.

**Service assumption/limitation:** Only permissions supported by IAM deny can be denied; support is explicitly stipulated.

- [Deny policies](https://docs.cloud.google.com/iam/docs/deny-overview) — Deny rules apply before allow grants and inherit from organization, folder or project attachment points.

Sources checked 2026-11-03. Original author ID: `ACCESS-033`.

---

<a id="q011"></a>
### PCSE200-011 — Choose ONE

A logistics company grants application read access to a Google group. HR has approved adding forty new analysts to that group, and the existing lifecycle service can call the Admin SDK with the required delegated administrative permissions. Administrators want onboarding to remain auditable and repeatable without adding forty individual IAM bindings or replacing the group's current members. What should the lifecycle service do? Choose ONE.

**A.** Use the Directory API group-member operations to add the approved memberships and reconcile responses.

**B.** Grant the lifecycle service Project IAM Admin and use it to update users' Google group memberships.

**C.** Recreate the group with the same address and assume its access bindings will remain attached.

**D.** Replace the group's IAM binding with bindings for every incoming employee.

**Answer: A**

Group membership belongs in the directory control plane. Adding approved members keeps the existing IAM group binding and membership set intact.

**Guide mapping:** 1.1; Administer groups through an authorized lifecycle integration. **Editorial difficulty:** medium.

- **A:** Correct: membership operations automate the approved change without replacing the group.
- **B:** Cloud project IAM administration is not delegated Directory API group administration.
- **C:** Recreation is disruptive and unnecessary when the group-member API exists.
- **D:** This creates unnecessary per-user IAM administration and abandons the desired access group.

- [Directory API: Group Members](https://developers.google.com/workspace/admin/directory/v1/guides/manage-group-members) — The Directory API manages group memberships programmatically.

Sources checked 2026-11-03. Original author ID: `ACCESS-004`.

---

<a id="q012"></a>
### PCSE200-012 — Choose ONE

An enterprise wants applications to access a supported bundle of global Google APIs through a customer-selected internal IPv4 endpoint. The VPC has subnets 10.20.0.0/24 and 10.21.0.0/24, and the address plan reserves nonoverlapping 10.90.0.10 outside all local and peered subnet ranges. No conflicting route or allocation exists. The team does not want an internet-facing VM proxy. Which endpoint configuration meets the address and service requirements? Choose ONE.

**A.** Create a regional VM forwarding appliance using 10.90.0.10 and call it a Private Google Access subnet gateway.

**B.** Create a private services access peering range and expect it to assign one endpoint for every global Google API.

**C.** Reserve 10.20.0.15 from the application subnet and use it as the global Google API bundle endpoint address.

**D.** Create a Private Service Connect endpoint targeting the API bundle with an appropriate global internal address resource for 10.90.0.10.

**Answer: D**

PSC global Google API endpoints use global internal addresses outside local and peered subnet ranges. They provide the requested private address without a proxy VM.

**Guide mapping:** 2.3; Place a PSC endpoint for global Google APIs. **Editorial difficulty:** medium.

- **A:** The requested managed endpoint does not require a VM appliance, and PGA is not this gateway model.
- **B:** Private services access is a different connection mechanism for supported producer-VPC services.
- **C:** Global API endpoint addresses cannot be allocated from a configured subnet range.
- **D:** The proposed address and global endpoint match the stated requirements.

- [About accessing global Google APIs through endpoints](https://docs.cloud.google.com/vpc/docs/about-accessing-google-apis-endpoints) — Global Google API PSC endpoints use a global internal IPv4 address outside subnet ranges and support hybrid access.

Sources checked 2026-11-03. Original author ID: `NETWORK-037`.

---

<a id="q013"></a>
### PCSE200-013 — Choose ONE

A bank's organization firewall policy delegates traffic from an approved analytics subnet with a priority-100 goto_next rule. The same policy contains a priority-200 deny for all remaining traffic. A folder policy below it allows analytics connections to a particular VM service. An auditor expects the priority-200 organizational deny to block even the analytics connection. Both rules match its addresses. For a new connection, which explanation correctly describes the delegation? Choose ONE.

**A.** The organization and folder priorities are merged, so the outcome depends on the folder allow's numerical priority.

**B.** The matching goto_next skips remaining rules in that policy and continues at the next applicable policy layer.

**C.** The organizational deny still wins because deny overrides goto_next regardless of the two priorities.

**D.** The priority-100 rule allows the packet immediately, so the folder policy is never evaluated.

**Answer: B**

goto_next transfers evaluation to the next applicable layer. It neither allows the connection itself nor resumes at the next rule in the same policy.

**Guide mapping:** 2.1; Use goto_next for delegated firewall administration. **Editorial difficulty:** hard.

- **A:** Rule priorities order a policy's rules; they do not merge organization and folder policies.
- **B:** This describes the intended delegation behavior.
- **C:** The earlier matching delegation prevents the later rule in that policy from being considered.
- **D:** Delegation does not itself grant access.

- [Firewall policy rule components](https://docs.cloud.google.com/firewall/docs/firewall-policies-rule-details) — goto_next delegates to the next policy layer rather than the next rule in the same policy.

Sources checked 2026-11-03. Original author ID: `NETWORK-003`.

---

<a id="q014"></a>
### PCSE200-014 — Choose TWO

A university federates visiting researchers through one OIDC provider in a workforce identity pool. The partner signs reliable research-program attributes for researchers and its wider student population. Another provider in the same pool admits legitimate library users; those users must remain admitted but must receive no role in the research project. Only approved researchers from the first provider may enter that particular integration, and they need project read access rather than organization-wide access. A test currently accepts a correctly signed token from an ordinary student, and reviewers propose granting the entire pool project access after fixing admission. The team wants both provider-level admission restrictions and a resource-level authorization boundary that does not accidentally include the library provider. Which TWO configuration choices implement these requirements? Choose TWO.

**A.** Grant a project role to the entire external IdP merely because its token signatures are valid.

**B.** Grant the required project role to the mapped, approved workforce principal set.

**C.** Add a provider attribute condition that accepts only the approved research-program value.

**D.** Grant the entire workforce pool project read access and rely on issuer signature validation to distinguish the research program.

**Answer: B, C**

Federation admission and resource authorization are separate controls. A provider condition limits accepted identities; a scoped IAM binding grants only the intended resource access.

**Guide mapping:** 1.1; Constrain federated workforce admission and authorization. **Editorial difficulty:** hard.

- **A:** Signature verification alone does not establish membership in the approved program.
- **B:** Correct: the approved set receives only its required project access.
- **C:** Correct: a signed attribute can constrain which IdP identities satisfy the federation trust.
- **D:** A whole-pool grant also authorizes admitted library users from the other provider. Filtering researchers at one provider does not narrow that separate population.

- [Workforce Identity Federation](https://docs.cloud.google.com/iam/docs/workforce-identity-federation) — External workforce identities can authenticate without synchronized Google accounts; attributes determine IAM access.

Sources checked 2026-11-03. Original author ID: `ACCESS-006`.

---

<a id="q015"></a>
### PCSE200-015 — Choose ONE

A regulated application uses a regional internal Application Load Balancer with HTTPS backends on Compute Engine. A transport test confirms that the backend connection is encrypted, but the security standard also requires peer authentication in both directions. The load balancer must verify the backend certificate against the enterprise trust hierarchy. Each backend must also authenticate the client certificate presented by the load balancer before accepting application requests. The application supports mutual TLS and the selected load-balancer architecture supports backend authenticated TLS and backend mTLS. End-user authentication and the frontend listener already meet their separate requirements. The team wants to close the backend identity gap without mistaking an encryption-only setting or a frontend certificate policy for backend authentication. Which change directly meets both remaining requirements? Choose ONE.

**A.** Enable frontend mTLS for end users and leave the backend TLS authentication configuration unchanged.

**B.** Configure backend authenticated TLS with the enterprise trust configuration and backend mTLS with the load balancer's client certificate.

**C.** Keep HTTPS alone because selecting an encrypted backend protocol always validates the enterprise CA and sends a client certificate.

**D.** Configure a stricter frontend SSL policy and assume its certificate-validation rules automatically apply to backend connections.

**Answer: B**

Encryption and peer authentication are distinct. Supported Application Load Balancers can explicitly validate backend identity and present their own client identity using backend mTLS.

**Guide mapping:** 2.1; Authenticate the backend side of a load-balancer TLS connection. **Editorial difficulty:** hard.

- **A:** Frontend client authentication is separate from the load balancer's backend client identity.
- **B:** This configures both requested directions of backend authentication.
- **C:** Plain HTTPS selection does not establish these explicit mutual authentication properties.
- **D:** Frontend TLS settings do not supply the required backend trust configuration.

**Service assumption/limitation:** The scenario uses a supported regional internal Application Load Balancer; support must be checked for other load-balancer types.

- [Backend authenticated TLS and backend mTLS overview](https://docs.cloud.google.com/load-balancing/docs/backend-authenticated-tls-backend-mtls) — Supported Application Load Balancers can validate backend identity with authenticated TLS and present a client certificate with backend mTLS.

Sources checked 2026-11-03. Original author ID: `NETWORK-022`.

---

<a id="q016"></a>
### PCSE200-016 — Choose ONE

A platform team configures two independent OIDC providers in one workload identity pool. Each provider assigns subjects such as build-17 from its own local namespace, and both configurations map google.subject directly from that value. The production builder from provider One has already received a narrow resource grant. Testing now shows that an unrelated builder from provider Two can present its own validly signed token and resolve to the same mapped principal. Both providers are legitimate and must continue to support other approved applications. Their display names are different, and token signature and audience validation are working as configured. The team wants durable identity separation and unambiguous audit attribution, rather than a change that merely makes the configuration look different in the console. What is the best correction? Choose ONE.

**A.** Rely only on different display names for the two provider configuration resources.

**B.** Give both providers the same audience so subjects can be correlated more easily.

**C.** Use collision-resistant subject mappings or separate pools so different external identities cannot map to the same principal.

**D.** Use the same service account key for both builders to avoid subject-mapping complexity.

**Answer: C**

Within one pool, equal mapped subjects identify the same principal. Provider-specific, stable mapping or separate pool boundaries prevent unintended identity equivalence.

**Guide mapping:** 1.2; Prevent subject collisions in a workload pool. **Editorial difficulty:** hard.

- **A:** Display names do not change the mapped principal identifier.
- **B:** Audience standardization does not resolve the subject collision.
- **C:** Correct: the principal identity must remain unambiguous.
- **D:** A shared key removes rather than improves workload attribution.

- [Best practices for using Workload Identity Federation](https://docs.cloud.google.com/iam/docs/best-practices-for-using-workload-identity-federation) — Avoid identity collisions and use unambiguous mappings and trust boundaries.

Sources checked 2026-11-03. Original author ID: `ACCESS-017`.

---

<a id="q017"></a>
### PCSE200-017 — Choose TWO

A single BigQuery sales table serves regional analysts and a central finance group. Analysts need all ordinary sales fields but may see only their own region’s rows, and their tax-identifier values must be masked. Finance must see every region and the raw identifiers. Both audiences already have the basic permissions needed to run approved queries. The selected edition supports the proposed security features, and the row predicates use simple comparisons without subqueries. The business rejects separate physical copies for each audience because corrections arrive throughout the day. It also rejects relying on dashboard authors to remember filters, since analysts can use other query clients. The team therefore needs independent enforcement of the row boundary and the sensitive-column presentation. Which TWO controls implement the design? Choose TWO answers.

**A.** Grant everyone table access and require each dashboard author to include a regional WHERE clause.

**B.** Apply region-specific row access policies and give finance an appropriate all-rows policy.

**C.** Apply column masking policies with masked access for analysts and raw column access only for finance.

**D.** Grant analysts Fine-Grained Reader on tax-identifier policy tags and rely on row policies to mask the column.

**Answer: B, C**

Row policies determine eligible rows; masking controls visible values in a column. With the stated non-subquery predicates these mechanisms can compose.

**Guide mapping:** 3.1; Combine BigQuery row and column restrictions. **Editorial difficulty:** hard.

- **A:** A dashboard convention is bypassed by direct queries.
- **B:** Server-enforced row policies implement regional restrictions independently of query authors.
- **C:** Different column privileges provide masked versus raw views of the same data.
- **D:** Fine-Grained Reader grants raw access rather than masked values.

- [Introduction to BigQuery row-level security](https://docs.cloud.google.com/bigquery/docs/row-level-security-intro) — Row access policies filter table rows for designated principals.
- [Introduction to data masking](https://docs.cloud.google.com/bigquery/docs/column-data-masking-intro) — Masked Reader and Fine-Grained Reader yield different access; masking composes with simple row policies.

Sources checked 2026-11-03. Original author ID: `DATA-007`.

---

<a id="q018"></a>
### PCSE200-018 — Choose TWO

A clinical operations team prepares event records for a scheduling simulation. The analysts need exact intervals between events for each patient, but they do not need true calendar dates or free-text names. Exports arrive weekly and must remain consistent for patients seen in earlier exports. The release process already replaces patient IDs with stable pseudonyms. Which two additional transformations best preserve the required utility while reducing disclosure? Choose TWO answers.

**A.** Bucket each event date independently into a calendar year.

**B.** Replace all event dates with independently generated random dates.

**C.** Redact detected names from narrative fields before release.

**D.** Apply date shifting using the patient context and a persistent protected key.

**Answer: C, D**

Consistent entity-based date shifting retains within-patient intervals across runs. Name redaction removes a separate identifying element without sacrificing interval analysis.

**Guide mapping:** 3.1; Preserve longitudinal utility while removing identifiers. **Editorial difficulty:** hard.

- **A:** Year bucketing discards the precise intervals needed by the simulator.
- **B:** Independent random dates destroy event intervals and ordering.
- **C:** Narrative names are unnecessary to the purpose and can be removed.
- **D:** A stable key and entity context preserve the same patient's temporal relationships.

- [Date shifting](https://docs.cloud.google.com/sensitive-data-protection/docs/concepts-date-shifting) — Entity context and a stable key preserve within-entity intervals across requests.
- [Transformation reference](https://docs.cloud.google.com/sensitive-data-protection/docs/transformations-reference) — Redaction, bucketing and tokenization have different utility and reversibility.

Sources checked 2026-11-03. Original author ID: `DATA-005`.

---

<a id="q019"></a>
### PCSE200-019 — Choose TWO

A service runs on 30 standalone Linux VMs distributed evenly across three zones. Each zone must retain at least eight healthy application instances, and the team wants to finish one zone before advancing. Package installation can succeed while the application fails to restart. The approved patches require reboots, and the maintenance period includes time for recovery checks. All agents and repositories are healthy. The team will treat application health-check failure as a failed patch step and stop for investigation rather than declare the fleet compliant. All 30 instances are healthy before maintenance. The service has no spare per-zone capacity beyond those two instances, and traffic cannot be shifted between zones. Which two settings best implement the rollout requirements? Choose TWO.

**A.** Select zone-by-zone rollout with an absolute disruption budget of two per zone.

**B.** Use post-patch application health checks and a reboot setting that permits the required restart before those checks complete.

**C.** Set reboot behavior to Never so the disruption budget counts only installation and all machines remain available.

**D.** Use concurrent-zone rollout with a disruption budget of two because identical per-zone budgets guarantee sequential zones.

**Answer: A, B**

Sequential zones and a two-VM disruption budget respect the stated capacity limit. Post-patch checks run after required reboot and allow application recovery failure to keep an instance counted as disrupted.

**Guide mapping:** 4.1; Constrain patch disruption and verify application recovery. **Editorial difficulty:** hard.

- **A:** This preserves at least eight available instances per zone during the planned rollout.
- **B:** This makes application recovery part of the patch outcome rather than equating package installation with service health.
- **C:** Avoiding reboot can leave required fixes unapplied and does not demonstrate recovery.
- **D:** Concurrent zones violate the explicit sequential-zone requirement.

- [Create patch jobs](https://docs.cloud.google.com/compute/vm-manager/docs/patch/create-patch-job) — Rollout supports zone-by-zone operation, per-zone disruption budgets, reboot control, and post-patch scripts.

Sources checked 2026-11-03. Original author ID: `OPS-012`.

---

<a id="q020"></a>
### PCSE200-020 — Choose TWO

A platform team needs to prohibit a resource configuration for which no suitable predefined organization constraint exists. The service documentation confirms that the relevant resource field and CREATE method support custom constraints. The team writes a CEL expression, creates the custom-constraint definition, and validates the expression against representative compliant and noncompliant configurations. New test deployments nevertheless remain unaffected because no organization policy references the definition. Production projects share a folder, and several release teams use that folder. Security wants centrally inherited prevention after assessing the operational impact, while application owners require an observation phase before requests can be rejected. Existing resources also need a separate review; the change is not intended to rewrite them. Which TWO steps complete an appropriate staged rollout? Choose TWO.

**A.** Create an organization policy referencing the custom constraint at the intended organization, folder, or project scope.

**B.** Configure only a dry-run policy indefinitely and treat logged violations as proof that noncompliant deployments are being blocked.

**C.** Treat creation of the constraint definition as sufficient enforcement and troubleshoot only the client library cache.

**D.** Evaluate an appropriate dry-run policy and its violations, then enable the live policy after validating the impact.

**Answer: A, D**

A custom constraint defines a restriction but does not enforce it by itself. A policy attaches enforcement to the resource hierarchy; dry-run evidence can support staged rollout.

**Guide mapping:** 1.5; Deploy a supported custom organization constraint safely. **Editorial difficulty:** hard.

- **A:** Correct: the constraint must be referenced by an applicable policy.
- **B:** Dry-run violations are evidence about prospective enforcement; dry run itself does not block the deployments.
- **C:** Definition creation alone does not apply enforcement.
- **D:** Correct: dry run exposes prospective violations without applying the restriction.

**Service assumption/limitation:** Custom resource types, fields and methods are service-specific; unsupported methods must not be assumed.

- [Create custom constraints](https://docs.cloud.google.com/resource-manager/docs/organization-policy/creating-managing-custom-constraints) — Custom constraints specify supported resources, methods, CEL conditions and actions, then require a policy.
- [REST Resource: organizations.customConstraints](https://docs.cloud.google.com/organization-policy/reference/rest/v2/organizations.customConstraints) — Creating a custom constraint does not itself enforce a policy.
- [Test organization policies](https://docs.cloud.google.com/organization-policy/test-policies) — Dry-run policies audit potential custom-constraint violations without enforcing them.

Sources checked 2026-11-03. Original author ID: `ACCESS-045`.

---

<a id="q021"></a>
### PCSE200-021 — Choose ONE

A batch integration in service perimeter Alpha must read one approved dataset in perimeter Beta. Both perimeters must remain separate. The integration service account already has the required IAM permission, but the security design explicitly requires the perimeter exception itself to restrict the identity, destination resources and permitted operations independently of IAM. Broad perimeter connectivity followed only by IAM filtering is unacceptable. Tests confirm that the request needs a permitted path at both boundaries. Other identities and destinations must not gain an equivalent boundary exception merely because they later receive an IAM role. The organization also wants to keep its existing isolation for unrelated workflows, rather than merge the perimeters or introduce a broad trust relationship between them. Which configuration best preserves the required boundaries? Choose ONE.

**A.** Merge Alpha and Beta into one perimeter so all present and future services can communicate without cross-boundary checks.

**B.** Create a perimeter bridge between Alpha and Beta and use IAM alone to enforce the requested method-specific boundary.

**C.** Add scoped egress permission from Alpha and scoped ingress permission to Beta for the integration identity, approved resources and required operations.

**D.** Add every service account to an access level and assume that access level grants all required directions and methods.

**Answer: C**

Paired, narrow ingress and egress rules preserve the separate perimeters and express the approved integration. Broad merging or bridging expands the boundary beyond the stated method-scoped requirement.

**Guide mapping:** 2.2; Limit cross-perimeter integration with scoped exceptions. **Editorial difficulty:** hard.

- **A:** Merging removes the requested perimeter separation.
- **B:** A broad bridge does not provide the requested narrowly scoped service-operation exception.
- **C:** This supplies the specific two-sided exception without opening unrelated access.
- **D:** An access level alone is not a substitute for all required boundary checks.

- [Ingress and egress rules](https://docs.cloud.google.com/vpc-service-controls/docs/ingress-egress-rules) — Rules scope boundary exceptions by identity, source or destination resources and operations.

Sources checked 2026-11-03. Original author ID: `NETWORK-031`.

---

<a id="q022"></a>
### PCSE200-022 — Choose ONE

A Security Command Center threat finding names a VM, a principal, and an unfamiliar caller address. The VM owner says the activity might be a scheduled maintenance task but cannot yet identify the job. The host also shows an unexpected process during the same interval. Operations can preserve the current evidence while validating the activity. The incident queue requires a defensible resolution, not just fewer active findings. What is the best next action? Choose ONE.

**A.** Apply a resource-specific mute rule until the next maintenance window, treating owner uncertainty as sufficient evidence of an approved exception.

**B.** Correlate the finding indicators with audit and host evidence, confirm the owner explanation, and apply containment according to the assessed risk.

**C.** Mark the finding inactive because a resource owner suggested a benign explanation, and investigate only if it recurs.

**D.** Delete the VM immediately and treat the lack of further findings as proof that the maintenance task was legitimate.

**Answer: B**

A tentative explanation does not resolve contradictory evidence. Triage should connect identity, resource, time, and indicators before closing the finding, while containment follows the risk.

**Guide mapping:** 4.2; Triage findings using correlated evidence rather than premature closure. **Editorial difficulty:** medium.

- **A:** A narrow mute can be appropriate for an approved exception, but there is no confirmed benign explanation or accepted risk here.
- **B:** This tests the explanation against evidence and supports a defensible response decision.
- **C:** An unconfirmed explanation is insufficient for a resolved incident state.
- **D:** Deletion destroys useful evidence and cannot establish that the original behavior was benign.

- [Mitigate security incidents](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/security-mitigations) — Incident mitigations depend on severity and certainty and should consider preserving forensic evidence.
- [Review and manage findings](https://docs.cloud.google.com/security-command-center/docs/review-manage-findings) — Findings expose affected resources and related attributes for investigation; INACTIVE represents an addressed issue.

Sources checked 2026-11-03. Original author ID: `OPS-033`.

---

<a id="q023"></a>
### PCSE200-023 — Choose ONE

A stateless application runs in a managed instance group whose instance template references a specific hardened custom image. During an urgent maintenance window, operators patch every current VM manually. The next day, autoscaling creates additional VMs containing the original vulnerable package. The team needs a durable correction that survives recreation, preserves rollback evidence, and limits service disruption while existing instances are updated. They already have a reproducible image-building pipeline and application health checks. New instances must use reviewed packages before receiving traffic; installing fixes after startup would leave an unacceptable exposure window during every scale-out. Which change most directly fixes the lifecycle problem rather than only its current symptoms? Choose ONE.

**A.** Set the group update policy to proactive without changing the template or the underlying image reference.

**B.** Rebuild and validate the hardened image, create a new instance template referencing it, and roll the group to that template with controlled disruption.

**C.** Update the image family pointer while leaving the existing template reference to its specific old image unchanged.

**D.** Patch all present VMs again, then save the package-manager logs as proof that future group members meet the baseline.

**Answer: B**

Replacement VMs derive from the group configuration. A rebuilt image plus a new template makes the fix durable, while a controlled rolling update applies it to current members.

**Guide mapping:** 4.1; Propagate hardened image fixes to replacements and existing instances. **Editorial difficulty:** hard.

- **A:** An updater cannot apply a new image that is absent from the desired template configuration.
- **B:** This updates both the source for new instances and the existing fleet.
- **C:** A specific image reference remains specific even when a family points elsewhere.
- **D:** Instance-local changes are not inherited by newly created group members.

- [Automatically apply VM configuration updates in a MIG](https://docs.cloud.google.com/compute/docs/instance-groups/rolling-out-updates-to-managed-instance-groups) — MIG configuration updates use new instance templates and support controlled rolling replacement.

Sources checked 2026-11-03. Original author ID: `OPS-013`.

---

<a id="q024"></a>
### PCSE200-024 — Choose ONE

A managed custom training job uses a custom runtime service account with narrow permissions on its approved dataset and output bucket. The container image is in an Artifact Registry repository owned by another project. The job fails while pulling the image, before any application code starts or any dataset access occurs. An engineer has repeatedly granted Artifact Registry Reader to the custom runtime account, including at a broader resource scope, without changing the failure. The dataset access design is intentional and should not be broadened as a troubleshooting shortcut. The repository owner can grant a narrowly scoped read role once the correct identity is identified. The team needs to distinguish the platform’s image-retrieval action from credentials used by code after the container starts. Which investigation and fix best targets the missing boundary? Choose ONE answer.

**A.** Copy the remote repository's IAM policy onto the dataset bucket used by the custom runtime identity.

**B.** Give the job submitter repository read access and assume the platform pulls using the submitter's user credentials.

**C.** Grant Artifact Registry Reader on the remote repository to the custom training runtime identity once more at organization scope.

**D.** Identify the platform identity used for image retrieval and grant that identity repository-scoped read access.

**Answer: D**

The custom training service account controls runtime code access but is not configurable as the identity for pulling the container image. Grant access to the actual platform pull identity at the required repository scope.

**Guide mapping:** 3.3; Distinguish container-image pull identity from training runtime identity. **Editorial difficulty:** hard.

- **A:** The image retrieval is authorized at its repository, not the training data bucket.
- **B:** The service's image retrieval identity is distinct from the submitting user.
- **C:** Broader grants to the wrong identity do not fix the pre-runtime pull authorization.
- **D:** This addresses the pre-runtime identity without broadening the training container's authority.

- [Use a custom service account](https://docs.cloud.google.com/gemini-enterprise-agent-platform/machine-learning/general/custom-service-account) — A custom training account governs runtime access; it cannot be selected for Artifact Registry image retrieval, which uses the platform image-pull identity.
- [Create a custom container for training](https://docs.cloud.google.com/vertex-ai/docs/training/create-custom-container) — Customers supply training code and dependencies in their custom container.

Sources checked 2026-11-03. Original author ID: `DATA-042`.

---

<a id="q025"></a>
### PCSE200-025 — Choose ONE

A logging cost review finds that application logs are stored both in each source Default bucket and in a validated central bucket. The team wants to stop the redundant source application copy. Auditors still require the automatically retained Admin Activity and System Event logs at their origins. The central copy is healthy and has independent access and retention controls. Which configuration change meets the request using supported system-sink behavior? Choose ONE.

**A.** Shorten source Default retention to one day while leaving its application-log routing enabled.

**B.** Modify or disable the source Default sink as appropriate while leaving the unmodifiable Required sink in place.

**C.** Keep the source Default sinks unchanged and add the same application-log filter to a second central sink.

**D.** Remove the central application-log route and lengthen source Default retention to preserve evidence during troubleshooting.

**Answer: B**

Default can be modified or disabled; Required cannot be disabled or deleted. The source application copy can therefore be reduced without turning off mandatory audit routing.

**Guide mapping:** 4.2; Adjust system sinks without assuming required logs can be disabled. **Editorial difficulty:** medium.

- **A:** Short retention reduces stored volume but does not meet the requirement to stop the source application copy.
- **B:** This targets the duplicate application copy while preserving protected routing.
- **C:** Another central route does not stop the duplicate source-bucket storage.
- **D:** This removes the required central copy instead of the redundant local copy.

- [Route logs to supported destinations](https://docs.cloud.google.com/logging/docs/export/configure_export_v2) — Default can be disabled but system-created sinks cannot be deleted; Required cannot be disabled.
- [Route log entries](https://docs.cloud.google.com/logging/docs/routing/overview) — Required routes eligible source audit logs and is not modifiable.

Sources checked 2026-11-03. Original author ID: `OPS-027`.

---

<a id="q026"></a>
### PCSE200-026 — Choose TWO

A manufacturer has an offline root CA already trusted by its factory devices. It wants CA Service to perform routine workload-certificate issuance, but the root private key must remain in its existing offline HSM. Root operators may participate in a one-time onboarding ceremony, not every issuance. The company has selected a subordinate CA architecture. Which TWO actions implement the trust relationship and make the managed issuer usable? Choose TWO.

**A.** Upload the signed subordinate certificate and activate it, but leave the subordinate disabled and expect routine issuance to succeed.

**B.** Create the subordinate in CA Service, retrieve its CSR, and have the external root sign it while retaining the root key externally.

**C.** Upload the signed subordinate certificate and issuer chain, activate the subordinate, and enable it for issuance.

**D.** Import the root's private signing key into CA Service so every new workload certificate chains to the existing root.

**Answer: B, C**

External root signing establishes the subordinate's chain without exporting the root key. Activation and enablement then permit routine managed issuance without calling the offline root.

**Guide mapping:** 2.1; Integrate CA Service with an external root. **Editorial difficulty:** hard.

- **A:** The subordinate must also be enabled for issuance; a valid activated certificate alone does not complete the requested managed issuer.
- **B:** This preserves the root trust anchor and its private-key boundary.
- **C:** The signed certificate and chain complete activation; enablement permits issuance.
- **D:** Exporting the root key violates the stated requirement and is unnecessary.

- [Create a subordinate CA from an external CA](https://docs.cloud.google.com/certificate-authority-service/docs/create-sub-ca-from-external-ca) — External signing and activation preserve the existing root; the signed certificate must preserve generated CSR properties.
- [Create a subordinate certificate authority](https://docs.cloud.google.com/certificate-authority-service/docs/create-subordinate-ca) — Subordinates are activated with a signed certificate and enabled before issuance.

Sources checked 2026-11-03. Original author ID: `NETWORK-007`.

---

<a id="q027"></a>
### PCSE200-027 — Choose TWO

Two research organizations want a jointly reviewed container to compute an aggregate over their private datasets. The operator running the compute environment must not gain general-purpose dataset decryption access. Both owners accept Confidential Space and have reviewed the output logic. They want key access restricted to the approved production workload image and environment, with each owner retaining its own resource policy. Which two configuration decisions support this design? Choose TWO answers.

**A.** Grant narrowly scoped resource access to the attested federated workload identity rather than the general operator identity.

**B.** Grant decryption access to any federated workload running the production Confidential Space image, without checking the approved workload image.

**C.** Configure federation conditions that verify the expected Confidential Space production environment and approved container-image digest.

**D.** Trust a container image tag alone because tags cannot refer to changed image contents.

**Answer: A, C**

Attestation-bound federation makes resource access conditional on measured workload properties. The owners still govern the resource policies and must trust the approved code's data handling.

**Guide mapping:** 3.2; Bind confidential resource release to attested workload identity. **Editorial difficulty:** hard.

- **A:** The binding separates workload access from human operator authority.
- **B:** A production environment alone does not restrict access to the jointly reviewed container.
- **C:** Environment and digest checks constrain which workload can receive access.
- **D:** Tags can change; an approved digest identifies the intended artifact.

**Service assumption/limitation:** Attestation does not prove that approved code is free of bugs or that its outputs cannot leak data.

- [Create and grant access to confidential resources](https://docs.cloud.google.com/confidential-computing/confidential-space/docs/create-grant-access-confidential-resources) — Federation policies evaluate attested workload claims before releasing resource access.

Sources checked 2026-11-03. Original author ID: `DATA-035`.

---

<a id="q028"></a>
### PCSE200-028 — Choose ONE

An application tier scales frequently, making manually maintained VM IP allowlists unreliable. All VMs are in one VPC and project, and each tier has a separate service account created in that project. Only a tightly controlled deployment pipeline can attach the application-tier account. Database ingress should follow that approved application identity on TCP/5432 as instances are replaced. Which classic VPC firewall configuration best fits the requirement? Choose ONE.

**A.** Allow TCP/5432 from the complete VPC range because autoscaling prevents stable source identification.

**B.** Use the same network tag on every tier and allow TCP/5432 from any instance with that shared tag.

**C.** Assign reserved internal addresses to each current application VM and manually maintain those source addresses as the fleet scales.

**D.** Use the application-tier source service account and the database-tier target service account in a TCP/5432 ingress rule.

**Answer: D**

Within the stated VPC and project, source and target service-account filtering follows VM tier identity. Controlling who can attach that identity is essential to the boundary.

**Guide mapping:** 2.2; Use managed workload identity for VM-tier firewall targeting. **Editorial difficulty:** medium.

- **A:** A VPC-wide source is broader than the approved tier.
- **B:** A tag shared by every tier does not express application-only access.
- **C:** This remains operationally fragile under the explicitly stated replacement pattern and does not follow the approved identity.
- **D:** This expresses the intended tier-to-tier flow and follows replacement instances.

**Service assumption/limitation:** Classic service-account firewall selectors apply to VM interfaces, not to individual GKE Pod identities.

- [VPC firewall rules](https://docs.cloud.google.com/firewall/docs/firewalls) — VPC firewall decisions depend on rule priority, target and source scope; tracked connections are stateful.

Sources checked 2026-11-03. Original author ID: `NETWORK-028`.

---

<a id="q029"></a>
### PCSE200-029 — Choose ONE

A team trains a customer-service model on tickets after deterministic tokenization of customer IDs. The model is intended for a wider internal audience that cannot access the original tickets. A reviewer claims tokenization alone proves the training set is anonymous and the resulting model safe to release. Tickets still contain rare incident descriptions and free-text contact details. Which next step best addresses the remaining privacy risk before approving broader use? Choose ONE answer.

**A.** Review and transform remaining identifying content, evaluate the proposed use and outputs, and retain access restrictions until the privacy checks pass.

**B.** Reduce output verbosity and remove customer-ID tokens from responses while leaving all narrative training fields unchanged.

**C.** Validate the pseudonym joins and confirm the re-identification key is isolated, then approve release without reviewing narrative fields.

**D.** Encrypt the training export with a new CMEK and treat authorized model-training access as proof of privacy suitability.

**Answer: A**

Tokenizing one identifier does not remove other identifying content or establish safe model behavior. Inspection and transformation of remaining fields plus application-specific evaluation address the actual residual risk.

**Guide mapping:** 3.3; Separate data de-identification from AI release assurance. **Editorial difficulty:** hard.

- **A:** This combines broader data minimization with validation of the intended application.
- **B:** Shorter responses and token suppression do not address the remaining identifying information comprehensively.
- **C:** Those token controls do not address untransformed rare descriptions or contact details.
- **D:** At-rest access control does not determine whether the authorized training content is appropriate for broader model use.

**Service assumption/limitation:** This is a control-selection inference from documented transformation limits and customer application responsibilities, not a claim that any test proves zero memorization risk.

- [Overview of sensitive data discovery](https://docs.cloud.google.com/sensitive-data-protection/docs/data-profiles) — Discovery profiles classify sensitivity and risk; inspect and enforce separately.
- [Pseudonymization](https://docs.cloud.google.com/sensitive-data-protection/docs/pseudonymization) — AES-SIV supports reversible deterministic tokens; FPE preserves alphabet and length; HMAC is not re-identifiable.
- [Agent Platform shared responsibility](https://docs.cloud.google.com/gemini-enterprise-agent-platform/machine-learning/shared-responsibility) — Customers secure applications and access, and select upgraded containers; Google secures the managed platform.

Sources checked 2026-11-03. Original author ID: `DATA-043`.

---

<a id="q030"></a>
### PCSE200-030 — Choose ONE

A research consortium requires that its key-encryption material remain in an approved external key manager and that the consortium be able to withdraw cryptographic access there. The selected Google Cloud datastore and region have been verified to support Cloud EKM through CMEK. The consortium accepts the external service's availability dependency. An architect claims CMEK is unsuitable because all customer-managed key material must be stored by Google. Which design correctly meets the requirements? Choose ONE answer.

**A.** Import the external key into a software-protected Cloud KMS key and call it externally retained.

**B.** Configure an external Cloud KMS key backed by the supported EKM and use it as the datastore's CMEK.

**C.** Use a Cloud HSM key and retain customer control over its IAM and disablement permissions.

**D.** Import the externally generated key into Cloud HSM while retaining the original external copy.

**Answer: B**

CMEK is a customer-control model that can use supported external key protection. EKM references material that remains external, unlike importing a copy into Cloud KMS.

**Guide mapping:** 3.2; Use external keys within supported CMEK integrations. **Editorial difficulty:** hard.

- **A:** Importing places usable material into Google's key-management environment.
- **B:** The verified EKM integration supplies external custody and external authorization control.
- **C:** HSM-backed CMEK gives customer control but does not meet the requirement that material remain external.
- **D:** Retaining an external copy is not the same as ensuring usable material never resides in Google Cloud.

- [Cloud External Key Manager](https://docs.cloud.google.com/kms/docs/ekm) — External key material remains outside Google and can be used with supported CMEK integrations.

Sources checked 2026-11-03. Original author ID: `DATA-020`.

---

<a id="q031"></a>
### PCSE200-031 — Choose ONE

An organization sink filters the required security logs and targets a Pub/Sub topic in a separate integration project. The external SIEM subscriber can pull a manually published test message, but no routed log messages arrive. Sink diagnostics report permission denied for publication. The engineer who created the sink has broad access to the topic, and source logs are visible in Logging. Which permission change directly addresses the failed delivery? Choose ONE.

**A.** Grant Pub/Sub Subscriber to the source workload service accounts that generated the log entries.

**B.** Grant Logs Viewer to the SIEM account on every source project, leaving the sink writer unchanged.

**C.** Grant the sink writer identity Pub/Sub Publisher on the destination topic.

**D.** Grant the sink creator another Pub/Sub role because the creator credentials are used for every routed publish.

**Answer: C**

The sink publishes using its writer identity, not the human creator or original workload identity. The subscriber test verifies a separate part of the delivery path.

**Guide mapping:** 4.2; Repair cross-project SIEM export destination permissions. **Editorial difficulty:** medium.

- **A:** Source workloads do not publish the routed messages to the sink destination.
- **B:** Reading source logs does not repair the sink publication permission.
- **C:** This authorizes the principal performing the denied publication.
- **D:** The creator permissions do not automatically become the sink runtime permissions.

- [Route logs to supported destinations](https://docs.cloud.google.com/logging/docs/export/configure_export_v2) — For Pub/Sub destinations, the sink writer identity needs Pub/Sub Publisher.

Sources checked 2026-11-03. Original author ID: `OPS-025`.

---

<a id="q032"></a>
### PCSE200-032 — Choose ONE

A database support team needs a production administrative role occasionally for incident diagnostics. Permanent elevation is disallowed. Each elevation must include a business justification, approval by a designated independent responder, a maximum one-hour duration, and a record of who had access. The organization wants a managed Google Cloud workflow rather than custom scripts that add and later remove group members. Which design best satisfies the requirements? Choose ONE.

**A.** Create a PAM entitlement with scoped roles, justification and a one-hour duration, but no designated approver.

**B.** Grant each requester Project IAM Admin so they can add and remove their own role during an incident.

**C.** Use a custom script that adds a one-hour role binding after a justification, without an independent approval step.

**D.** Create a Privileged Access Manager entitlement with the eligible team, scoped role, required justification, approval and maximum grant duration.

**Answer: D**

PAM entitlements express eligible requesters, roles, duration, justifications and approval requirements, and PAM revokes the temporary grant when it ends.

**Guide mapping:** 1.4; Configure just-in-time elevation with approval and expiry. **Editorial difficulty:** medium.

- **A:** This supplies temporary access but omits the independent approval required for this routine entitlement.
- **B:** Self-managed grants defeat independent approval and add excessive IAM authority.
- **C:** This lacks the required approval and replaces the requested managed workflow with custom grant administration.
- **D:** Correct: it provides the requested elevation lifecycle.

- [Privileged Access Manager overview](https://docs.cloud.google.com/iam/docs/pam-overview) — Entitlements define eligible requesters, roles, duration, justification and optional approval; grants expire.

Sources checked 2026-11-03. Original author ID: `ACCESS-041`.

---

<a id="q033"></a>
### PCSE200-033 — Choose ONE

A test mistakenly schedules a production Cloud KMS key version for destruction. The configured waiting period has not expired, and the version's state remains DESTROY_SCHEDULED. A dependent recovery workflow needs the historical ciphertext tomorrow. The key was generated by Cloud KMS, not imported, and the team has confirmed that the scheduling was unauthorized. Which recovery sequence preserves the original material and makes it usable again? Choose ONE answer.

**A.** Extend the key rotation period and retry decryption while leaving the version scheduled for destruction.

**B.** Restore the scheduled version to cancel destruction, then enable the restored version before use.

**C.** Restore the scheduled version and immediately retry decryption without changing its resulting state.

**D.** Create and enable a new primary version, then retry the historical ciphertext with its original version scheduled for destruction.

**Answer: B**

Destruction has a recoverable scheduled phase. Restoring cancels pending destruction and returns the version to a disabled state; enabling is then required for cryptographic use.

**Guide mapping:** 3.2; Recover a key version during its destruction waiting period. **Editorial difficulty:** medium.

- **A:** Rotation configuration does not cancel scheduled destruction or make that version usable.
- **B:** This uses the documented restoration window and activation step.
- **C:** Restoration cancels destruction but returns the version disabled; it must also be enabled.
- **D:** New material does not decrypt historical ciphertext protected by the still-unavailable original material.

- [Destroy and restore key versions](https://docs.cloud.google.com/kms/docs/destroy-restore) — Scheduled destruction is recoverable before expiry; disable and dependency review precede destruction.

Sources checked 2026-11-03. Original author ID: `DATA-026`.

---

<a id="q034"></a>
### PCSE200-034 — Choose ONE

A billing team is replacing a nightly export script that runs with its developer's saved user credentials. The script will run unattended on a Google Cloud runtime that supports an attached service account, read one input bucket, and write to one output bucket. Employee departures must not interrupt the job, and the organization prohibits downloaded private keys. Which design best meets the operational and authorization requirements? Choose ONE.

**A.** Attach the project's existing default account and preserve its broad project roles to avoid export failures.

**B.** Create a dedicated service account, grant only the required bucket roles, and use the runtime's attached-identity credentials.

**C.** Create a dedicated user account, exempt it from interactive sign-in controls, and save its refresh token.

**D.** Create a dedicated service account, grant the two bucket roles, and install its downloaded JSON key in the runtime.

**Answer: B**

A workload identity removes dependence on an employee account. An attached service account obtains runtime credentials without a downloaded key; bucket-level grants match the input/output boundary.

**Guide mapping:** 1.2; Create a narrowly authorized workload identity. **Editorial difficulty:** medium.

- **A:** An existing broadly privileged account exceeds the two-bucket requirement.
- **B:** Correct: it combines workload identity, narrow authorization, and keyless runtime authentication.
- **C:** A synthetic employee identity retains user-session lifecycle problems.
- **D:** The identity and scope are appropriate, but the downloaded private key violates the explicit authentication constraint.

- [Service accounts overview](https://docs.cloud.google.com/iam/docs/service-account-overview) — Service accounts represent workloads; recreated accounts have new identities and old bindings do not transfer.
- [Use IAM securely](https://docs.cloud.google.com/iam/docs/using-iam-securely) — Least privilege, separation of duties and group-based grants reduce unnecessary privileges.

Sources checked 2026-11-03. Original author ID: `ACCESS-009`.

---

<a id="q035"></a>
### PCSE200-035 — Choose ONE

Elm Clinical stores case documents in supported services inside its Assured Workloads boundary. To help operators troubleshoot, the provisioning workflow embeds patient names and diagnosis codes in project descriptions, resource names and labels. The service team argues that the payload bucket is regional and encrypted, so the same assurances must cover those identifying strings. The approved privacy design permits opaque case identifiers in operational metadata, with the identifying mapping kept in the protected data store. Existing metadata has already been copied into operational systems, so renaming resources alone cannot be treated as erasing every historical copy. What should the security engineer require? Choose ONE.

**A.** Remove sensitive values from provisioning metadata, use approved opaque identifiers, and assess historical exposure and remediation separately.

**B.** Retain the names and labels, but add a regional resource-location policy to make all metadata inherit the document storage guarantee.

**C.** Move the names and diagnosis codes into custom log-based metric labels, which provide a dedicated protected metadata boundary.

**D.** Enable customer-managed encryption for document objects and consider the metadata issue resolved once a new encryption key is active.

**Answer: A**

Assured Workloads warns against sensitive data in common metadata fields outside its technical control boundary. Protecting document payloads does not resolve that exposure.

**Guide mapping:** 5.1; Keep regulated payloads out of metadata fields outside the technical boundary. **Editorial difficulty:** medium.

- **A:** This follows the approved design and acknowledges the separate historical exposure.
- **B:** A resource-location setting does not extend every payload assurance to metadata.
- **C:** Log-based metric labels are also unsuitable for this sensitive metadata use.
- **D:** Object encryption does not fix sensitive naming.

- [Shared responsibility in Assured Workloads](https://docs.cloud.google.com/assured-workloads/docs/shared-responsibility) — Sensitive data should not be placed in names, IDs, descriptions, labels, or similar fields outside the technical control boundary.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-016`.

---

<a id="q036"></a>
### PCSE200-036 — Choose ONE

A knowledge assistant retrieves vendor documents and calls a search tool before generating answers. Initial user prompts and final outputs pass policy checks, but a retrieved document contains instructions that cause the agent to request a prohibited tool action. The selected Gemini Enterprise Agent Platform managed integration supports Model Armor inspection of intermediate grounding and tool payloads. Which additional control most directly covers the demonstrated entry point while preserving document retrieval? Choose ONE answer.

**A.** Require every retrieved document to come from an approved bucket and treat that source approval as content sanitization.

**B.** Scan retrieved document titles and URLs but omit the returned document bodies and tool payloads.

**C.** Apply the initial-user-prompt template only to the user's original question after retrieval completes.

**D.** Enable the integration's intermediate-content inspection and enforce the relevant templates on grounding and tool responses.

**Answer: D**

Retrieved and tool-supplied content is an additional untrusted input. The documented managed integration can inspect intermediate content, while least-privilege tool authorization remains a separate necessary boundary.

**Guide mapping:** 3.3; Screen retrieved AI context and tool responses. **Editorial difficulty:** hard.

- **A:** An approved storage source can still contain untrusted instructions inside documents.
- **B:** The demonstrated instruction resides in retrieved content, not necessarily its title or URL.
- **C:** Repeating inspection of the original question still excludes the intermediate content.
- **D:** Intermediate inspection covers the path that bypasses initial-prompt screening.

- [Model Armor integrations](https://docs.cloud.google.com/model-armor/integrations) — Managed integrations can inspect intermediate grounding and tool payloads as well as initial and final content.

Sources checked 2026-11-03. Original author ID: `DATA-038`.

---

<a id="q037"></a>
### PCSE200-037 — Choose TWO

Vela Insurance has two approved requirements. Its own production operators must request separately approved, time-limited IAM elevation with a recorded justification. Covered Google support access to Customer Data must use a customer approval workflow and leave provider-access evidence. The organization is eligible for the relevant services, and it accepts their documented exclusions. Which TWO configurations meet these requirements? Choose TWO.

**A.** Create PAM entitlements for operator roles with requester groups, justification, approvers and maximum grant duration.

**B.** Enable Data Access audit logs for customer actions and treat the resulting records as approval of Google support access.

**C.** Enable Access Transparency and enroll the supported services in Access Approval with an appropriate customer approver workflow.

**D.** Create Access Approval approver groups for the company's operators and use those groups to grant temporary production IAM roles.

**Answer: A, C**

PAM governs temporary customer IAM elevation. Access Approval and Access Transparency address covered Google personnel access, with their own scope and exclusions.

**Guide mapping:** 5.1; Map provider access and customer temporary elevation to separate controls. **Editorial difficulty:** medium.

- **A:** The entitlement models the required temporary operator privilege.
- **B:** Recording a customer action does not authorize a provider support action.
- **C:** The combination supplies the provider approval workflow and access evidence.
- **D:** Access Approval is not the customer's temporary IAM grant mechanism.

- [Privileged Access Manager overview](https://docs.cloud.google.com/iam/docs/pam-overview) — Entitlements provide approval-based temporary IAM elevation with a maximum grant duration and auditability.
- [Overview of Access Approval](https://docs.cloud.google.com/assured-workloads/access-approval/docs/overview) — Access Approval governs enrolled supported Google personnel access, complements Access Transparency, and has exclusions and potential outage auto-approvals.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-006`.

---

<a id="q038"></a>
### PCSE200-038 — Choose TWO

Summit Finance is evaluating whether a reporting environment can be excluded from its sensitive processing boundary. The approved scoping method requires evidence that unapproved paths into the sensitive application are blocked, including relevant administrative paths. Teams provide a diagram showing separate projects and a Connectivity Tests configuration result for one denied TCP path. The design also includes a proxy appliance whose runtime rules are not fully represented in the configuration model. There is an approved maintenance window for non-destructive validation, and required reporting traffic must remain functional. Which TWO evidence activities best address the remaining uncertainty before the scope decision? Choose TWO.

**A.** Document permitted and prohibited flows and administrative dependencies, then analyze the actual applicable routes and security controls across those paths.

**B.** Perform authorized runtime validation of representative allowed and forbidden paths, including the proxy's actual behavior, and record model coverage limits.

**C.** Replace runtime validation with a week of traffic logs, treating the absence of observed forbidden traffic as proof that such traffic cannot pass.

**D.** Treat separate project IDs and one denied configuration result as sufficient proof that every relevant path is isolated.

**Answer: A, B**

Configuration analysis is useful evidence, but the stated approval method requires broader path coverage and validation of runtime behavior outside the model.

**Guide mapping:** 5.1; Validate segmentation with configuration and runtime evidence. **Editorial difficulty:** hard.

- **A:** This establishes what is being claimed and checks the actual relevant controls.
- **B:** This addresses the explicitly stated runtime gap without claiming universal tool coverage.
- **C:** Unobserved traffic may simply never have been attempted.
- **D:** One modeled flow does not establish all network or administrative boundaries.

**Service assumption/limitation:** Connectivity Tests performs live data-plane analysis only in supported scenarios; this question does not treat it as a compliance certification.

- [Connectivity Tests overview](https://docs.cloud.google.com/network-intelligence-center/docs/connectivity-tests/concepts/overview) — Configuration analysis models forwarding paths; live data-plane analysis applies only to supported scenarios.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-017`.

---

<a id="q039"></a>
### PCSE200-039 — Choose ONE

A data engineer with legitimate raw access creates a new BigQuery table using CREATE TABLE AS SELECT against a source protected by policy tags. The destination dataset is shared with a larger analytics group. Reviewers assumed the source's policy tags would automatically follow the projected columns, but a test reader can query a sensitive destination field. The engineering job must continue producing transformed tables. What is the most appropriate correction to the publication workflow? Choose ONE answer.

**A.** Restrict the exposure, use restricted staging or a preprotected destination, and validate column protections before publishing to broader readers.

**B.** Grant destination readers source Fine-Grained Reader so both tables use identical permissions.

**C.** Replace CREATE TABLE AS SELECT with a temporary table and grant the larger group access to the source.

**D.** Remove the source policy tags so source and destination access behavior match.

**Answer: A**

Query-generated tables do not automatically inherit source policy tags. Close the existing exposure and design publication so raw data is never populated into an unprotected table visible through the shared dataset. Use restricted staging or a preprotected destination, preserve protections during publication, and verify actual reader access.

**Guide mapping:** 3.1; Preserve BigQuery classification after derived-table creation. **Editorial difficulty:** hard.

- **A:** Dataset-level access is inherited, so withholding a later table grant does not prevent exposure. Stage privately or preprotect the destination and preserve and validate controls through publication.
- **B:** Adding raw source privileges makes the exposure broader.
- **C:** Direct source access changes the sharing contract and grants unnecessary reach.
- **D:** Removing protection increases exposure rather than fixing the derived copy.

- [Restrict access with column-level access control](https://docs.cloud.google.com/bigquery/docs/column-level-security) — Column access requires both data access and appropriate policy-tag access; query destinations do not automatically inherit tags.
- [Manage BigQuery tables and copy protections](https://docs.cloud.google.com/bigquery/docs/managing-tables) — Table copies and destination permissions need explicit review; do not assume every publication/copy path preserves source column controls.

Sources checked 2026-11-03. Original author ID: `DATA-008`.

---

<a id="q040"></a>
### PCSE200-040 — Choose ONE

A deployment engineer has permissions to create a Compute Engine VM and the Service Account User role on its intended runtime service account. VM creation with that identity succeeds. The engineer then tries gcloud with the impersonate-service-account option from a workstation, but token creation is denied. Security approves workstation impersonation of only this one identity and rejects broader project access. What additional grant most directly addresses the failure? Choose ONE.

**A.** Compute Instance Admin on the service account's project.

**B.** Service Account Admin on every service account in the project.

**C.** Service Account User on the entire organization.

**D.** Service Account Token Creator on the intended service account.

**Answer: D**

Attachment uses actAs, while CLI impersonation requires short-lived credential creation permissions. Token Creator on the target account supplies the relevant ability at the narrow scope.

**Guide mapping:** 1.2; Distinguish attachment from token impersonation. **Editorial difficulty:** hard.

- **A:** Instance administration addresses VM resources rather than IAM token minting.
- **B:** Account management is broader and is not the required token-creation grant.
- **C:** More actAs scope does not add token creation.
- **D:** Correct: it authorizes token minting for this account.

- [Roles for service account authentication](https://docs.cloud.google.com/iam/docs/service-account-permissions) — Service Account User permits attachment; Token Creator permits short-lived credentials; ID-token-only creation has a narrower role.

Sources checked 2026-11-03. Original author ID: `ACCESS-010`.

---

<a id="q041"></a>
### PCSE200-041 — Choose TWO

Aster Legal's approved design requires key material to remain with its external key manager while using a supported managed data service's CMEK integration. The security team has confirmed that the selected service and region support Cloud EKM. The records service must recover after a regional application failover, and its recovery test must include cryptographic operations, not merely a healthy HTTP status. The external provider offers separate availability and support arrangements that have not yet been reviewed. Management asks whether Google Cloud's managed-service availability alone closes the key-related recovery requirement. Which TWO actions should the security engineer require before approving the design? Choose TWO.

**A.** Approve the recovery plan using the managed data service's availability objective, leaving external key failures to the provider's internal process.

**B.** Use the supported Cloud EKM integration and document the external key system's custody and access controls.

**C.** Validate external key availability, connectivity, support ownership and cryptographic recovery through the intended failover path.

**D.** Import the external key into a regional Cloud HSM and classify it as externally held because the original copy remains external.

**Answer: B, C**

Cloud EKM preserves the external key arrangement, while the customer must account for the additional availability dependency.

**Guide mapping:** 5.1; Combine external key custody with customer-owned availability planning. **Editorial difficulty:** hard.

- **A:** The managed data service cannot guarantee the external key system's availability.
- **B:** This selects the supported integration consistent with external custody.
- **C:** This tests a dependency that a healthy application endpoint alone can miss.
- **D:** Importing key material into Cloud HSM changes the required custody model.

**Service assumption/limitation:** External-key unavailability consequences differ by integrated service.

- [Cloud External Key Manager](https://docs.cloud.google.com/kms/docs/ekm) — Cloud EKM uses externally held keys with supported CMEK integrations; external key availability and connectivity are required for cryptographic operations.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-013`.

---

<a id="q042"></a>
### PCSE200-042 — Choose ONE

A platform team believes a service account belongs to a retired reporting job. Its last observed activity is old, but a quarterly finance export might still depend on it. The team wants a reversible retirement step and a monitored period that can reveal hidden dependencies before permanent removal. It must avoid creating a new identity or rewriting every existing grant during this evaluation. Which action best fits? Choose ONE.

**A.** Delete one unused key while leaving the attached-runtime authentication paths available.

**B.** Remove all resource-level grants, record them manually, and rebuild the grants if the finance export fails.

**C.** Delete the account and recreate it with the same email if a job fails.

**D.** Disable the account, monitor dependent workloads, and re-enable it if an approved dependency appears.

**Answer: D**

Disabling the account tests whether anything still depends on its identity and supports straightforward re-enablement. Removing only one authentication mechanism would not exercise all dependencies.

**Guide mapping:** 1.2; Retire a service account reversibly. **Editorial difficulty:** medium.

- **A:** Other credentials can remain usable, so this does not establish that the account is unused.
- **B:** This rewrites the permission state the team explicitly wants to preserve during its reversible evaluation.
- **C:** Recreation produces a new identity and is not equivalent to re-enabling.
- **D:** Correct: this is the documented reversible step before deletion.

- [Disable and enable service accounts](https://docs.cloud.google.com/iam/docs/service-accounts-disable-enable) — Disabling stops service-account resource access and is reversible; it can precede deletion.
- [Service accounts overview](https://docs.cloud.google.com/iam/docs/service-account-overview) — Service accounts represent workloads; recreated accounts have new identities and old bindings do not transfer.

Sources checked 2026-11-03. Original author ID: `ACCESS-013`.

---

<a id="q043"></a>
### PCSE200-043 — Choose ONE

A company grants an engineering group a broad read role on its top-level development folder. One newly sensitive project remains beneath that folder, and its owner removes the group from the project's local IAM policy. Group members can still read supported resources in the project. The company wants to preserve development access elsewhere and has not deployed an IAM deny rule. Which redesign best fixes the structural authorization problem? Choose ONE.

**A.** Add the group to the project's local policy with a narrower role and expect it to replace inherited permissions.

**B.** Move the broad group binding from the folder to the organization so the project can set its own restriction.

**C.** Move the sensitive project into an appropriately restricted folder and grant only its required access, after reviewing inherited policies.

**D.** Add an unconditional read-only binding on the sensitive project for the broad group and remove only its local broad role.

**Answer: C**

Removing a local binding cannot remove an ancestor's allow grant. A separate restricted hierarchy boundary can preserve access to ordinary development projects while excluding the sensitive project.

**Guide mapping:** 1.5; Remove inherited access at its granting scope. **Editorial difficulty:** medium.

- **A:** A narrower local allow role does not subtract permissions.
- **B:** A still-higher inherited allow grant preserves or broadens the unwanted access.
- **C:** Correct: this changes the inherited access boundary and retains deliberate grants.
- **D:** The ancestor's broader grant remains independently effective despite the narrower local grant.

- [Using resource hierarchy for access control](https://docs.cloud.google.com/iam/docs/resource-hierarchy-access-control) — Effective IAM allow access combines local and inherited grants.
- [Move a project](https://docs.cloud.google.com/resource-manager/docs/moving-projects-folders) — Moving projects changes inherited policies; evaluate destination and source hierarchy effects.

Sources checked 2026-11-03. Original author ID: `ACCESS-048`.

---

<a id="q044"></a>
### PCSE200-044 — Choose ONE

An investigation asks which service account read confidential objects through authenticated Cloud Storage API requests. The team can find bucket configuration changes in Admin Activity logs but has no object-read records. At the time of the suspected reads, Data Access logging for Cloud Storage was not enabled, and there was no other object-access telemetry. No exemption explains the gap. Which conclusion and forward control are correct? Choose ONE.

**A.** Enable the relevant Data Access read logging for future requests and document that this change cannot recreate the missing historical audit evidence.

**B.** Enabling Data Access now will reconstruct the missing read events from stored object metadata.

**C.** Admin Activity records contain every object read; granting Logs Viewer automatically reveals them.

**D.** Enable only System Event logging because object reads by service accounts are always system-generated administration.

**Answer: A**

Object reads are data-access activity, not bucket configuration administration. Enabling future collection cannot create records for events that were not logged.

**Guide mapping:** 4.2; Select audit categories that capture user-data access. **Editorial difficulty:** medium.

- **A:** This addresses future coverage while stating the historical evidence limit honestly.
- **B:** Enabling a category does not reconstruct unrecorded past API calls.
- **C:** Admin Activity is not a substitute for user-data read logging.
- **D:** A service-account principal does not turn a user-driven data read into a System Event.

- [Cloud Audit Logs overview](https://docs.cloud.google.com/logging/docs/audit) — Admin Activity and Data Access cover different operations; Data Access is disabled by default for most services.
- [Enable Data Access audit logs](https://docs.cloud.google.com/logging/docs/audit/configure-data-access) — Data Access configuration enables read and write categories for supported services.

Sources checked 2026-11-03. Original author ID: `OPS-029`.

---

<a id="q045"></a>
### PCSE200-045 — Choose ONE

A company acquires a subsidiary whose organization is separate from its own. The parent security team sees findings in its existing Security Command Center deployment and assumes that buying Premium for the subsidiary automatically gives the same detector set and organization-wide coverage. A pilot in one subsidiary project shows no expected posture findings. The security lead must sign off coverage for the whole subsidiary, including projects outside the pilot, and the subsidiary is a newly activated organization. Which assessment is required before that sign-off? Choose ONE.

**A.** Treat the Premium purchase as sufficient evidence that every detector in the parent organization is active across the subsidiary.

**B.** Copy the parent findings dashboard filter into the pilot project and treat an empty result as proof that all subsidiary projects are compliant.

**C.** Confirm the subsidiary activation scope, current tier and service availability, enabled sources, prerequisites, and coverage with representative resources in the intended hierarchy.

**D.** Grant the pilot project administrator organization-wide Logs Viewer and assume this expands Security Command Center activation to every project.

**Answer: C**

Tier labels alone do not establish scope or source availability. Current SHA availability differs for new activations; coverage must be verified for the actual organization, services, and resources.

**Guide mapping:** 4.2; Verify SCC service availability and activation scope before claiming coverage. **Editorial difficulty:** hard.

- **A:** Entitlement is not proof of activation scope, prerequisites, or identical source availability.
- **B:** An empty filtered view can reflect missing collection or scope, not compliance.
- **C:** This checks the controls that determine whether the intended environment is actually assessed.
- **D:** Reading logs does not expand an SCC activation or enable detection sources.

**Service assumption/limitation:** This question tests verification of present service availability, not memorization of historical SKU names.

- [Security Command Center service tiers](https://docs.cloud.google.com/security-command-center/docs/service-tiers) — SCC capabilities depend on service tier and activation level.
- [Overview of Security Health Analytics](https://docs.cloud.google.com/security-command-center/docs/concepts-security-health-analytics) — SHA is unavailable for newly activated Premium organizations; current alternatives include Compliance Manager.

Sources checked 2026-11-03. Original author ID: `OPS-032`.

---

<a id="q046"></a>
### PCSE200-046 — Choose ONE

A payments team pushes container images to Artifact Registry and starts deployment immediately after a successful build. Automatic scanning sometimes completes after deployment. Policy permits release only when the exact artifact has a completed scan with no fixable HIGH or CRITICAL vulnerabilities; scan failures must stop promotion. Developers may push candidate images but cannot approve releases. Which pipeline design best closes this timing gap while preserving that separation? Choose ONE.

**A.** Require a Cloud Build provenance signature on the digest and promote as soon as the build reports success.

**B.** Run a severity check against the previous release, then promote the new tag if the dependency lockfile has not changed.

**C.** Wait a fixed two minutes after pushing, then promote if the image has no vulnerability occurrences at that moment.

**D.** Wait for a successful scan of the image digest, evaluate the severity policy, and let a separately controlled approval identity attest only passing digests.

**Answer: D**

The gate must establish scan completion before interpreting the results, bind the decision to the deployed digest, and keep approval authority separate. An empty or stale result is not evidence that the release passed.

**Guide mapping:** 4.1; Gate releases on completed vulnerability results for the deployed artifact. **Editorial difficulty:** hard.

- **A:** Provenance establishes build information, not satisfaction of this vulnerability threshold.
- **B:** A previous release cannot establish the vulnerability state of the current image and base layers.
- **C:** A fixed delay does not prove completion; missing results could incorrectly pass.
- **D:** This couples completed results and policy evaluation to the exact artifact while separating approval.

- [Container scanning overview](https://docs.cloud.google.com/artifact-analysis/docs/container-scanning-overview) — Scanning supplies vulnerability metadata and on-demand scanning can be integrated into CI/CD.
- [Binary Authorization concepts](https://docs.cloud.google.com/binary-authorization/docs/key-concepts) — Attestations sign image digests and policies can require them before deployment.

Sources checked 2026-11-03. Original author ID: `OPS-001`.

---

<a id="q047"></a>
### PCSE200-047 — Choose ONE

A build fleet and a finance fleet share a VPC but use different VM service accounts. Both are configured to send outbound web traffic through Secure Web Proxy, and direct egress is blocked. Builds may contact approved package-repository hostnames; finance may contact a separate banking-hostname list. The lists change frequently, while IP addresses overlap behind content-delivery networks. No full-path inspection is required. Which policy approach best fits these constraints? Choose ONE.

**A.** Apply one shared destination-IP firewall allowlist to both fleets, using addresses returned by DNS for both approved hostname lists.

**B.** Match each source service account with its approved destination-hostname list in the proxy policy, keeping unmatched requests denied.

**C.** Grant each VM service account permission to use all network tags and let applications choose which destination policy applies.

**D.** Give both fleets one egress IP and permit every destination IP ever observed for either hostname list.

**Answer: B**

Source identity and destination-hostname policy express the intended division without maintaining unstable CDN address lists. The explicit proxy path and blocked bypass make this enforceable.

**Guide mapping:** 2.1; Apply workload-specific Secure Web Proxy egress policy. **Editorial difficulty:** medium.

- **A:** That shared IP list loses the required fleet separation and does not track CDN hostname intent reliably.
- **B:** This matches the required source and destination dimensions.
- **C:** Allowing workloads to select their own security classification undermines the boundary.
- **D:** Shared addresses and accumulated CDN IPs do not preserve the intended hostname separation.

- [Security policies](https://docs.cloud.google.com/secure-web-proxy/docs/create-a-policy) — Gateway policies can combine workload source identity and destination hostname or URL constraints.

Sources checked 2026-11-03. Original author ID: `NETWORK-015`.

---

<a id="q048"></a>
### PCSE200-048 — Choose ONE

An investigation team already stores network logs in a Cloud Logging bucket upgraded for analytics. Analysts can run SQL aggregations over those logs, but now need to join destination addresses with an approved asset-owner table in BigQuery. The security owner does not want a second exported copy of all log records. The team must also review any expansion in who can query the data. The ownership table changes daily and is maintained by another team, so copying a static list into the query is insufficient. The existing log bucket remains the authoritative retained copy. Which approach most directly satisfies the new requirement? Choose ONE.

**A.** Grant every analyst Logs Viewer on the source projects; that alone makes the BigQuery asset table joinable in Logging.

**B.** Create a linked BigQuery dataset for the analytics-enabled bucket, authorize the necessary access, and join through BigQuery.

**C.** Create a Logs Explorer saved query containing the asset table name; saved queries can join external BigQuery tables directly.

**D.** Create a second log sink exporting all records to a new BigQuery dataset and remove the existing Logging bucket.

**Answer: B**

A linked BigQuery dataset exposes the analytics-enabled log data for joins without a separate export copy. It expands the security boundary to BigQuery and requires an access review.

**Guide mapping:** 4.2; Choose analytics access that supports joins without duplicating logs. **Editorial difficulty:** hard.

- **A:** Logging permissions alone do not provide BigQuery table access or the linked dataset.
- **B:** This is the supported path for joining log data with other BigQuery datasets.
- **C:** Saved Logging queries do not provide the requested cross-dataset SQL join.
- **D:** This introduces the unwanted duplicate export and unnecessary storage migration.

**Service assumption/limitation:** The exam guide calls this Log Analytics; current documentation uses Observability Analytics.

- [Query and analyze logs with Observability Analytics](https://docs.cloud.google.com/logging/docs/analyze/query-and-view) — Joining logs with other BigQuery datasets requires a linked dataset and expands the data security boundary.

Sources checked 2026-11-03. Original author ID: `OPS-020`.

---

<a id="q049"></a>
### PCSE200-049 — Choose ONE

A platform team associates a global network firewall policy with an existing VPC. It denies egress TCP/8443 to a test destination at priority 50. A classic VPC rule allows the same traffic at priority 1000. The network uses AFTER_CLASSIC_FIREWALL, all hierarchical and system policies delegate, and a newly created connection succeeds. The team wants global policy decisions to precede classic rules while retaining unmatched classic rules. What should it change? Choose ONE.

**A.** Move the deny to a regional network policy because regional policies always override global and classic policies.

**B.** Change the network enforcement order to BEFORE_CLASSIC_FIREWALL and validate new connections against the effective policy chain.

**C.** Change the global deny priority to 1 while keeping the current network enforcement order.

**D.** Add a lower-priority global allow rule so the global policy has an explicit terminal action for both outcomes.

**Answer: B**

The explicitly selected enforcement order makes the classic allow terminal first. Moving network policies before classic rules enables the matching global deny without discarding unrelated classic rules.

**Guide mapping:** 2.1; Account for network firewall policy enforcement order. **Editorial difficulty:** hard.

- **A:** Regional policies do not automatically outrank classic rules.
- **B:** This changes the relevant ordering while preserving classic rules as a later fallback.
- **C:** A smaller priority number does not move a rule across policy layers.
- **D:** An additional allow cannot make the existing global deny run before an earlier classic allow.

**Service assumption/limitation:** The current ordering also includes regional system policies; the scenario explicitly makes those delegate.

- [Evaluation order for firewall policies and rules](https://docs.cloud.google.com/firewall/docs/firewall-policies-rule-eval-order) — Policy layers are evaluated in order; terminal actions stop evaluation, while goto_next delegates.

Sources checked 2026-11-03. Original author ID: `NETWORK-002`.

---

<a id="q050"></a>
### PCSE200-050 — Choose TWO

An older organization contains several default service accounts with project Editor grants. A review confirms that two legacy jobs depend on some of those permissions, while newly created projects should never receive automatic broad grants. The team must reduce risk without breaking the jobs and cannot assume that a new policy repairs old bindings. Which TWO actions form the most appropriate remediation plan? Choose TWO.

**A.** Treat constraint enforcement as retroactive removal of every existing Editor binding.

**B.** Remove every existing Editor grant immediately and restore permissions only when production jobs report failures.

**C.** Enforce the organization constraint that disables automatic IAM grants for default service accounts.

**D.** Review existing jobs, replace broad grants with tested least-privilege permissions, and remove obsolete Editor bindings.

**Answer: C, D**

Preventing automatic grants and remediating existing bindings are different tasks. Existing workloads require reviewed replacements rather than an assumption that a preventive policy rewrites their access.

**Guide mapping:** 1.2; Prevent future default grants and repair existing access. **Editorial difficulty:** hard.

- **A:** The prevention control is not a retroactive IAM cleanup.
- **B:** The organization has confirmed dependencies and requires tested migration rather than avoidable production failures.
- **C:** Correct: it addresses future automatic broad grants.
- **D:** Correct: explicit, validated IAM changes address current overprivilege.

**Service assumption/limitation:** Default enforcement depends on organization creation date and effective policy; inspect actual state.

- [Secure enterprise foundation controls](https://docs.cloud.google.com/docs/security/security-best-practices-catalog/secure-enterprise-foundations) — Disable automatic broad IAM grants for default service accounts.
- [Test role changes with Policy Simulator](https://docs.cloud.google.com/policy-intelligence/docs/simulate-iam-policies) — Simulation evaluates candidate policy changes using historical access information.

Sources checked 2026-11-03. Original author ID: `ACCESS-011`.

---
## Set 2

<a id="q051"></a>
### PCSE200-051 — Choose ONE

A research company already uses application TLS for sensitive requests. Its new transport requirement specifically asks for link-layer protection between its on-premises edge router and Google's peering edge over a supported Dedicated Interconnect circuit. The facility and router support MACsec. The network architect proposes MACsec and asks how to describe it in the control record without overstating its coverage. Which statement is correct? Choose ONE.

**A.** Select MACsec but record its boundary as only the on-premises LAN before the edge router, leaving the Interconnect segment unprotected.

**B.** Treat MACsec as replacing TLS for the entire application path because both technologies use encryption.

**C.** MACsec protects that adjacent-router link; retain TLS or another appropriate control for protection beyond the Google edge.

**D.** MACsec protects the adjacent-router segment and authenticates the ultimate application server, so retain downstream encryption but remove application certificate validation.

**Answer: C**

MACsec is appropriate for the specified link-layer segment. Its protection does not by itself extend through Google's subsequent internal path or replace application authentication.

**Guide mapping:** 2.3; Match MACsec to its actual protection boundary. **Editorial difficulty:** medium.

- **A:** This describes the wrong link; the configured MACsec protects between the on-premises and Google edge routers.
- **B:** The controls protect different boundaries; MACsec does not replace authentication and encryption beyond its link.
- **C:** This accurately states the segment protected and retains controls for the remaining path.
- **D:** MACsec authenticates/protects the link, not the ultimate application peer. Keep appropriate application identity verification beyond that boundary.

- [MACsec for Cloud Interconnect overview](https://docs.cloud.google.com/network-connectivity/docs/interconnect/concepts/macsec-overview) — MACsec protects the link to Google's edge and does not itself encrypt the subsequent path within Google.

Sources checked 2026-11-03. Original author ID: `NETWORK-043`.

---

<a id="q052"></a>
### PCSE200-052 — Choose ONE

An organization uses a list-type organization policy constraint that supports inheritance and merging. Its parent folder explicitly denies a particular allowed-value identifier. A child project sets inheritFromParent to true and lists that same identifier as allowed, expecting the more specific project policy to win. The deployment is rejected. Other permissions and service prerequisites are satisfied. Which explanation best describes the policy result? Choose ONE.

**A.** List constraints ignore inherited rules whenever the child supplies any value.

**B.** The project's broader IAM role should neutralize the deny value once its permission cache refreshes.

**C.** The project allow always overrides the parent denial because project policies are more specific.

**D.** The merged list policy gives the explicit denied value precedence over the matching allowed value.

**Answer: D**

For merged list organization policies, denied values take precedence. The question explicitly states merging is enabled, so the child allow does not erase the inherited denial.

**Guide mapping:** 1.5; Evaluate inherited list-policy conflicts. **Editorial difficulty:** hard.

- **A:** The child explicitly inherits the parent's policy.
- **B:** An IAM allow role does not override effective organization constraints.
- **C:** This would require different inheritance or override behavior, not the stated merged policy.
- **D:** Correct: the matching deny wins during reconciliation.

**Service assumption/limitation:** Do not generalize list-merge rules to managed boolean constraints.

- [Hierarchy evaluation](https://docs.cloud.google.com/organization-policy/hierarchy-evaluation) — List organization policies may merge; deny values win; managed constraints are inherited or overridden, not merged.

Sources checked 2026-11-03. Original author ID: `ACCESS-046`.

---

<a id="q053"></a>
### PCSE200-053 — Choose ONE

A VPC has a working Private Service Connect endpoint for a supported bundle of global Google APIs. VM clients resolve its generated p.googleapis.com name to the intended internal IPv4 address, and requests from those VMs succeed. An on-premises batch server connected through Interconnect is configured to use that same generated endpoint hostname. An erroneous override in its recursive DNS path maps that hostname to public Google addresses. The enterprise router also has no route for the endpoint’s /32. The attachments and application IAM authorization are healthy, and approved private traffic between the data center and VPC already works. Policy prohibits a public API path for this batch workload, so permitting the current public resolution through an internet proxy is not acceptable. Which paired change completes the private client path? Choose ONE.

**A.** Advertise the endpoint's /32 through Interconnect but keep on-premises DNS resolving the API endpoint name to public Google addresses.

**B.** Make on-premises DNS resolve the endpoint name to its internal address and advertise an appropriate route to that address over Interconnect.

**C.** Enable Private Google Access on every VPC subnet; this automatically changes on-premises recursive DNS and endpoint route advertisements.

**D.** Allocate a second public forwarding address for the PSC endpoint and allow it through the on-premises internet proxy.

**Answer: B**

The hybrid client must discover the private endpoint address and route to it. VPC-local automatic DNS registration does not automatically configure the enterprise resolver or router.

**Guide mapping:** 2.3; Enable hybrid clients to resolve and reach a PSC API endpoint. **Editorial difficulty:** hard.

- **A:** The client will still select the wrong destination, so the new private route alone is insufficient.
- **B:** This corrects both observed hybrid-client deficiencies.
- **C:** The subnet feature does not configure external DNS or route advertisement.
- **D:** A public path violates the workload requirement and is not the private endpoint design.

- [Access global Google APIs through endpoints](https://docs.cloud.google.com/vpc/docs/configure-private-service-connect-apis) — Clients must resolve endpoint names to the PSC endpoint address; hybrid clients need additional DNS and routing configuration.
- [About accessing global Google APIs through endpoints](https://docs.cloud.google.com/vpc/docs/about-accessing-google-apis-endpoints) — Global Google API PSC endpoints use a global internal IPv4 address outside subnet ranges and support hybrid access.

Sources checked 2026-11-03. Original author ID: `NETWORK-038`.

---

<a id="q054"></a>
### PCSE200-054 — Choose TWO

An organization has hundreds of projects and an existing supported Security Health Analytics deployment. Security has a custom module that finds noncompliant resources, but a developer can create such a resource and use it before the next finding appears. A new requirement says supported create and update requests that violate the rule must be rejected synchronously. Existing violations must also remain visible until owners remediate them. The relevant resource type, fields, and methods are supported by custom organization constraints. Resource owners may use the console, Terraform, or direct API calls, so a check confined to the approved CI pipeline would leave another creation path open. Which two controls should the team use? Choose TWO.

**A.** Trigger an automatic remediation job from each custom-module finding and remove any violating resource when the job runs.

**B.** Add the rule to the mandatory CI policy check and require a successful check before the standard deployment job runs.

**C.** Keep posture detection for existing resources and track their remediation separately from request-time enforcement.

**D.** Enforce an appropriately tested custom organization constraint for the supported methods at the required hierarchy scope.

**Answer: C, D**

Organization Policy can reject supported requests, whereas posture findings identify state for follow-up. Enforcing a new constraint does not itself repair existing violations.

**Guide mapping:** 4.1; Combine preventive organization policy with retrospective detection. **Editorial difficulty:** hard.

- **A:** Reactive remediation still permits an interval in which a forbidden create or update has succeeded.
- **B:** This is useful for the standard pipeline but does not synchronously reject direct API or console requests.
- **C:** This preserves visibility of pre-existing drift that request enforcement does not repair.
- **D:** This supplies the required API enforcement point.

- [Create custom constraints](https://docs.cloud.google.com/organization-policy/create-custom-constraints) — Custom constraints restrict supported resource types and methods through organization policies.
- [Overview of Security Health Analytics](https://docs.cloud.google.com/security-command-center/docs/concepts-security-health-analytics) — Security Health Analytics detects resource configuration issues and produces findings.

Sources checked 2026-11-03. Original author ID: `OPS-014`.

---

<a id="q055"></a>
### PCSE200-055 — Choose TWO

Tern Utilities must demonstrate authenticated reads of confidential Cloud Storage objects and preserve that evidence for its approved review period. Admin Activity logs are present, but a controlled object-read test produces no Data Access entry. The security engineer has confirmed sufficient log-viewing permissions, no applicable exemption, and no existing Data Access configuration for Cloud Storage. The destination's current retention is shorter than the approved period. Which TWO actions close the identified gaps? Choose TWO.

**A.** Configure and verify routing, retention and appropriately restricted access for the resulting Data Access evidence.

**B.** Enable Access Transparency and use Google personnel access records as the evidence for reads by customer service accounts.

**C.** Enable the applicable Cloud Storage Data Access audit logging and verify representative authenticated reads end to end.

**D.** Increase retention on the Admin Activity archive and repeat the read test without changing the audit configuration.

**Answer: A, C**

The missing read record and inadequate evidence lifetime are separate gaps. Both audit generation and its storage/handling must satisfy the control.

**Guide mapping:** 5.1; Close a data-read evidence gap and preserve the resulting audit records. **Editorial difficulty:** hard.

- **A:** This addresses the independently identified evidence storage requirements.
- **B:** Provider access records are not customer service-account read records.
- **C:** This addresses the missing event category and validates actual coverage.
- **D:** Longer retention cannot preserve a read record that was never generated.

**Service assumption/limitation:** Cloud Audit Logs is service-specific; the stem excludes permission and exemption explanations for the missing read record.

- [Cloud Audit Logs overview](https://docs.cloud.google.com/logging/docs/audit) — Admin Activity and Data Access cover different operations; most Data Access logging must be enabled, with service-specific exceptions.
- [Configure log buckets](https://docs.cloud.google.com/logging/docs/buckets) — Log buckets support configurable retention; extending retention does not recover entries already expired.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-022`.

---

<a id="q056"></a>
### PCSE200-056 — Choose TWO

A research bucket uses fine-grained access. Some approved collaborators can read objects only because of object ACLs, while the bucket IAM policy grants the internal team access. Security wants one IAM-based authorization model and plans to enable uniform bucket-level access. The migration must retain approved collaborator access and stop applications from modifying object ACLs. Which TWO actions are required for a sound migration? Choose TWO.

**A.** Enable uniform bucket-level access after migration validation so ACL operations and ACL authorization no longer govern access.

**B.** Identify ACL-dependent access and create appropriate IAM grants or resource organization before the switch.

**C.** Remove all bucket IAM grants first because uniform access derives permissions only from project roles.

**D.** Keep relying on object ACLs because they continue granting read access after uniform access is enabled.

**Answer: A, B**

Uniform access disables ACL authorization and operations. Required ACL-only access therefore needs an IAM-based replacement before enforcement.

**Guide mapping:** 1.4; Migrate ACL-dependent access to uniform IAM. **Editorial difficulty:** hard.

- **A:** Correct: this establishes the intended unified model.
- **B:** Correct: otherwise legitimate ACL-only collaborators can lose access.
- **C:** Bucket IAM remains meaningful; indiscriminate removal can break access.
- **D:** ACL grants no longer authorize access after enabling uniform access.

**Service assumption/limitation:** IAM cannot reproduce every object-level ACL arrangement with an identical layout; redesign boundaries where needed.

- [Uniform bucket-level access](https://docs.cloud.google.com/storage/docs/uniform-bucket-level-access) — Uniform bucket-level access disables ACL authorization; migration must account for ACL-only access.

Sources checked 2026-11-03. Original author ID: `ACCESS-031`.

---

<a id="q057"></a>
### PCSE200-057 — Choose ONE

Northbank's approved Assured Workloads package supports the core data service used by a new records application. An optional feature reachable through the same enabled API is absent from the package's supported-product list. The feature passes a deployment test, and its compute region matches the approved boundary. The security team requires package support or an explicitly approved exception before regulated data is processed. What should the release engineer do? Choose ONE.

**A.** Block the unsupported feature pending a supported alternative or documented due diligence and an approved exception under the team's process.

**B.** Proceed after adding a location constraint, because regional deployment resolves every unsupported-product control gap.

**C.** Move the feature into a sibling project outside the folder and retain the application's existing compliance designation.

**D.** Proceed because an API permitted within the Assured Workloads folder establishes support for all features exposed by that API.

**Answer: A**

Deployability is not evidence of package coverage. Products can share an API while having different support status.

**Guide mapping:** 5.1; Verify Assured Workloads support at product and control-package granularity. **Editorial difficulty:** hard.

- **A:** This follows the explicit release requirement and the product-level support boundary.
- **B:** Location is only one possible package control.
- **C:** Moving outside the boundary does not remove the regulated processing requirement.
- **D:** A shared API endpoint can expose unsupported products.

- [Supported products by control package](https://docs.cloud.google.com/assured-workloads/docs/supported-products) — Support varies by control package; an accessible API can expose unsupported products.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-005`.

---

<a id="q058"></a>
### PCSE200-058 — Choose ONE

Islet Health is preparing a new production project whose required and default system log buckets must store data in an approved region from the start. Its staging project was created earlier with global system buckets. The team has tested routing ordinary application logs into a regional user-defined bucket, but the auditor's approved requirement also covers the system audit logs retained by the required sink. Production does not yet exist, so there is no migration deadline forcing reuse of staging. A proposal says to clone staging, then edit both system buckets to the approved location. Which provisioning plan best satisfies the requirement? Choose ONE.

**A.** Create a regional bucket and redirect only the default sink, keeping staging's global required bucket as the permanent audit store.

**B.** Set the appropriate organization or folder default log storage location before creating production, then verify its system bucket locations and routing.

**C.** Create an intercepting aggregated sink to the regional bucket and assume the required-origin copies are no longer stored.

**D.** Create production normally, then change the location field on both existing system buckets before the first customer transaction.

**Answer: B**

System bucket location must be planned before creation. Redirecting ordinary logs does not eliminate the required bucket's existing storage location.

**Guide mapping:** 5.1; Plan log residency before creating the regulated project. **Editorial difficulty:** hard.

- **A:** This leaves system audit evidence in the global required bucket.
- **B:** The defaults apply when new system buckets are created, matching the greenfield opportunity.
- **C:** Interception does not remove mandatory required-origin storage.
- **D:** Existing log bucket locations cannot be edited in place.

**Service assumption/limitation:** The cited regionalization procedure does not relocate existing system buckets or historical entries.

- [Regionalize your logs](https://docs.cloud.google.com/logging/docs/regionalized-logs) — Log storage location is a bucket property; defaults can set locations for new system buckets and sinks can route to regional buckets.
- [Route log entries](https://docs.cloud.google.com/logging/docs/routing/overview) — An intercepting aggregated sink still sends entries to the required sink at their origin; the required sink cannot be modified.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-011`.

---

<a id="q059"></a>
### PCSE200-059 — Choose ONE

A Cloud Storage bucket uses a CMEK in a separate security project. A new uploader has the intended bucket permissions but uploads fail with a Cloud KMS permission error. The human key administrators can manage the key, and the key location is already compatible with the bucket. Review shows the bucket project's Cloud Storage service agent has no cryptographic-use permission on the key. Which targeted change is appropriate? Choose ONE answer.

**A.** Grant the uploaders CryptoKey Encrypter/Decrypter on the required key while leaving the service agent unchanged.

**B.** Grant the Cloud Storage service agent CryptoKey Encrypter/Decrypter on the required key.

**C.** Grant the Cloud Storage service agent KMS Viewer on the key so it can discover the primary version.

**D.** Grant the Cloud Storage service agent KMS Admin on the key instead of a cryptographic-use role.

**Answer: B**

CMEK integrations use a service identity for cryptographic operations. Key administration and storage-object permissions do not supply that identity's missing key-use permission.

**Guide mapping:** 3.2; Grant the CMEK integration identity appropriate key use. **Editorial difficulty:** medium.

- **A:** Uploader authorization is not the missing service-agent authorization for the CMEK integration.
- **B:** This grants the integration identity the missing permission at key scope.
- **C:** Metadata visibility does not grant cryptographic use.
- **D:** Key administration and cryptographic use are distinct; the grant does not target the missing use permission.

- [Customer-managed encryption keys](https://docs.cloud.google.com/kms/docs/cmek) — CMEK gives customer key controls and requires service identity cryptographic access.
- [Customer-managed encryption keys in Cloud Storage](https://docs.cloud.google.com/storage/docs/encryption/customer-managed-keys) — Cloud Storage CMEK access and rotation are service-specific; existing objects require rewrite to change protection.

Sources checked 2026-11-03. Original author ID: `DATA-027`.

---

<a id="q060"></a>
### PCSE200-060 — Choose ONE

A supplier receives a time-limited signed URL for a private invoice object. After a public-access audit, an administrator enforces public access prevention on the bucket and expects all external downloads to stop. The supplier can still use the unexpired URL. The security requirement is to stop issuing these delegated links unless a separate approval workflow authorizes them; ordinary authenticated internal reads must continue. Which explanation and remediation direction is correct? Choose ONE answer.

**A.** Uniform bucket-level access is missing; enabling it invalidates every signed URL.

**B.** Change the bucket's default object ACL so only internal users appear in future object permissions.

**C.** Signed URLs are separate delegated access; govern signing capability and the workflow that issues URLs.

**D.** Remove allUsers and allAuthenticatedUsers from bucket policies and assume that also revokes signing authority.

**Answer: C**

Public access prevention does not prevent signed URL access. The signing principal's capabilities and issuance workflow must be controlled; an existing leaked URL also requires a targeted revocation response.

**Guide mapping:** 3.1; Distinguish public prevention from signed URL delegation. **Editorial difficulty:** hard.

- **A:** Signed URLs are not object ACLs and are not universally revoked by uniform access.
- **B:** Default object ACLs do not eliminate the signed URL delegation path for this private object.
- **C:** Controlling delegation addresses the authorized signing path.
- **D:** Removing public principals does not govern an authenticated principal's ability to delegate through signed URLs.

- [Public access prevention](https://docs.cloud.google.com/storage/docs/public-access-prevention) — Public access prevention restricts public principals but does not block signed URLs.

Sources checked 2026-11-03. Original author ID: `DATA-010`.

---

<a id="q061"></a>
### PCSE200-061 — Choose TWO

A media company has hundreds of projects, including newly created sandboxes. Its one-time spreadsheet of enabled APIs is already stale because console workflows can enable additional services. Security needs recurring visibility and a controlled reduction of unnecessary services without breaking approved workloads. An approved service catalog, project ownership records, and permission for automated inventory collection already exist. Which TWO actions form the most appropriate ongoing workflow? Choose TWO.

**A.** Disable every API absent from last month's billing report immediately because no billing guarantees no dependency.

**B.** Regularly enumerate enabled services through Service Usage, compare them with the approved catalog, and route exceptions to accountable owners.

**C.** Review usage and dependencies for unapproved or unused services, disable them through a controlled change, and verify the resulting inventory.

**D.** Treat the list of services enabled by default when a project is created as a complete inventory throughout its lifetime.

**Answer: B, C**

Enabled-service inventory must be refreshed. Ownership and dependency checks turn differences into safe remediation instead of assuming billing data or initial defaults are complete.

**Guide mapping:** 2.1; Continuously inventory enabled APIs and manage exceptions. **Editorial difficulty:** medium.

- **A:** Unbilled services can still be dependencies or operationally necessary.
- **B:** This provides recurring inventory and accountable review.
- **C:** This closes the loop with controlled remediation and verification.
- **D:** Subsequent service enablement makes the initial list insufficient.

- [Service Usage overview](https://docs.cloud.google.com/service-usage/docs/overview) — Service Usage lists and manages enabled APIs; services can be enabled by default or during console workflows.
- [Enable and disable services](https://docs.cloud.google.com/service-usage/docs/enable-disable) — Service disablement should account for dependent services and service-specific consequences.

Sources checked 2026-11-03. Original author ID: `NETWORK-021`.

---

<a id="q062"></a>
### PCSE200-062 — Choose ONE

A security team suspects an application identity has been misused to decrypt records through a specific Cloud KMS version. It has isolated the identity, but also wants to stop new cryptographic operations with that version during investigation. The records may need to be recovered, so destroying material is unacceptable. The application performs KMS operations directly and does not retain unwrapped keys. Which action supplies the required reversible key-level control? Choose ONE answer.

**A.** Create a replacement version and update only the primary pointer before resuming the investigation.

**B.** Disable the affected key version and monitor failures while preserving the ability to re-enable it.

**C.** Rotate the key and leave the suspected version enabled.

**D.** Revoke only the currently known application's decrypt binding and keep the affected version enabled for other identities.

**Answer: B**

Disabling prevents operations using the version and is reversible. Rotation alone does not revoke an old enabled version. The no-key-cache assumption makes the direct KMS effect relevant to the application.

**Guide mapping:** 3.2; Use reversible key disablement with explicit service effects. **Editorial difficulty:** medium.

- **A:** Changing the primary controls new encryption selection, not continued decryption through the old enabled version.
- **B:** This matches a reversible interruption of cryptographic use.
- **C:** An enabled old version can still decrypt its ciphertext after rotation.
- **D:** This may contain a principal but does not satisfy the requested key-level stop for all new use of that version.

**Service assumption/limitation:** Integrated services can have distinct revocation timing and cache behavior; the stem uses direct KMS calls.

- [Enable and disable key versions](https://docs.cloud.google.com/kms/docs/enable-disable) — Disabled key versions cannot be used for cryptographic operations and can be re-enabled.
- [Key rotation](https://docs.cloud.google.com/kms/docs/key-rotation) — Rotation creates versions; it does not automatically re-encrypt data or disable previous versions.

Sources checked 2026-11-03. Original author ID: `DATA-025`.

---

<a id="q063"></a>
### PCSE200-063 — Choose ONE

A partner portal behind a global external Application Load Balancer uses Cloud Armor throttling keyed by client IP. Hundreds of legitimate users share one partner NAT address, so ordinary traffic hits the threshold. Every portal request in the proposed rule's scope carries a stable, opaque per-session cookie. The objective is to reduce shared-IP collateral throttling; the security team explicitly accepts that edge throttling is approximate and is not a tamper-proof account quota. Which adjustment fits? Choose ONE.

**A.** Use the session cookie as the aggregation key for that rule and handle requests without the cookie through a separate rule.

**B.** Use HTTP_PATH as the aggregation key so each user's requests to the same portal path receive separate counters.

**C.** Raise the IP threshold until the busiest partner never triggers it, retaining the same aggregation for all partner users.

**D.** Replace throttling with an IP-keyed rate-based ban so each individual user behind the shared NAT is tracked separately.

**Answer: A**

A cookie key separates stable session values despite a shared IP. The stated scope avoids confusing this mitigation with an authenticated, unforgeable application quota.

**Guide mapping:** 2.1; Choose a Cloud Armor aggregation key for shared-IP clients. **Editorial difficulty:** hard.

- **A:** This separates the sessions and explicitly addresses missing-cookie behavior.
- **B:** Path keys group requests by URL path, not by user session.
- **C:** A higher shared threshold retains collateral aggregation and weakens control for that IP.
- **D:** Changing the action does not change the shared-IP aggregation.

**Service assumption/limitation:** Cloud Armor rate limits are approximate; client-controlled cookies are not reliable identity or billing-quota enforcement.

- [Rate limiting overview](https://docs.cloud.google.com/armor/docs/rate-limiting-overview) — IP aggregates clients behind a shared address; HTTP_COOKIE can separate cookie values and thresholds are approximate.

Sources checked 2026-11-03. Original author ID: `NETWORK-013`.

---

<a id="q064"></a>
### PCSE200-064 — Choose ONE

A security analyst confirms that an attacker downloaded a service account key and used it to obtain access tokens. The exposed key has now been deleted. The service account is dedicated to a batch job whose temporary interruption is approved, and containment must also stop resource access through already-issued tokens. Responders will repair permissions and restart the job later. Which additional action best satisfies the immediate containment requirement? Choose ONE.

**A.** Disable the affected service account and monitor the resulting loss of access.

**B.** Disable new key creation at the project and assume existing tokens are invalidated.

**C.** Revoke the engineers' user sessions and leave the service account enabled after deleting its exposed key.

**D.** Create a replacement key with the same display name and leave the account enabled.

**Answer: A**

Deleting the private key prevents its future use but does not revoke short-lived credentials already minted from it. Disabling the represented service account is the documented containment measure, with the accepted workload interruption.

**Guide mapping:** 1.2; Contain a compromised key and issued credentials. **Editorial difficulty:** hard.

- **A:** Correct: it addresses access through the compromised identity.
- **B:** Preventing new key creation does not revoke credentials already issued.
- **C:** The attacker's already-issued service account credentials do not depend on those engineer user sessions.
- **D:** A replacement key does not revoke existing tokens.

- [Create and delete service account keys](https://docs.cloud.google.com/iam/docs/keys-create-delete) — Deleting a key prevents future use of that key but does not revoke short-lived credentials already issued.
- [Disable and enable service accounts](https://docs.cloud.google.com/iam/docs/service-accounts-disable-enable) — Disabling stops service-account resource access and is reversible; it can precede deletion.

Sources checked 2026-11-03. Original author ID: `ACCESS-012`.

---

<a id="q065"></a>
### PCSE200-065 — Choose ONE

A manufacturer has an approved offline ceremony that generates every production encryption key. Importing that material into Cloud HSM is allowed, but Google-generated replacement versions are not. A draft deployment imports version one and enables ordinary automatic rotation, assuming future versions will rerun the offline ceremony. The team needs a configuration that enforces its provenance rule and a process for future versions. What should it implement? Choose ONE answer.

**A.** Keep the imported first version and enable ordinary automatic rotation for all subsequent versions.

**B.** Use an import-only key and a controlled process to generate, wrap, import, and activate replacement versions.

**C.** Create an ordinary HSM key and restrict version creation to the key administrators while keeping automatic rotation.

**D.** Re-import the same material periodically while treating each operation as new cryptographic key material.

**Answer: B**

Import-only keys prevent accidental generation within KMS and require manual rotation through imported versions. Ordinary automatic rotation generates new material in KMS rather than executing an external ceremony.

**Guide mapping:** 3.2; Keep imported key provenance across rotations. **Editorial difficulty:** hard.

- **A:** The later versions would be generated in KMS, violating the all-versions provenance rule.
- **B:** This enforces imported provenance while allowing genuinely new ceremony-generated versions.
- **C:** Administrative restrictions do not make automatic KMS generation execute the external ceremony.
- **D:** Reusing the same material does not provide a cryptographic replacement key.

- [Import a key version into Cloud KMS](https://docs.cloud.google.com/kms/docs/importing-a-key) — Import-only restricts versions to imported material; automatic rotation otherwise generates material in KMS.

Sources checked 2026-11-03. Original author ID: `DATA-024`.

---

<a id="q066"></a>
### PCSE200-066 — Choose ONE

A legacy test harness accepts exactly sixteen decimal characters in its customer-reference field. The references are synthetic account identifiers, not payment cards, and the harness performs no checksum validation. Test datasets must retain consistent joins, and an isolated support process must be able to re-identify approved values. Changing the harness is outside this migration. Which transformation fits the stated compatibility requirement, after evaluating the security limitations of the input domain? Choose ONE answer.

**A.** Use format-preserving encryption with the decimal alphabet and stable key/context.

**B.** Use HMAC hashing and convert the result to a sixteen-digit decimal suffix.

**C.** Use AES-SIV tokenization and truncate its encoded output to sixteen characters.

**D.** Use character masking with the first four and last four digits retained.

**Answer: A**

FPE preserves length and character set while supporting reversibility. The scenario excludes checksum semantics; preserving numeric format alone does not guarantee arbitrary business validators will accept output.

**Guide mapping:** 3.1; Apply format-preserving encryption only when required. **Editorial difficulty:** hard.

- **A:** FPE meets the fixed-width numeric constraint with configured referential integrity.
- **B:** Truncated HMAC is not reversible and can collide.
- **C:** Truncating ciphertext prevents reliable reversal and can introduce collisions.
- **D:** Masking destroys information and can merge distinct identifiers.

**Service assumption/limitation:** FPE has domain-size and cryptographic limitations; it is not a general preference over AES-SIV.

- [Pseudonymization](https://docs.cloud.google.com/sensitive-data-protection/docs/pseudonymization) — AES-SIV supports reversible deterministic tokens; FPE preserves alphabet and length; HMAC is not re-identifiable.

Sources checked 2026-11-03. Original author ID: `DATA-004`.

---

<a id="q067"></a>
### PCSE200-067 — Choose ONE

Security must retain selected logs for 400 days and query them in Cloud Logging. A central sink already writes the records to a user-defined log bucket in a security project, but its retention is still the default. Source projects use shorter operational retention. No requirement calls for a Cloud Storage archive. The team wants the smallest change that preserves the central evidence independently of source retention. Which action should it take? Choose ONE.

**A.** Change the sink filter to include timestamps from the past 400 days and leave all bucket retention unchanged.

**B.** Increase only each source project bucket retention, leaving the central bucket at its default.

**C.** Set a 400-day retention period on the organization resource itself rather than the destination bucket.

**D.** Configure the central project log bucket retention to 400 days and verify incoming records are retained there.

**Answer: D**

Retention is a bucket property. The central project bucket can retain the routed copy for 400 days regardless of the shorter source-bucket setting.

**Guide mapping:** 4.2; Configure retention where the central evidence is stored. **Editorial difficulty:** medium.

- **A:** A filter selects entries; it does not control how long they survive in storage.
- **B:** This changes the wrong storage copy and requires unnecessary source changes.
- **C:** Custom retention must be set on a supported project bucket, not an abstract organization resource.
- **D:** This changes the storage policy governing the required evidence copy.

- [Configure log buckets](https://docs.cloud.google.com/logging/docs/buckets) — User-defined project log buckets support configurable retention; organization and folder bucket retention cannot be extended.

Sources checked 2026-11-03. Original author ID: `OPS-022`.

---

<a id="q068"></a>
### PCSE200-068 — Choose ONE

A platform team plans to move a production project from a shared-services folder into a regulated folder within the same organization. A monitoring service account currently receives its read role only from the source folder. The project also has directly attached IAM bindings and a project-level organization policy. The team must avoid loss of monitoring while adopting the destination's inherited controls. What is the best pre-move plan? Choose ONE.

**A.** Assume all source-folder IAM roles become permanent project-level roles after the move.

**B.** Move first and copy every old folder grant to the regulated folder if any alert fails.

**C.** Compare source and destination inheritance, preserve required narrow monitoring access, and validate direct and effective policies after the move.

**D.** Delete the project's directly attached policies because they cannot move with the project.

**Answer: C**

Directly attached policies move with the project, but inherited controls change with its parent. The monitoring dependency must therefore be addressed explicitly without copying unrelated source-folder access.

**Guide mapping:** 1.5; Anticipate project-move access changes. **Editorial difficulty:** hard.

- **A:** Inherited roles are not automatically converted into direct grants.
- **B:** Reactive broad copying can undermine the new regulated boundary.
- **C:** Correct: it checks both continuity and the destination's intended controls.
- **D:** Directly attached policies move with the project.

- [Move a project](https://docs.cloud.google.com/resource-manager/docs/moving-projects-folders) — Moving projects changes inherited policies; evaluate destination and source hierarchy effects.

Sources checked 2026-11-03. Original author ID: `ACCESS-047`.

---

<a id="q069"></a>
### PCSE200-069 — Choose ONE

An application outside Google Cloud already receives short-lived OIDC credentials from an enterprise workload identity provider. It must read objects from one Cloud Storage bucket and has no need to administer the bucket or access another application’s data. The bucket uses uniform bucket-level access, and the chosen API and client library have been verified to support direct access by federated workload principals. The company is removing long-lived private keys from this environment. Its identity team can maintain a dedicated federation trust for the application, while the storage owner can grant a bucket role to the resulting principal. An architect proposes introducing a shared service account used by several unrelated integrations. Security prefers the fewest intermediate identities consistent with a separate authorization boundary. Which design is the simplest fit? Choose ONE.

**A.** Require all external workloads to share one impersonated service account with permissions on every application bucket.

**B.** Create a service account key, encrypt it locally, and decrypt it for every object request.

**C.** Create a managed Cloud Identity user for the application and cache a user refresh token.

**D.** Configure Workload Identity Federation and grant the required bucket role directly to the application's federated principal.

**Answer: D**

Direct access is supported under the stated service and library assumptions. Federation plus a bucket-scoped binding avoids both long-lived keys and an unnecessary shared service account. Uniform bucket-level access is an explicit prerequisite in this case.

**Guide mapping:** 1.2; Choose direct federated workload access. **Editorial difficulty:** medium.

- **A:** The shared account adds unnecessary identity and access breadth.
- **B:** Encryption does not remove key lifecycle and exposure risks.
- **C:** A user identity is not required for this non-human workload.
- **D:** Correct: it uses the existing workload credentials and explicit resource authorization.

**Service assumption/limitation:** Some APIs or client capabilities require service account impersonation; direct support is explicitly stipulated.

- [Workload Identity Federation](https://docs.cloud.google.com/iam/docs/workload-identity-federation) — External workload credentials can be exchanged for federated tokens with direct access or service account impersonation.
- [Uniform bucket-level access and federated identities](https://docs.cloud.google.com/storage/docs/uniform-bucket-level-access) — Direct workforce/workload federation access to Storage requires uniform bucket-level access.

Sources checked 2026-11-03. Original author ID: `ACCESS-015`.

---

<a id="q070"></a>
### PCSE200-070 — Choose ONE

Security has a cross-project sink that writes application logs directly into a central Logging bucket. It then adds a Pub/Sub sink in the central project to feed an external SIEM. Logs originating in the central project reach the SIEM, but logs deposited directly in the central bucket by the cross-project sink do not. Both sink filters and writer permissions are correct. The team needs future source logs in both the central bucket and the SIEM without assuming stored bucket contents are re-ingested. The receiving project uses custom sinks for unrelated streams, and those work normally. The observed failure is specific to entries delivered straight into the bucket. Which change correctly repairs the routing design? Choose ONE.

**A.** Route source entries to the central project and configure its sinks for both destinations, or add a source-side sink for Pub/Sub.

**B.** Create a second subscription on the same Pub/Sub topic so it can read directly from the central bucket.

**C.** Increase the central bucket retention so the central-project Pub/Sub sink has more time to discover stored entries.

**D.** Grant the Pub/Sub sink writer Logs Viewer on the bucket so the sink begins polling previously stored records.

**Answer: A**

Only a project destination invokes that project sinks for rerouting. Entries sent directly to a bucket are stored there without being routed again through the bucket project sinks.

**Guide mapping:** 4.2; Distinguish direct-bucket routing from destination-project rerouting. **Editorial difficulty:** hard.

- **A:** Either proposed routing design supplies entries to the necessary sinks at arrival.
- **B:** Subscriptions consume published topic messages, not arbitrary Logging buckets.
- **C:** Retention does not cause a second routing pass.
- **D:** Sinks do not poll stored bucket contents when granted read access.

- [Route log entries](https://docs.cloud.google.com/logging/docs/routing/overview) — A project destination permits rerouting; direct bucket destinations do not invoke destination-project sinks.

Sources checked 2026-11-03. Original author ID: `OPS-035`.

---

<a id="q071"></a>
### PCSE200-071 — Choose ONE

Frost Manufacturing deploys a Compliance Manager framework to its regulated folder in an eligible tier. A detective cloud control flags resources created outside an approved region. The compliance owner assumes this satisfies a requirement to prevent such creations. A release pipeline subsequently creates another disallowed resource, and a finding appears later. That resource type supports the resource-location organization policy constraint. The company must retain visibility into existing violations while rejecting future disallowed creations; it also wants a small pilot before production enforcement because shared deployment modules are used by several business units. Which change best addresses the failed requirement without losing the existing evidence function? Choose ONE.

**A.** Pilot and enforce the applicable organization policy for creation prevention, while retaining detective assessment and remediation tracking for existing violations.

**B.** Keep the detective control and require engineers to acknowledge its findings before the next scheduled release.

**C.** Replace the framework's evidence export with Compliance Reports Manager because provider reports use independently audited controls.

**D.** Shorten the detective scan interval and classify any resource removed before the next scan as compliant.

**Answer: A**

The requirement is prevention, while the deployed control only detects. A supported creation guardrail and a detective control serve complementary purposes.

**Guide mapping:** 5.1; Distinguish detective findings from preventive enforcement. **Editorial difficulty:** hard.

- **A:** This supplies prevention and retains visibility into existing state.
- **B:** Acknowledgement is a workflow response after the preventive requirement has already failed.
- **C:** Provider reports cannot reject customer resource creation.
- **D:** A faster discovery cycle still permits the prohibited creation.

- [Compliance Manager overview](https://docs.cloud.google.com/security-command-center/docs/compliance-manager-overview) — Framework deployments bind controls to customer resource scope; detective controls detect without preventing; audit controls gather evidence in eligible tiers.
- [Restrict resource locations](https://docs.cloud.google.com/organization-policy/restrict-locations) — Location constraints restrict new supported resources, do not relocate existing resources, and are not universal storage or processing commitments.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-009`.

---

<a id="q072"></a>
### PCSE200-072 — Choose ONE

A data team legitimately reads objects from a sensitive Cloud Storage project using a service account. It worries that stolen credentials could copy those objects into an attacker-controlled Cloud Storage project, even when IAM currently permits the reads. The workload already uses private networking, but both source and destination are Google-managed API resources rather than VM addresses. Which additional control best addresses this boundary risk while preserving authorized in-perimeter analysis? Choose ONE.

**A.** Remove every IAM read permission from the service account, including those needed for the approved analysis workflow.

**B.** Use only a private Cloud DNS zone so valid credentials cannot operate on an unauthorized destination project.

**C.** Place the protected projects and supported services in an enforced VPC Service Controls perimeter and restrict approved boundary exceptions.

**D.** Add a VM egress rule allowing TCP/443 to all Google API addresses and treat every bucket reachable there as trusted.

**Answer: C**

A service perimeter can restrict supported managed-service transfers across a resource boundary even when credentials have IAM permissions. It complements the permissions needed for legitimate work.

**Guide mapping:** 2.2; Select VPC Service Controls for managed-service exfiltration boundaries. **Editorial difficulty:** medium.

- **A:** This stops the required workflow instead of preserving approved analysis.
- **B:** DNS selection is not resource-level authorization.
- **C:** This directly addresses the cross-project data boundary.
- **D:** One Google API address range does not identify which project owns a bucket.

- [Overview of VPC Service Controls](https://docs.cloud.google.com/vpc-service-controls/docs/overview) — Service perimeters constrain supported data-service access and cross-perimeter data transfers.

Sources checked 2026-11-03. Original author ID: `NETWORK-029`.

---

<a id="q073"></a>
### PCSE200-073 — Choose TWO

An internal web application lets employees authorize a Google API through the server-side OAuth authorization-code flow. During review, engineers find that the callback accepts a response without comparing the returned state to the initiating browser session. A deployment also changes the callback path from the exact URI registered for the client. The application must preserve user consent and prevent callback confusion. Which TWO changes should be made? Choose TWO.

**A.** Use the browser's referrer header as the only binding between the authorization request and callback.

**B.** Register and send the exact intended redirect URI rather than relying on a broad path wildcard.

**C.** Validate the returned state against an unpredictable value tied to the initiating session.

**D.** Treat a valid Google authorization code as sufficient proof that the callback belongs to the current browser session.

**Answer: B, C**

Exact redirect URI matching protects callback routing; session-bound state validation protects the request-response association. A valid code alone does not replace that association.

**Guide mapping:** 1.3; Implement a secure OAuth authorization-code callback. **Editorial difficulty:** hard.

- **A:** Referrer data is not the prescribed CSRF binding for OAuth callbacks.
- **B:** Correct: the authorization request's redirect URI must match the configured client URI.
- **C:** Correct: state must be checked, not merely sent.
- **D:** A code's validity does not prove that this browser initiated the corresponding request.

- [Using OAuth 2.0 for Web Server Applications](https://developers.google.com/identity/protocols/oauth2/web-server) — OAuth code flow uses exact redirect URIs and state validation; offline access permits refresh tokens.

Sources checked 2026-11-03. Original author ID: `ACCESS-027`.

---

<a id="q074"></a>
### PCSE200-074 — Choose ONE

A finance analyst can run SELECT customer_id, total against an approved BigQuery table, but SELECT customer_id, tax_id fails. The dataset-level Data Viewer role and job-creation permission are present. The tax_id column uses an enforced policy tag; no masking policy is configured. The analyst has now been approved to see the raw tax ID but should not administer tables or policies. Which additional grant most precisely satisfies the approval? Choose ONE answer.

**A.** Grant Data Catalog Fine-Grained Reader on the relevant policy tag or its appropriate parent.

**B.** Grant BigQuery Data Owner on the entire dataset.

**C.** Grant BigQuery Data Viewer directly on the table in addition to the dataset binding.

**D.** Grant BigQuery Masked Reader on the taxonomy without creating a masking policy.

**Answer: A**

Dataset read access and protected-column authorization are separate checks. Fine-Grained Reader on the relevant policy tag supplies raw column access without broad table administration.

**Guide mapping:** 3.1; Diagnose a BigQuery protected-column denial. **Editorial difficulty:** medium.

- **A:** This addresses the failing policy-tag check at the narrow intended scope.
- **B:** Data ownership is excessive for a column-read requirement.
- **C:** An additional table-read binding does not satisfy the independent policy-tag authorization check.
- **D:** The scenario requires raw access and has no masking policy; the missing authorization is raw protected-column access.

- [Restrict access with column-level access control](https://docs.cloud.google.com/bigquery/docs/column-level-security) — Column access requires both data access and appropriate policy-tag access; query destinations do not automatically inherit tags.

Sources checked 2026-11-03. Original author ID: `DATA-018`.

---

<a id="q075"></a>
### PCSE200-075 — Choose TWO

A test-data bucket has Object Versioning and a seven-day soft delete policy. A lifecycle rule deletes live objects older than 30 days, but storage usage does not drop as expected. Investigation finds many noncurrent generations and recently soft-deleted objects. The owner wants an eventual cleanup policy while retaining the stated seven-day accidental-deletion recovery window. Which two changes or expectations should be included in the plan? Choose TWO answers.

**A.** Treat deletion of a live version as immediate permanent deletion of all generations with the same name.

**B.** Expect eligible soft-deleted data to remain during its configured recovery duration rather than promise immediate byte reclamation.

**C.** Disable Object Versioning and assume existing noncurrent generations are automatically removed.

**D.** Add appropriately scoped lifecycle rules for noncurrent generations using age or newer-version conditions.

**Answer: B, D**

Versioning and soft delete extend the data lifecycle beyond disappearance of a live generation. Noncurrent generations need intentional cleanup, and recovery retention delays permanent removal.

**Guide mapping:** 3.2; Account for versions and soft delete in lifecycle cleanup. **Editorial difficulty:** hard.

- **A:** Object generations have distinct lifecycles and are not all removed with the live version.
- **B:** Soft delete preserves recovery for the agreed interval.
- **C:** Turning off versioning affects future behavior; retained noncurrent generations still require cleanup.
- **D:** Explicit noncurrent-generation rules address retained historical versions.

- [Object Lifecycle Management](https://docs.cloud.google.com/storage/docs/lifecycle) — Lifecycle actions are asynchronous and constrained by holds, retention and versioning.
- [Soft delete overview](https://docs.cloud.google.com/storage/docs/soft-delete) — Soft-deleted resources remain recoverable for their retention duration.
- [Object Versioning](https://docs.cloud.google.com/storage/docs/object-versioning) — Disabling Object Versioning does not remove already existing noncurrent object versions.

Sources checked 2026-11-03. Original author ID: `DATA-033`.

---

<a id="q076"></a>
### PCSE200-076 — Choose ONE

A support chatbot invokes the standalone Model Armor API before sending prompts to its model. A test prompt produces a prompt-injection violation in the API response, yet the chatbot continues with the original prompt and displays the resulting answer. This application does not use an inline managed integration. The team requires violations to block processing and does not want to rely on the model obeying another instruction. Which change addresses the observed gap? Choose ONE answer.

**A.** Check only response sanitization and remove input enforcement once output screening is available.

**B.** Branch on sanitization results, block violating requests, and screen responses before releasing them.

**C.** Store sanitization results alongside the prompt and reject only requests whose final model output also contains a violation.

**D.** Increase the screening confidence threshold but continue forwarding every original prompt.

**Answer: B**

Standalone sanitization returns findings for the caller to enforce. The custom application must act on those results; inline managed integration behavior cannot be assumed.

**Guide mapping:** 3.3; Enforce Model Armor screening decisions in a custom application. **Editorial difficulty:** medium.

- **A:** Output screening leaves the specified input-processing requirement unmet.
- **B:** Explicit request and output enforcement closes the application gap.
- **C:** The requirement is to stop violating input before model processing, not only after output exists.
- **D:** Changing the threshold cannot fix application logic that ignores all results.

- [Protect AI applications with Model Armor](https://docs.cloud.google.com/security-command-center/docs/model-armor) — Standalone API callers must enforce sanitization results in application logic.

Sources checked 2026-11-03. Original author ID: `DATA-037`.

---

<a id="q077"></a>
### PCSE200-077 — Choose TWO

Lumen Retail runs Cloud SQL for MySQL in an approved region. Its internal policy now requires both production data and standard backups to remain in that exact region. Inspection finds standard backups in a broader multi-region, including several copies that must remain recoverable for another month. An approved transition plan permits those historical copies only during that month. Which TWO actions are necessary to complete the transition while preserving recovery? Choose TWO.

**A.** Configure an explicit permitted regional location for future standard backups and verify newly created backup locations.

**B.** Enable regional high availability across two zones and treat the standby location as the standard backup location.

**C.** Apply a resource-location organization policy for the approved region and treat existing backups as relocated when the policy takes effect.

**D.** Track historical backups separately, retain them through the approved transition, and verify their permitted disposition before closing the exception.

**Answer: A, D**

The future backup setting and historical backup inventory are separate obligations. Changing the setting does not move old backup copies.

**Guide mapping:** 5.1; Account for standard-backup locality and historical copies. **Editorial difficulty:** hard.

- **A:** This establishes and verifies the required location for new backups.
- **B:** HA addresses zonal availability; it does not replace explicit standard-backup locality.
- **C:** A resource-location policy does not relocate existing backups; the historical copies still need the approved transition handling.
- **D:** This handles existing copies without falsely claiming the configuration change relocated them.

**Service assumption/limitation:** The scenario uses Cloud SQL standard backups, not enhanced backups managed through Backup and DR.

- [Choose your backup option](https://docs.cloud.google.com/sql/docs/mysql/backup-recovery/backup-options) — Standard backup location can be customized; defaults may be multi-regional and changing the setting leaves existing backups in their original location.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-002`.

---

<a id="q078"></a>
### PCSE200-078 — Choose ONE

A document-review application accepts legitimate SQL examples in a query parameter named sample. It shares a Cloud Armor backend security policy with other application paths. During preview, one preconfigured SQL-injection signature matches the sample parameter in legitimate requests. The same signature correctly identifies attacks in a different parameter, and other signatures also detect attacks against the review path. The owner needs the SQL examples to remain usable but will not accept an entire URL bypass or a reduction in protection across the other applications. Backend ingress is already restricted to the supported load-balancer path. The team can replay representative legitimate and malicious requests before enforcement and knows the exact signature and field causing the false positives. Which change provides the narrowest suitable exception? Choose ONE.

**A.** Create a higher-priority allow for the whole review URL so none of its requests reach the SQL-injection rule.

**B.** Add an exclusion for the sample parameter scoped to the identified signature, retest legitimate and malicious requests, then enforce.

**C.** Remove the entire SQL-injection rule set and retain only a source-IP rate limit for the application.

**D.** Lower every WAF rule to its least sensitive configuration, without checking which signature matched the sample parameter.

**Answer: B**

A narrowly targeted field exclusion preserves the remaining signatures and fields. Retesting confirms that the intended exception works without silently allowing the broader attack surface.

**Guide mapping:** 2.1; Tune Cloud Armor without broadly exempting legitimate traffic. **Editorial difficulty:** hard.

- **A:** An early URL allow bypasses more inspection than required.
- **B:** This changes only the known false-positive surface and validates the result.
- **C:** Rate limiting does not replace SQL-injection detection.
- **D:** Broad sensitivity changes affect unrelated detections and may not isolate the false positive.

- [Tune preconfigured WAF rules](https://docs.cloud.google.com/armor/docs/rule-tuning) — Targeted field exclusions and signature tuning reduce false positives without bypassing all WAF checks.
- [Best practices for Cloud Armor](https://docs.cloud.google.com/armor/docs/best-practices) — Validate application traffic and tune false positives in preview before enforcing new WAF rules.

Sources checked 2026-11-03. Original author ID: `NETWORK-012`.

---

<a id="q079"></a>
### PCSE200-079 — Choose ONE

A Cloud Run service revision and a Cloud Run job both use image digest X. Binary Authorization is enabled on each. Security changes the policy so X is no longer permitted. An existing service revision is already serving traffic, and one execution of the job is running. There is no breakglass bypass. The team plans a new job execution but no new service revision. Which outcome should the response plan anticipate? Choose ONE.

**A.** The service is rechecked on each HTTP request, while jobs are checked only when their definitions are updated.

**B.** All three continue until the service or job definition is updated because Cloud Run never checks execution start.

**C.** The existing revision and running execution terminate immediately; the new execution is also denied.

**D.** Existing revision traffic and the running execution are not retroactively stopped; the new job execution is checked against the changed policy.

**Answer: D**

Cloud Run services check Binary Authorization when deploying a new revision; jobs check at each execution. Changing policy does not retroactively stop existing revisions or already-running job executions.

**Guide mapping:** 4.1; Predict Cloud Run service and job policy evaluation times. **Editorial difficulty:** hard.

- **A:** These are not the documented enforcement points for either resource type.
- **B:** A new job execution is evaluated even without a job-definition update.
- **C:** Policy updates are not retroactive termination controls.
- **D:** This applies the distinct service and job enforcement moments correctly.

**Service assumption/limitation:** This item concerns service revisions and job executions, not traffic migration or Preview attestor features.

- [Set up overview for Cloud Run](https://docs.cloud.google.com/binary-authorization/docs/run/overview) — Services validate new revisions; jobs validate each execution; existing revisions and running executions are unaffected retroactively.

Sources checked 2026-11-03. Original author ID: `OPS-008`.

---

<a id="q080"></a>
### PCSE200-080 — Choose ONE

Ridge Payments deploys card-processing VMs in a service project attached to a Shared VPC host project. A central network group can change the host project's firewall rules and routes, but it cannot read the payment database directly. The draft assessment inventory includes the service project and database only. The approved scope must include controls that protect the payment network without automatically including unrelated corporate workloads. Which inventory change is most appropriate? Choose ONE.

**A.** Keep the inventory unchanged and cite the service project's IAM policy as evidence of the complete network boundary.

**B.** Add every workload in the organization because a Shared VPC cannot support different administrative responsibilities.

**C.** Include the relevant host-project network resources, network administrators and change evidence, then document boundaries around unrelated components.

**D.** Add only the network group's user accounts; host-project configuration can stay excluded because the VMs live elsewhere.

**Answer: C**

Network controls reside in the host project and can affect the payment service. Resource placement alone misses that dependency.

**Guide mapping:** 5.1; Include the Shared VPC network control plane in workload scope. **Editorial difficulty:** medium.

- **A:** Service-project IAM does not capture the host's network control plane.
- **B:** Shared VPC does not automatically make every organization workload the same scope.
- **C:** This captures the relevant security dependency while preserving evidence-based boundaries.
- **D:** Identities without the configurations they control produce an incomplete inventory.

- [Shared VPC](https://docs.cloud.google.com/vpc/docs/shared-vpc) — Service-project resources use networks in host projects; network administration is centralized in the host.
- [PCI DSS on Google Cloud](https://cloud.google.com/security/compliance/pci-dss) — Scope includes systems securing and logging the cardholder environment; provider certification does not establish application compliance.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-020`.

---

<a id="q081"></a>
### PCSE200-081 — Choose ONE

A company wants production administrators to reauthenticate more frequently when using the Google Cloud console and gcloud. General employee browsing sessions should remain unchanged, and non-human batch jobs already use service accounts. An administrator proposes changing only the general Google web-session setting. Which control most directly targets the required Cloud user sessions, assuming the organization's edition supports it? Choose ONE.

**A.** Give administrators Cloud IAM roles only during business hours using scheduled time conditions.

**B.** Set the administrators' password-expiration interval to the desired Cloud reauthentication duration.

**C.** Change only the general Google web-session duration and apply it to the entire employee organization.

**D.** Configure Google Cloud session control for the administrators' organizational unit and test console and CLI reauthentication.

**Answer: D**

Google Cloud session control specifically covers Cloud console, gcloud and applications authorized for Cloud scopes. User session management is distinct from service account credential management.

**Guide mapping:** 1.3; Configure Cloud user session reauthentication. **Editorial difficulty:** medium.

- **A:** Time conditions restrict authorization windows, rather than creating the required session reauthentication policy.
- **B:** Password expiration and Cloud user-session reauthentication are different policy controls.
- **C:** This changes the broader sessions the requirement preserves and does not target the specified Cloud controls.
- **D:** Correct: it targets the desired user sessions with the proper administrative scope.

**Service assumption/limitation:** Availability and external-IdP reauthentication behavior require deployment-specific validation.

- [Set session length for Google Cloud services](https://knowledge.workspace.google.com/admin/security/set-session-length-for-google-cloud-services) — Google Cloud session controls govern user access through Cloud console, gcloud and applications using Cloud scopes.

Sources checked 2026-11-03. Original author ID: `ACCESS-024`.

---

<a id="q082"></a>
### PCSE200-082 — Choose ONE

Cloud IDS is receiving mirrored traffic from a production subnet and generating alerts for a suspicious exploit pattern. An application owner asks why the original connections still reach the backend even though the alert severity is critical. Security wants to keep this detection deployment and add an independently tested prevention control where appropriate. No inline prevention device currently handles the affected path. What should the engineer explain and do? Choose ONE.

**A.** Treat Cloud IDS as out-of-band detection and implement appropriate inline or firewall enforcement separately.

**B.** Retain Cloud IDS and widen the mirrored source set to every subnet, treating broader inspection coverage as the prevention change.

**C.** Raise the minimum alert severity to critical and have the application rely on the resulting alerts as proof that exploit traffic was blocked.

**D.** Send critical IDS findings to a ticket queue and close each ticket once the mirrored packet has been processed by the endpoint.

**Answer: A**

Cloud IDS analyzes mirrored copies and is not an inline blocking control. Prevention requires a separate control in the traffic path or a deliberate response action.

**Guide mapping:** 4.2; Distinguish mirrored intrusion detection from inline prevention. **Editorial difficulty:** medium.

- **A:** This preserves detection while adding prevention at a suitable enforcement point.
- **B:** Broader coverage may improve detection but still does not stop original connections.
- **C:** An alert threshold affects which detections are reported, not whether original traffic is prevented.
- **D:** Processing a mirrored copy is not containment or prevention of the original connection.

- [Cloud IDS overview](https://docs.cloud.google.com/intrusion-detection-system/docs/overview) — Cloud IDS receives mirrored traffic for intrusion detection and does not itself prevent attacks.

Sources checked 2026-11-03. Original author ID: `OPS-019`.

---

<a id="q083"></a>
### PCSE200-083 — Choose ONE

A server-side application periodically retrieves an employee's Google data with explicit user authorization. The work must continue while the employee's browser is closed, within the scopes the employee approved. The developer currently stores only the short-lived access token and finds that later jobs fail when it expires. The organization does not permit a broadly delegated service account for this user-driven application. Which design is appropriate? Choose ONE.

**A.** Use the authorization-code flow with offline access, securely retain an issued refresh token, and handle revocation or expiry.

**B.** Keep requesting new access tokens through an interactive consent redirect each time a scheduled job starts.

**C.** Extend the local cache retention of the access token and retry it after the server reports expiry.

**D.** Request an ID token and treat it as a permanent authorization credential for the data API.

**Answer: A**

Offline authorization can issue a refresh token for renewing access tokens without a present browser. It remains scoped delegated authorization and must handle revocation or other refresh-token invalidation.

**Guide mapping:** 1.3; Use OAuth offline access for delegated background work. **Editorial difficulty:** hard.

- **A:** Correct: it supplies the intended background authorization mechanism.
- **B:** This depends on a present user browser and does not meet the unattended requirement.
- **C:** Local retention cannot extend the access token's validity.
- **D:** ID tokens establish identity to an audience and are not perpetual API access credentials.

- [Using OAuth 2.0 for Web Server Applications](https://developers.google.com/identity/protocols/oauth2/web-server) — OAuth code flow uses exact redirect URIs and state validation; offline access permits refresh tokens.

Sources checked 2026-11-03. Original author ID: `ACCESS-029`.

---

<a id="q084"></a>
### PCSE200-084 — Choose ONE

A supported legacy appliance cannot use federation or attached runtime credentials and currently requires a user-managed service account key. A risk exception allows this temporarily. Its operators can deploy a replacement key without an outage, and monitoring can distinguish use of the old and new key IDs. The team wants to retire the old credential without unexpectedly breaking the appliance. Which sequence is most appropriate? Choose ONE.

**A.** Keep both keys indefinitely because simultaneous keys guarantee availability.

**B.** Create a replacement key, deploy and verify it, then disable and remove the old key after confirming migration.

**C.** Generate and install a new key, immediately delete the old one, and postpone checking which key the appliance uses.

**D.** Delete the only working key first, then ask operations to generate a replacement during the next maintenance window.

**Answer: B**

Rotation must replace the credential actually used by the appliance. Verification before retiring the previous key limits outage risk; leaving both indefinitely retains the old exposure.

**Guide mapping:** 1.2; Rotate a necessary legacy key with verification. **Editorial difficulty:** medium.

- **A:** Permanent overlap fails to retire the old credential.
- **B:** Correct: it validates adoption before retiring the old credential.
- **C:** Skipping adoption verification creates avoidable failure risk in the stated rotation workflow.
- **D:** This introduces a known avoidable outage.

**Service assumption/limitation:** This is an explicit legacy exception, not a recommendation to create keys for workloads that support safer alternatives.

- [Best practices for managing service account keys](https://docs.cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys) — Restrict key creation and upload, rotate necessary keys, and disable detected exposed keys.

Sources checked 2026-11-03. Original author ID: `ACCESS-021`.

---

<a id="q085"></a>
### PCSE200-085 — Choose ONE

A regional museum stores digitized public exhibits in Cloud Storage. Its approved security standard requires encryption at rest but explicitly permits Google to manage keys. There is no external key-custody requirement, customer-controlled revocation requirement, or mandated hardware protection level. The small operations team wants to avoid new key-availability dependencies and manual key administration. Which encryption choice most directly meets these stated requirements while keeping the operational burden proportionate? Choose ONE answer.

**A.** Use CSEK with centrally operated application key distribution and recovery.

**B.** Use externally managed CMEK through a supported highly available EKM partner.

**C.** Build client-side envelope encryption and operate a custom key-recovery service.

**D.** Use Google-managed default encryption for the stored objects.

**Answer: D**

Google Cloud's default encryption protects stored customer content without requiring the customer to administer encryption keys. Additional key-control mechanisms should follow an actual control requirement.

**Guide mapping:** 3.2; Choose default encryption when customer key control is unnecessary. **Editorial difficulty:** medium.

- **A:** This introduces customer key delivery and recovery duties without a requirement for customer-supplied keys.
- **B:** This can add customer key control, but also adds an external availability dependency and administration that the stated requirements do not need.
- **C:** Client-side encryption adds engineering and custody obligations without a stated benefit here.
- **D:** Default encryption satisfies the stated standard with minimal customer key operations.

- [Envelope encryption](https://docs.cloud.google.com/kms/docs/envelope-encryption) — Local DEKs encrypt bulk data; KMS KEKs wrap DEKs and never leave KMS.
- [Customer-managed encryption keys](https://docs.cloud.google.com/kms/docs/cmek) — CMEK gives customer key controls and requires service identity cryptographic access.

Sources checked 2026-11-03. Original author ID: `DATA-019`.

---

<a id="q086"></a>
### PCSE200-086 — Choose ONE

A disaster-recovery exercise will redeploy a container image last pulled 70 days ago. The image digest is unchanged and its original scan passed the release policy. The release manager wants a decision based on current vulnerability intelligence before traffic is restored. Automatic Artifact Analysis scanning is enabled, but the image has not been pulled since that earlier release. Which action best establishes the required evidence? Choose ONE.

**A.** Change the image tag and assume the existing scan timestamp is refreshed immediately.

**B.** Pull the image to trigger refreshed analysis and wait for updated results before evaluating the rollback gate.

**C.** Reuse the original report because digest immutability makes the vulnerability assessment immutable as well.

**D.** Check that the repository still has scanning enabled and approve without checking the report freshness.

**Answer: B**

Immutable bytes can acquire newly disclosed vulnerabilities. Automatic analysis stops updating images that have not been pulled within 30 days; pulling can refresh stale metadata, and refresh is not instantaneous.

**Guide mapping:** 4.1; Recognize stale vulnerability metadata during rollback approval. **Editorial difficulty:** hard.

- **A:** Retagging does not establish that a fresh assessment completed.
- **B:** Pulling and verifying updated results addresses the documented stale-metadata behavior.
- **C:** Digest integrity does not freeze external vulnerability knowledge.
- **D:** Repository configuration alone does not prove this old image has current results.

- [Container scanning overview](https://docs.cloud.google.com/artifact-analysis/docs/container-scanning-overview) — Images not pulled for 30 days have stale metadata; pulling refreshes it and can take up to 24 hours.

Sources checked 2026-11-03. Original author ID: `OPS-002`.

---

<a id="q087"></a>
### PCSE200-087 — Choose ONE

A payment platform separates release engineers from the security team that approves production permissions. Release engineers must update an existing application using its approved runtime identity, but they must not change IAM policies, mint credentials for more privileged service accounts, or replace that identity with a broader one. A proposed role bundle includes both deployment permissions and unrestricted service account administration. Which review outcome best preserves the intended separation? Choose ONE.

**A.** Limit actAs to the approved account but let release engineers edit that account’s IAM policy.

**B.** Approve the bundle because application deployment and IAM policy administration are both operational tasks.

**C.** Restrict deployment and actAs permissions to the approved runtime identity, and reserve IAM administration and other impersonation grants for the security team.

**D.** Grant narrow deployment permissions but allow actAs on every service account in the project.

**Answer: C**

Separation of duties must be enforced by permissions. Deployment access can imply use of the runtime account, so both deployment scope and the allowed identity need deliberate limits.

**Guide mapping:** 1.4; Separate privilege administration from workload operation. **Editorial difficulty:** hard.

- **A:** IAM policy administration leaves an impersonation/escalation boundary under release-engineer control, contrary to the stated separation.
- **B:** Combining authority defeats the stated approval boundary.
- **C:** Correct: it separates permission administration while constraining the identity available during deployment.
- **D:** Project-wide actAs leaves the rejected path to substitute a more privileged runtime identity.

**Service assumption/limitation:** The exact deployment role depends on the runtime; inspect permissions and service-specific identity attachment behavior.

- [Use IAM securely](https://docs.cloud.google.com/iam/docs/using-iam-securely) — Least privilege, separation of duties and group-based grants reduce unnecessary privileges.
- [Roles for service account authentication](https://docs.cloud.google.com/iam/docs/service-account-permissions) — Service Account User permits attachment; Token Creator permits short-lived credentials; ID-token-only creation has a narrower role.

Sources checked 2026-11-03. Original author ID: `ACCESS-030`.

---

<a id="q088"></a>
### PCSE200-088 — Choose ONE

A business configures managed-user SAML SSO and sees successful IdP authentication for an acquired team's employees. Those employees still cannot enter Google services because their managed Google accounts have not been provisioned. The business requires Workspace mailboxes, and the new identities will remain managed by its central HR-driven directory process. Which change addresses the missing dependency without changing the authentication design? Choose ONE.

**A.** Provision the managed users through the authorized directory lifecycle integration, then verify that SAML NameID matches the accounts.

**B.** Create temporary accounts whose primary addresses differ from the SAML subjects and defer reconciling the identifiers.

**C.** Add incoming workers as group members or aliases without provisioning their required managed user accounts.

**D.** Use Workforce Identity Federation for Cloud access and leave the managed account provisioning backlog unresolved.

**Answer: A**

SAML sign-in does not replace the required managed-user provisioning process. The provisioned account and SAML subject must refer to the same user.

**Guide mapping:** 1.1; Separate directory provisioning from SAML claims. **Editorial difficulty:** hard.

- **A:** Correct: this supplies the missing directory identity while retaining SSO.
- **B:** Provisioned accounts must match the SAML subject; mismatched temporary accounts do not complete the existing authentication design.
- **C:** A membership or alias alone does not supply the required managed identity and mailbox.
- **D:** That can address supported Cloud access but does not create the required managed Workspace identities.

- [Manage user accounts](https://developers.google.com/workspace/admin/directory/v1/guides/manage-users) — The Directory API creates, updates, suspends and deletes managed users.
- [Troubleshoot single sign-on (SSO)](https://knowledge.workspace.google.com/admin/support/troubleshooting/troubleshoot-single-sign-on-sso) — Certificate mismatch, incorrect NameID and incorrect recipient information can cause SAML sign-in failures.

Sources checked 2026-11-03. Original author ID: `ACCESS-008`.

---

<a id="q089"></a>
### PCSE200-089 — Choose TWO

An engineering VPC has no earlier terminal policy decisions. Its security team adds a classic egress deny rule for TCP/443 to a specific external address, using the same priority as an existing matching allow. New connections fail, but a long-lived connection established before the change continues carrying data. The team must explain both observations before deciding how to terminate the application session. Which TWO statements are correct? Choose TWO.

**A.** A matching classic deny takes precedence over a matching classic allow at the same priority.

**B.** An equal-priority classic allow takes precedence if it existed before the deny rule.

**C.** Adding the deny invalidates every established connection immediately, so the continuing session proves target mismatch.

**D.** Connection tracking can preserve an existing allowed session; a new deny is not a reliable session-termination mechanism.

**Answer: A, D**

The tie is resolved in favor of deny for new connections. Existing tracked connections can survive rule changes, so their continuation does not contradict the new-connection result.

**Guide mapping:** 2.1; Analyze equal-priority classic rules and stateful connections. **Editorial difficulty:** hard.

- **A:** Deny wins the equal-priority conflict.
- **B:** Creation time is not the tie-breaker.
- **C:** Firewall rule changes should not be treated as instantaneous termination of all tracked sessions.
- **D:** Existing connection state explains the observed difference.

- [VPC firewall rules](https://docs.cloud.google.com/firewall/docs/firewalls) — VPC firewall decisions depend on rule priority, target and source scope; tracked connections are stateful.

Sources checked 2026-11-03. Original author ID: `NETWORK-004`.

---

<a id="q090"></a>
### PCSE200-090 — Choose ONE

A company migrates a public application domain to Cloud DNS. DNSSEC is enabled on the managed public zone and records have signatures, but an external validating resolver reports the delegation as insecure. The parent zone currently contains no DS record for the domain, and ordinary DNS resolution works. The team wants authenticated DNS responses without changing application certificates or making the zone private. What should it do next? Choose ONE.

**A.** Publish a DNSKEY record in the child public zone and assume the parent delegation is authenticated without any DS update.

**B.** Publish the DS record only inside the application's child zone and leave the parent zone and registrar delegation unchanged.

**C.** Publish the correct Cloud DNS DNSSEC DS information through the registrar into the parent zone, then verify propagation and validation.

**D.** Enable DNSSEC only on a new private zone with the same name and leave the public delegation unchanged.

**Answer: C**

Signed zone data alone is insufficient for a validated delegation chain. The parent DS record links the child's DNSSEC key material to the parent trust chain.

**Guide mapping:** 2.1; Complete DNSSEC public-zone chain of trust. **Editorial difficulty:** medium.

- **A:** Child key publication does not replace the missing parent DS trust link.
- **B:** The parent must publish the DS record; a record only in the child cannot establish the missing delegation trust.
- **C:** This establishes the missing parent-child trust link.
- **D:** Private-zone configuration does not repair the public delegation.

- [Activate DNSSEC](https://docs.cloud.google.com/dns/docs/registrars) — Public-zone DNSSEC needs a correct parent DS record to establish the validation chain.

Sources checked 2026-11-03. Original author ID: `NETWORK-017`.

---

<a id="q091"></a>
### PCSE200-091 — Choose ONE

A folder-level intercepting sink sends all selected logs to a central Google Cloud project, rather than directly to a bucket. Its permissions and filters are correct. Application logs are stored centrally, but Admin Activity logs from child projects appear only in their original projects Required buckets. The central project still has only its unmodified system sinks. The security team needs a central Admin Activity copy without losing the mandatory original copies. The source entries have fresh timestamps, and synthetic tests confirm they match the folder sink. Changing the source audit configuration would therefore not explain the observed split. Which change should it make? Choose ONE.

**A.** Change the central project IAM policy to grant Logs Viewer to every source project owner.

**B.** Disable the source Required sinks so the central Required sink becomes the sole eligible destination.

**C.** Wait for the intercepting sink to delete the original copies, after which the central Required sink will accept them.

**D.** Create a central-project sink that explicitly matches the incoming Admin Activity logs and writes them to the intended central bucket.

**Answer: D**

A destination project reroutes entries through its sinks. Its Required sink only accepts eligible logs originating there, so foreign Admin Activity logs need explicit central routing. Source Required copies persist.

**Guide mapping:** 4.2; Route intercepted audit logs through destination-project sinks. **Editorial difficulty:** hard.

- **A:** Reader permissions do not affect routing into storage.
- **B:** Required sinks cannot be disabled and origin copies are expected.
- **C:** Interception does not delete required-origin copies or change entry origin.
- **D:** This adds the missing destination-project routing rule for foreign audit entries.

- [Route log entries](https://docs.cloud.google.com/logging/docs/routing/overview) — Destination-project system sinks exclude source Required logs; explicit routing can store them centrally and source Required copies remain.

Sources checked 2026-11-03. Original author ID: `OPS-026`.

---

<a id="q092"></a>
### PCSE200-092 — Choose ONE

A supported Security Health Analytics detector reports a vulnerable configuration in a legacy project. The risk owner grants a 14-day exception while the application is migrated. An engineer changes the finding to INACTIVE to clear the dashboard, but the resource has not changed and the detector later reports it again. Security needs the exception to remain reviewable without representing the issue as fixed. Which treatment best reflects the actual state? Choose ONE.

**A.** Delete the affected resource from the inventory and retain the INACTIVE finding as the remediation record.

**B.** Repeatedly set the finding to INACTIVE after every scan, treating the exception as permanent remediation.

**C.** Disable that detector for the organization until the migration completes in the legacy project.

**D.** Keep the issue active, record the exception and expiry in the response process, and use narrowly scoped muting where appropriate.

**Answer: D**

Finding state describes whether the issue persists. Muting manages presentation and noise; it does not repair configuration. The exception process must retain its owner and deadline.

**Guide mapping:** 4.1; Separate remediation from accepted-risk presentation in posture management. **Editorial difficulty:** medium.

- **A:** Removing visibility does not change the underlying security condition.
- **B:** Rewriting state without fixing the resource misstates remediation and fights the detector.
- **C:** Organization-wide detector disablement hides unrelated violations.
- **D:** This distinguishes an accepted temporary risk from a resolved issue.

- [Review and manage findings](https://docs.cloud.google.com/security-command-center/docs/review-manage-findings) — ACTIVE denotes an ongoing issue; INACTIVE denotes addressed issues; muted findings remain queryable.

Sources checked 2026-11-03. Original author ID: `OPS-016`.

---

<a id="q093"></a>
### PCSE200-093 — Choose ONE

A central networking team manages a Shared VPC host project. An application team has a service project and must create VMs only in the host's application subnet, while the network team retains control of routing and firewall policies. The application team already has the required Compute Engine permissions in its own project. The host also contains sensitive administration subnets that the team must not consume. Which additional grant is most appropriate? Choose ONE.

**A.** Grant Compute Network Admin on the host project so the team can select the required subnet and manage its own routes.

**B.** Grant Compute Network User on only the application subnet, keeping host networking administration with the central team.

**C.** Grant Compute Network User on the entire host project and rely on subnet naming conventions to prevent use of administration subnets.

**D.** Grant Compute Network User only on the service project because its VM permissions automatically authorize every shared host subnet.

**Answer: B**

Subnet-scoped Network User authorizes consumption of the intended shared subnet without giving network administration or access to every subnet in the host.

**Guide mapping:** 2.2; Delegate Shared VPC consumption at subnet scope. **Editorial difficulty:** medium.

- **A:** Network administration exceeds the required consumption permission.
- **B:** This preserves centralized control and limits which subnet the team may use.
- **C:** A project-wide grant is broader than the stated boundary.
- **D:** The service-project grant does not itself authorize use of the host's shared subnet.

- [Shared VPC](https://docs.cloud.google.com/vpc/docs/shared-vpc) — Host projects centralize networking; compute.networkUser can be scoped to individual shared subnets.

Sources checked 2026-11-03. Original author ID: `NETWORK-023`.

---

<a id="q094"></a>
### PCSE200-094 — Choose ONE

A vendor delivers one container tag whose manifest list references both Linux amd64 and arm64 images. Production includes both architectures, and policy requires each executable image to pass vulnerability review. The automated Artifact Analysis result for the manifest list is clean, but it identifies the amd64 image. The vendor proposes approving the entire list with that report. Which additional action is required before granting approval? Choose ONE.

**A.** Approve the list because the shared tag guarantees identical operating-system packages on every platform.

**B.** Approve both images after validating the manifest-list digest; cryptographic integrity makes another package assessment unnecessary.

**C.** Scan and evaluate each platform-specific image that will run, including the arm64 image, and bind approvals to the reviewed artifacts.

**D.** Remove the architecture field from the review record so the approval applies uniformly to both node pools.

**Answer: C**

Artifact Analysis selects an image from a manifest list, preferring Linux amd64 when present. A clean selected-image report is not evidence that every platform image meets policy.

**Guide mapping:** 4.1; Avoid treating a manifest-list scan as full platform coverage. **Editorial difficulty:** hard.

- **A:** A tag may reference different platform builds and dependencies.
- **B:** A digest verifies identity, not vulnerability equivalence between distinct child images.
- **C:** Separate assessment closes the explicit per-executable coverage requirement.
- **D:** Changing the evidence record cannot expand what was scanned.

- [Container scanning overview](https://docs.cloud.google.com/artifact-analysis/docs/container-scanning-overview) — For manifest lists, Artifact Analysis scans Linux amd64 if present or selects another image otherwise.

Sources checked 2026-11-03. Original author ID: `OPS-003`.

---

<a id="q095"></a>
### PCSE200-095 — Choose ONE

A company discovers an unapproved Google Cloud resource service already enabled in several development projects. The service is explicitly supported by the Restrict Resource Service Usage constraint, and application dependency testing is complete. Security wants a centrally managed policy that blocks its runtime use for those in-scope resources, including existing ones. Merely preventing a future API-enable operation is insufficient. Which control should it apply after the staged rollout checks? Choose ONE.

**A.** Apply a gcp.restrictServiceUsage policy denying the service at the development folder and account for inheritance and supported dependencies.

**B.** Use only constraints/serviceuser.services because it retroactively denies all runtime calls for every already-enabled Google API.

**C.** Remove the service's public hostname from a VPC DNS zone and assume console and external authenticated API requests are also blocked.

**D.** Remove Service Usage Admin from developers and assume that existing resources of the enabled service become inaccessible.

**Answer: A**

The named resource-service constraint controls supported runtime resource use. Enablement permissions and DNS manipulation alone do not impose the requested hierarchy-wide runtime restriction.

**Guide mapping:** 2.1; Restrict supported service runtime use rather than only enablement. **Editorial difficulty:** hard.

- **A:** This is the supported policy for the stated service and scope.
- **B:** That legacy enablement constraint is limited and nonretroactive; it is not the requested runtime control.
- **C:** DNS changes in one VPC do not constrain other access paths.
- **D:** Removing enablement authority does not disable existing access.

**Service assumption/limitation:** This constraint has a supported-service scope and excludes essential dependencies such as IAM, Logging and Monitoring.

- [Restrict service usage](https://docs.cloud.google.com/organization-policy/restrict-services) — gcp.restrictServiceUsage controls supported resource-service runtime use, including existing in-scope resources.

Sources checked 2026-11-03. Original author ID: `NETWORK-020`.

---

<a id="q096"></a>
### PCSE200-096 — Choose ONE

A team piloting Agent Gateway on supported Agent Runtime deployments has enabled IAM policy dry-run to assess disruption. Test agents can still call an unapproved destination, even though evaluation logs show that the proposed policy would deny access. Management now requires the policy to block that path after approved dependencies have been validated. Preview access is available and the traffic is confirmed to traverse the gateway. What should the engineer do? Choose ONE answer.

**A.** Add a second explicit deny rule but leave IAM policy evaluation in dry-run mode.

**B.** Remove the destination's existing allow policy but leave the policy engine in dry-run mode.

**C.** Alert on every deny-evaluation log while retaining dry-run for production traffic.

**D.** Disable IAM policy dry-run, enable enforcement, and verify both prohibited and approved destination tests.

**Answer: D**

Dry-run evaluates policy without enforcing its deny outcome. After dependency validation, switching to enforcement and testing both paths verifies the intended behavior.

**Guide mapping:** 3.3; Move Agent Gateway access policies from dry-run to enforcement. **Editorial difficulty:** medium.

- **A:** A more specific hypothetical denial remains non-enforcing in dry-run.
- **B:** Policy content changes are still evaluated without blocking while dry-run remains enabled.
- **C:** Alerting improves visibility but does not meet the requirement to block the path.
- **D:** This changes the control from observation to enforcement and confirms the result.

**Service assumption/limitation:** Assumes approved Preview access and a supported Agent Runtime deployment.

- [Set up Agent Gateway](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/set-up-agent-gateway) — Dry-run does not enforce IAM policies; enforcement requires appropriate configuration.

Sources checked 2026-11-03. Original author ID: `DATA-046`.

---

<a id="q097"></a>
### PCSE200-097 — Choose TWO

An operations group must SSH to IPv4-only Compute Engine VMs without external IP addresses. The VMs have working SSH servers and OS Login permissions for the operators. No firewall rule currently permits SSH, and operators lack IAP tunnel permissions. The company will use IAP TCP forwarding and must avoid exposing SSH to arbitrary sources. Which TWO changes complete the missing network and tunnel authorization requirements? Choose TWO.

**A.** Grant the operators IAP-secured Tunnel User access on the intended instances or an appropriately scoped parent.

**B.** Allow ingress TCP/22 from the operators' changing home IP addresses to all VM targets.

**C.** Allow ingress TCP/22 from 35.235.240.0/20 to the intended VM targets.

**D.** Grant Compute Network User on the VM subnet and leave IAP tunnel IAM unchanged because the operators already have OS Login.

**Answer: A, C**

IAP tunnel authorization is separate from OS Login. The IAP forwarding source range must also reach the VM's SSH listener; neither requirement needs a VM external IP.

**Guide mapping:** 2.1; Secure administrative access with IAP TCP forwarding. **Editorial difficulty:** medium.

- **A:** This supplies the missing tunnel authorization.
- **B:** IAP-forwarded traffic originates from the IAP range, not the laptop's home address.
- **C:** This supplies the narrowly scoped ingress path used by IAP TCP forwarding.
- **D:** Network consumption permission is not the missing authorization to establish an IAP tunnel.

- [Use IAP for TCP forwarding](https://docs.cloud.google.com/iap/docs/using-tcp-forwarding) — IAP tunnel IAM authorization and ingress from 35.235.240.0/20 are distinct requirements; broad SSH rules permit bypass.

Sources checked 2026-11-03. Original author ID: `NETWORK-009`.

---

<a id="q098"></a>
### PCSE200-098 — Choose ONE

A long-running batch service opens new Cloud SQL for PostgreSQL connections throughout a six-hour run. It currently generates one IAM access token at startup and supplies that token as the database password. Initial connections succeed, but later connection attempts fail while existing pooled connections may remain usable. Network routing and database grants are correct, and Context-Aware Access is not configured. Which change best removes this credential-lifetime failure without introducing stored database passwords? Choose ONE answer.

**A.** Use a Cloud SQL connector with automatic IAM database authentication and the correct runtime identity.

**B.** Increase the database session idle timeout to exceed the batch duration.

**C.** Generate a new token once per six-hour run and configure retries to reuse it after a login failure.

**D.** Store the startup token as a Secret Manager version and reuse it for every connection.

**Answer: A**

Automatic IAM database authentication delegates access-token refresh to a supported connector. IAM database tokens are short-lived; storing or privileging a token does not extend its validity.

**Guide mapping:** 3.1; Use refreshable Cloud SQL IAM database authentication. **Editorial difficulty:** medium.

- **A:** Connector-managed refresh supports long-running connection pools without static passwords.
- **B:** Session settings do not refresh credentials used for new logins.
- **C:** Retrying with the expired token does not establish a valid identity for new connections.
- **D:** Secret storage protects the token but does not extend its lifetime.

- [IAM authentication for Cloud SQL for PostgreSQL](https://docs.cloud.google.com/sql/docs/postgres/iam-authentication) — Connectors automate refresh of one-hour IAM database authentication tokens over encrypted connections.

Sources checked 2026-11-03. Original author ID: `DATA-011`.

---

<a id="q099"></a>
### PCSE200-099 — Choose ONE

A regulated team must access a protected application only when BOTH its managed device requirement and its office-network requirement are satisfied. Two tested Access Context Manager levels already express these individual requirements. A new combined level instead permits a managed laptop on a home network and an unmanaged laptop at the office. The enforcement point correctly references that combined level. Which correction best matches the policy intent? Choose ONE.

**A.** Require both existing levels in the combined condition, using AND semantics, and test all four device/network combinations.

**B.** Keep an OR combination because each existing level is individually trusted.

**C.** Require only the managed-device level and document office access as an operational expectation.

**D.** Create two independent unconditional allow bindings, one for each existing level's users.

**Answer: A**

The observed truth table is consistent with alternatives being accepted. The stated policy requires the intersection, not the union, of device and network requirements.

**Guide mapping:** 1.4; Combine device and network conditions correctly. **Editorial difficulty:** hard.

- **A:** Correct: validate the conjunction with positive and negative cases.
- **B:** Either condition alone fails the explicit both-required policy.
- **C:** A procedural network expectation does not enforce the required network predicate.
- **D:** Independent grants can admit either path rather than requiring both.

- [Creating a basic access level](https://docs.cloud.google.com/access-context-manager/docs/create-basic-access-level) — Basic access level conditions can combine device and network requirements.

Sources checked 2026-11-03. Original author ID: `ACCESS-036`.

---

<a id="q100"></a>
### PCSE200-100 — Choose ONE

A transaction archive must use customer-managed keys whose cryptographic operations execute in FIPS 140-2 Level 3 certified hardware. The approved design permits Google to host and operate the hardware; external custody and dedicated single-tenant devices are not required. The archive service supports CMEK using Cloud HSM in the selected location. Which key arrangement meets the control with the least additional infrastructure for the customer to operate? Choose ONE answer.

**A.** Generate the key in an offline ceremony, then import it with SOFTWARE protection into Cloud KMS.

**B.** An HSM-protected Cloud KMS key used by the archive's CMEK integration.

**C.** A software-protected Cloud KMS key with a more frequent rotation period.

**D.** Use a supported external software key manager with customer-controlled access approvals.

**Answer: B**

Cloud HSM offers managed hardware-backed key storage and cryptographic operations through Cloud KMS. Software storage, extra rotation or a VM-hosted service does not supply the specified HSM boundary.

**Guide mapping:** 3.2; Select hardware protection for explicit HSM requirements. **Editorial difficulty:** medium.

- **A:** Generation provenance does not make subsequent software-protected operations occur in certified hardware.
- **B:** The managed HSM protection level matches the explicit hardware requirement.
- **C:** Rotation frequency does not convert software cryptography into certified hardware operations.
- **D:** External custody is a different control and this proposal still lacks the required HSM cryptographic boundary.

- [Cloud HSM](https://docs.cloud.google.com/kms/docs/hsm) — HSM keys use managed FIPS 140-2 Level 3 hardware through the Cloud KMS interface.

Sources checked 2026-11-03. Original author ID: `DATA-021`.

---
## Set 3

<a id="q101"></a>
### PCSE200-101 — Choose ONE

A VPC has Public NAT configured for eligible primary subnet ranges in one region. Internal-only VMs previously reached a third-party update repository, using the reserved NAT addresses that the repository allowlists. During a network-appliance migration, a more-specific static route for the repository prefix was introduced with the appliance as its next hop. New update connections now fail, although other internet destinations still work. The NAT configuration and VM egress firewall permissions have not changed, and neither VM external addresses nor a new proxy service is approved. The intended design remains direct managed Public NAT for this repository. The engineer needs to repair the selected path rather than change token permissions, NAT identity or application behavior. What is the best correction? Choose ONE.

**A.** Replace the unintended appliance route with an eligible route to default-internet-gateway for that prefix and verify new flows.

**B.** Increase NAT port allocation because Public NAT processes all egress routes regardless of the selected next hop.

**C.** Remove and recreate the NAT configuration using the same addresses while leaving the more-specific appliance route unchanged.

**D.** Add a BGP session to the Cloud Router hosting NAT so it can translate packets forwarded through any appliance.

**Answer: A**

Public NAT applies to eligible traffic using local static routes to the default internet gateway. Selecting the appliance route diverts the packet away from that path.

**Guide mapping:** 2.3; Troubleshoot Public NAT route eligibility. **Editorial difficulty:** hard.

- **A:** This restores the intended routing path for the approved prefix.
- **B:** Port allocation does not correct the next-hop mismatch.
- **C:** Recreating NAT does not change which route the repository traffic selects.
- **D:** Cloud Router is not the NAT packet-forwarding appliance and BGP does not remove route eligibility requirements.

- [Public NAT](https://docs.cloud.google.com/nat/docs/public-nat) — Public NAT serves eligible outbound flows using default-internet-gateway routes and does not accept unsolicited inbound traffic.
- [Troubleshoot Cloud NAT configuration](https://docs.cloud.google.com/nat/docs/troubleshooting) — NAT depends on eligible routes and connection mappings and is not an inbound access proxy.

Sources checked 2026-11-03. Original author ID: `NETWORK-040`.

---

<a id="q102"></a>
### PCSE200-102 — Choose TWO

A utility's normal privileged-access entitlement requires an approver, but a severe overnight outage could leave no approver reachable. Leadership explicitly approves a separate emergency path for a small named responder group. The path must require an explanation, expire quickly, and support later review; routine staff must retain the normal approval workflow. Which TWO choices best implement this approved emergency design? Choose TWO.

**A.** Create a separate short-duration PAM entitlement limited to the designated emergency responders, without mandatory preapproval.

**B.** Disable approvals on every existing entitlement to eliminate all approval-related outages.

**C.** Grant the emergency role permanently to every on-call engineer because the audit logs will constrain their actions.

**D.** Require a justification and review the emergency grant and subsequent activity through the available audit evidence.

**Answer: A, D**

PAM supports emergency grants without preapproval. A narrowly eligible, short-lived entitlement with justification and audit review implements the approved exception without changing routine access.

**Guide mapping:** 1.4; Design controlled emergency elevation. **Editorial difficulty:** hard.

- **A:** Correct: it localizes the approved availability exception.
- **B:** This broadens the exception beyond the approved responder group.
- **C:** Logging records activity; it does not remove standing privilege.
- **D:** Correct: it supplies the required explanation and review evidence.

- [Privileged Access Manager overview](https://docs.cloud.google.com/iam/docs/pam-overview) — Entitlements define eligible requesters, roles, duration, justification and optional approval; grants expire.

Sources checked 2026-11-03. Original author ID: `ACCESS-042`.

---

<a id="q103"></a>
### PCSE200-103 — Choose TWO

A Cloud Build trigger currently runs under a broadly privileged user-managed service account. An engineer changes the repository build YAML to name a restricted account, but triggered builds still access production resources. The team must use the restricted identity for future trigger executions and let one operator maintain the trigger without granting project-wide service-account impersonation. Which two actions address the actual configuration and permission boundaries? Choose TWO.

**A.** Keep the existing trigger account and remove the serviceAccount field from the YAML so Cloud Build reselects the restricted account.

**B.** Set the restricted service account on the trigger itself and grant it only the resource permissions required by its build steps.

**C.** Grant the operator the necessary trigger-management permissions and actAs on the old and new trigger accounts for the identity transition.

**D.** Grant the operator Service Account Token Creator on every account in the project to make trigger changes reliable.

**Answer: B, C**

Triggered builds use the account configured on the trigger, overriding the build-file selection. Updating a trigger identity requires actAs on both the previous and replacement account, scoped to those accounts.

**Guide mapping:** 4.1; Select and authorize the effective Cloud Build trigger identity. **Editorial difficulty:** hard.

- **A:** Removing the YAML field does not replace the account configured on the trigger.
- **B:** This changes the effective identity rather than an ignored build-file field.
- **C:** This supplies the documented transition permissions without project-wide impersonation.
- **D:** Broad token creation is unnecessary and expands the impersonation surface.

- [Run builds with a user-managed service account](https://docs.cloud.google.com/build/docs/securing-builds/configure-user-specified-service-accounts) — Only the service account on the trigger is used for trigger-invoked builds.
- [Default Cloud Build service account: trigger privileges](https://docs.cloud.google.com/build/docs/cloud-build-service-account) — Trigger updates require actAs on both old and new service accounts.

Sources checked 2026-11-03. Original author ID: `OPS-007`.

---

<a id="q104"></a>
### PCSE200-104 — Choose ONE

During an outage review, Cedar Markets finds an Access Approval request marked auto approved. Its workload uses the default signing-key configuration and a package for which outage auto-approval remains enabled. The compliance spreadsheet states that every Google personnel access waits for manual customer approval. No evidence indicates a customer IAM grant was used for the event. Which conclusion and response are best supported? Choose ONE.

**A.** Investigate the request and associated access evidence, correct the absolute control claim, and evaluate supported package/key controls if stricter guarantees are required.

**B.** Treat the status as evidence that Access Transparency was disabled, and enable it to force all future approvals to be manual.

**C.** Treat the event as proof that customer approver credentials were compromised, and rotate those credentials before examining the request.

**D.** Replace Access Approval with PAM so future Google support work is subject to the company's temporary-role approval policy.

**Answer: A**

The documented outage path can automatically approve requests in this configuration. The event needs review, but it does not by itself prove compromise.

**Guide mapping:** 5.1; Evaluate Access Approval exceptions without overclaiming prevention. **Editorial difficulty:** hard.

- **A:** This reconciles actual behavior with the stated configuration and revisits the requirement honestly.
- **B:** Access Transparency is not a manual-approval switch.
- **C:** The status has a documented alternative explanation.
- **D:** PAM does not replace the provider access-approval mechanism.

**Service assumption/limitation:** Access Approval also inherits Access Transparency exclusions. Some control packages disable outage auto-approval.

- [Overview of Access Approval](https://docs.cloud.google.com/assured-workloads/access-approval/docs/overview) — Access Approval governs enrolled supported Google personnel access, complements Access Transparency, and has exclusions and potential outage auto-approvals.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-007`.

---

<a id="q105"></a>
### PCSE200-105 — Choose ONE

A retailer acquires several business units with hundreds of BigQuery datasets. The security team cannot maintain a list of every new table, and it initially needs a prioritized inventory of sensitive columns rather than exported row contents. Findings must adapt as teams create or modify tables. A separate remediation process will decide whether to restrict access. Which design best satisfies the discovery requirement without confusing classification with enforcement? Choose ONE answer.

**A.** Run one inspection job against the acquisition's initial table list and retain its findings as the permanent inventory.

**B.** Enable BigQuery column access policies on all string fields and use denied queries as the sensitivity inventory.

**C.** Configure organization-scoped Sensitive Data Protection discovery with an inspection template and profiling schedule.

**D.** Schedule a daily export of every table and redact all columns before deciding which datasets need investigation.

**Answer: C**

Discovery profiles classify supported resources and refresh according to scan configuration, producing risk and sensitivity insights. Profiles inform remediation; they do not independently revoke data access.

**Guide mapping:** 3.1; Discover sensitive data at organization scale. **Editorial difficulty:** medium.

- **A:** A fixed inspection list misses subsequently created resources and changed data.
- **B:** Column permissions enforce decisions but do not discover which columns contain sensitive data.
- **C:** Discovery addresses changing organization-wide inventory and provides column-level insights.
- **D:** Full exports and redaction perform an unnecessary transformation before the required inventory exists.

- [Overview of sensitive data discovery](https://docs.cloud.google.com/sensitive-data-protection/docs/data-profiles) — Discovery profiles classify sensitivity and risk; inspect and enforce separately.

Sources checked 2026-11-03. Original author ID: `DATA-001`.

---

<a id="q106"></a>
### PCSE200-106 — Choose ONE

A consulting firm discovers that allowing employees to enroll in 2-Step Verification has left many administrators using only passwords. Management now requires phishing-resistant authentication for those privileged accounts. The administrators have supported security keys, but the team must avoid preventable lockouts during the rollout and preserve a documented recovery path. Which approach best meets the requirement for the targeted group? Choose ONE.

**A.** Enforce any second factor immediately and allow SMS as the permanent compliance standard.

**B.** Keep optional enrollment and send a reminder that administrators should prefer strong passwords.

**C.** Enroll and verify the administrators first, configure the allowed security-key method and enforcement, and prepare controlled recovery.

**D.** Enforce 2SV while permitting any available factor and treat enrollment alone as evidence of phishing resistance.

**Answer: C**

Allowing enrollment is not enforcement. A staged rollout verifies readiness before requiring the selected phishing-resistant method, while controlled recovery addresses lockouts.

**Guide mapping:** 1.3; Deploy enforced phishing-resistant two-step verification. **Editorial difficulty:** medium.

- **A:** Unverified immediate enforcement risks lockouts, and SMS is not the requested phishing-resistant method.
- **B:** Optional enrollment does not satisfy required 2SV.
- **C:** Correct: it combines enrollment readiness, method restriction, enforcement and recovery.
- **D:** Any-factor enforcement does not require the phishing-resistant method requested by policy.

**Service assumption/limitation:** Confirm current permitted methods, passkey treatment and organizational settings in the actual tenant.

- [Deploy 2-Step Verification](https://knowledge.workspace.google.com/admin/security/deploy-2-step-verification) — 2SV enforcement can be staged with enrollment and permitted authentication methods.
- [Security best practices for administrator accounts](https://knowledge.workspace.google.com/admin/users/security-best-practices-for-administrator-accounts) — Use individually attributable admin accounts, separate daily accounts, strong 2SV and multiple super administrators.

Sources checked 2026-11-03. Original author ID: `ACCESS-028`.

---

<a id="q107"></a>
### PCSE200-107 — Choose ONE

A fleet of IPv4-only VMs without external addresses must fetch updates from a third-party internet repository. The repository requires a small stable allowlist of source public IPs. The fleet runs in one region; eligible default-internet-gateway routing and egress firewall permission already exist. Unsolicited inbound connections to the VMs must remain unavailable, and the team wants a managed outbound service rather than a proxy VM. Which configuration should it use? Choose ONE.

**A.** Assign a reserved external IP to every VM and provide all those addresses to the repository, retaining narrow egress firewall rules.

**B.** Configure Public NAT for the fleet's subnet ranges with manually allocated reserved external IP addresses and provide those addresses to the repository.

**C.** Enable Private Google Access on the subnet and provide the restricted.googleapis.com VIP range to the third-party repository.

**D.** Configure only automatic Public NAT address allocation and promise the repository that its allowlist never needs an address-management process.

**Answer: B**

Public NAT with managed, manually allocated external addresses gives eligible internal-only VMs a stable outbound source set. It does not create an unsolicited inbound path.

**Guide mapping:** 2.3; Provide stable outbound internet addresses without VM public addresses. **Editorial difficulty:** medium.

- **A:** This provides stable egress but violates both internal-only VM addressing and the small shared source set.
- **B:** This meets stable-source, managed-egress and internal-only VM requirements.
- **C:** PGA serves Google APIs, not arbitrary third-party internet repositories.
- **D:** Automatic allocation does not provide the same deliberate fixed-address lifecycle required by the repository.

- [Set up and manage network address translation with Public NAT](https://docs.cloud.google.com/nat/docs/set-up-manage-network-address-translation) — Public NAT supports manually allocated addresses; configuration is scoped to a VPC and region.
- [Public NAT](https://docs.cloud.google.com/nat/docs/public-nat) — Public NAT serves eligible outbound flows using default-internet-gateway routes and does not accept unsolicited inbound traffic.

Sources checked 2026-11-03. Original author ID: `NETWORK-039`.

---

<a id="q108"></a>
### PCSE200-108 — Choose ONE

A security engineer creates an Access Context Manager access level requiring the approved device posture and corporate source network. The organization has an application on a supported IAP web path and an organization-level access policy, but its existing IAP authorization is unchanged. Tests still permit a user from a noncompliant device. The engineer expected creating the access level to restrict the application automatically. Which action best completes the intended design? Choose ONE.

**A.** Grant the users an additional unconditional IAP application-access binding to accompany the new access level.

**B.** Update the applicable IAP-secured Web App User bindings to require the access level, remove unconditional bypasses for these users, and test both request types.

**C.** Configure an office IP condition only on an unrelated project role while leaving application admission unchanged.

**D.** Create separate device and network access levels but leave both unreferenced in the application's authorization.

**Answer: B**

Access Context Manager defines context; an integrated service such as IAP enforces it. An unreferenced access level does not automatically change the application's admission policy.

**Guide mapping:** 1.4; Connect context definitions to an enforcement point. **Editorial difficulty:** medium.

- **A:** An unconditional binding does not require the contextual checks and can preserve an alternative allow path.
- **B:** The consuming IAP authorization must enforce the level, and an independent unconditional allow would otherwise preserve access.
- **C:** Changing a different authorization path does not make IAP require the intended device and network context.
- **D:** Additional unreferenced definitions still do not enforce the application requirement.

**Service assumption/limitation:** Device signals, licensing and supported IAP condition behavior must be validated in deployment.

- [Access Context Manager Overview](https://docs.cloud.google.com/access-context-manager/docs/overview) — Access Context Manager defines context policies; enforcement occurs at integrated enforcement points.
- [Set up context-aware access with IAP](https://docs.cloud.google.com/iap/docs/cloud-iap-context-aware-access-howto) — Apply access levels through conditional IAP authorization on the supported application path.

Sources checked 2026-11-03. Original author ID: `ACCESS-035`.

---

<a id="q109"></a>
### PCSE200-109 — Choose ONE

An external data-processing job authenticates through a workload identity pool, but its target API requires service account impersonation for this deployment. Token exchange with Security Token Service succeeds. The next step, obtaining the designated service account's credentials, fails with an authorization error. The service account already has the correct target-resource role, and only this job should impersonate it. Which change is appropriate? Choose ONE.

**A.** Grant the approved federated principal Workload Identity User on the designated service account.

**B.** Grant the external job Owner on the target resource project.

**C.** Grant the designated service account the workload pool administration role.

**D.** Grant the approved federated principal Service Account User on every project account.

**Answer: A**

Federated admission, service account impersonation authorization, and the service account's resource permissions are separate. Workload Identity User on the designated account enables the required federation-to-account step.

**Guide mapping:** 1.2; Authorize federated service account impersonation. **Editorial difficulty:** hard.

- **A:** Correct: it grants the approved external principal the needed ability on one account.
- **B:** Project ownership is unnecessarily broad and not the scoped impersonation design.
- **C:** Pool administration is control-plane management, not the missing authorization.
- **D:** Attachment permission is not the required federated impersonation permission.

- [Workload Identity Federation](https://docs.cloud.google.com/iam/docs/workload-identity-federation) — External workload credentials can be exchanged for federated tokens with direct access or service account impersonation.
- [Configure Workload Identity Federation with deployment pipelines](https://docs.cloud.google.com/iam/docs/workload-identity-federation-with-deployment-pipelines) — Restrict shared issuers by attributes; numeric repository and owner IDs resist name reuse.

Sources checked 2026-11-03. Original author ID: `ACCESS-016`.

---

<a id="q110"></a>
### PCSE200-110 — Choose TWO

The SOC has approved a narrow temporary exception for one known finding category on a specific test resource. The corresponding SCC findings are muted and disappear from the default dashboard. Nevertheless, the external incident system continues opening tickets when those findings are updated because an existing NotificationConfig exports all ACTIVE findings to Pub/Sub. Security wants the issue to remain discoverable for audit, and findings for production resources must still create tickets. The Pub/Sub transport is healthy and the incident system intentionally creates tickets from every delivered notification. Changing only its dashboard would not address incoming ticket volume. Which two changes or interpretations correctly support that goal? Choose TWO.

**A.** Set every matching finding to INACTIVE so the notification configuration can continue treating all ACTIVE findings as actionable.

**B.** Disable the source detector for the whole organization because muted findings cannot otherwise be omitted from exports.

**C.** Keep the accepted findings muted and record the scoped exception; muting does not mean the resource issue has been remediated.

**D.** Change the NotificationConfig filter to exclude muted findings while retaining its intended active-finding scope.

**Answer: C, D**

Muting controls finding presentation but does not automatically suppress matching Pub/Sub notifications. The export filter must exclude muted findings if downstream tickets should follow that distinction.

**Guide mapping:** 4.2; Align SCC mute semantics with downstream notification filtering. **Editorial difficulty:** hard.

- **A:** Changing state would misrepresent a continuing issue as resolved.
- **B:** A mute-aware export filter avoids organization-wide detection loss.
- **C:** This preserves truthful state and an auditable exception.
- **D:** This makes downstream notification behavior match the explicit mute decision.

- [Mute individual findings](https://docs.cloud.google.com/security-command-center/docs/mute-individual-findings) — Muted findings matching notification filters still export; excluding mute=MUTED in NotificationConfig suppresses them.

Sources checked 2026-11-03. Original author ID: `OPS-034`.

---

<a id="q111"></a>
### PCSE200-111 — Choose ONE

A service account holds a broad production role. A review proposes replacing that binding with two narrower roles, and the application owner wants to know whether the change could break known operations before approving it. Historical access logs cover ordinary daily requests and some previous reporting jobs. However, a seasonal export runs infrequently, and a new workflow scheduled for next quarter has never appeared in the available logs. The engineer has permission to examine the relevant policies and to use supported Policy Intelligence tools. Leadership wants evidence about the proposed change, without treating a lack of observed permission use as proof that a permission will never be needed. The account and production architecture must remain in place during this assessment. Which approach best meets the requirement? Choose ONE.

**A.** Use Policy Troubleshooter once on a successful request and treat that result as full regression coverage.

**B.** Use Policy Analyzer alone to prove that every future application request will succeed.

**C.** Apply the recommendation immediately because unused observed permissions can never be needed later.

**D.** Simulate the proposed allow-policy change, review affected historical access, and separately test the seasonal and new workflows.

**Answer: D**

Simulation estimates the impact on historical access. It cannot demonstrate that unobserved or future business operations will succeed, so those paths require separate validation.

**Guide mapping:** 1.4; Evaluate a proposed role reduction before applying it. **Editorial difficulty:** hard.

- **A:** One current access decision cannot validate the proposed change across all workflows.
- **B:** An access inventory is not a prediction of all future workload behavior.
- **C:** Observed non-use is not proof of permanent lack of need.
- **D:** Correct: it combines the right tool with testing for unrepresented paths.

- [Test role changes with Policy Simulator](https://docs.cloud.google.com/policy-intelligence/docs/simulate-iam-policies) — Simulation evaluates candidate policy changes using historical access information.

Sources checked 2026-11-03. Original author ID: `ACCESS-037`.

---

<a id="q112"></a>
### PCSE200-112 — Choose ONE

An organization enables DATA_READ logging for a supported service and exempts one high-volume batch service account. A regulated child project must now record that account too. The project administrator enables DATA_READ explicitly and supplies an empty local exemption list. New reads by ordinary users appear, but the batch account remains absent. The administrator can verify the parent configuration and confirms that the calls are otherwise loggable. Which explanation and correction are appropriate? Choose ONE.

**A.** The batch account must receive Private Logs Viewer before its API requests become eligible for audit generation.

**B.** The local empty list should override the parent; recreate the project logging bucket to refresh inherited configuration.

**C.** Effective audit configuration includes inherited exemptions; remove or restructure the parent exemption at the level where it is defined.

**D.** Add the account to the local exemption list to cancel the matching inherited exemption through duplicate detection.

**Answer: C**

Audit configurations combine across the hierarchy. A child can add logging and exemptions but cannot remove an exemption inherited from a parent by supplying an empty list.

**Guide mapping:** 4.2; Diagnose inherited audit exemptions and additive configuration. **Editorial difficulty:** hard.

- **A:** Log-reading permissions do not control whether a principal API call generates an audit record.
- **B:** Bucket recreation cannot change effective audit configuration inheritance.
- **C:** This repairs the actual inherited exemption that suppresses generation.
- **D:** Adding an exemption reinforces omission; it does not cancel it.

- [Enable Data Access audit logs](https://docs.cloud.google.com/logging/docs/audit/configure-data-access) — Hierarchy configurations are combined, and child resources cannot remove parent exemptions.

Sources checked 2026-11-03. Original author ID: `OPS-030`.

---

<a id="q113"></a>
### PCSE200-113 — Choose ONE

A risk-scoring service already encrypts its Persistent Disk and uses TLS for requests. A new requirement addresses memory exposure to the underlying host while the application processes sensitive records. The service runs on an existing ordinary Compute Engine VM, and a short migration window is available. The team wants the additional in-use protection without assuming it repairs application vulnerabilities. Which deployment plan is appropriate? Choose ONE answer.

**A.** Keep the existing VM and move its disk key from software protection to Cloud HSM through a supported migration.

**B.** Stop the ordinary VM, switch its machine type, and set confidential-compute configuration in place.

**C.** Create a new Shielded VM with Secure Boot and integrity monitoring but no Confidential VM configuration.

**D.** Create a supported Confidential VM with a compatible machine type, platform, zone, and OS, then migrate and validate the workload.

**Answer: D**

Confidential VM supplies hardware-backed in-use protection and has platform requirements. Existing ordinary instances cannot simply be converted; encryption at rest and TLS address different states.

**Guide mapping:** 3.2; Plan a supported Confidential VM deployment. **Editorial difficulty:** medium.

- **A:** Changing at-rest key protection does not supply in-use memory encryption.
- **B:** The documented supported path requires creating a new Confidential VM rather than converting the existing instance.
- **C:** Boot-integrity features are valuable but do not provide the requested memory-encryption property.
- **D:** This applies the documented deployment constraints and preserves other controls.

- [Supported Confidential VM configurations](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/supported-configurations) — Confidential VM requires a supported new instance and compatible platform configuration.
- [Confidential VM overview](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/confidential-vm-overview) — Hardware memory encryption and attestation address data in use.

Sources checked 2026-11-03. Original author ID: `DATA-034`.

---

<a id="q114"></a>
### PCSE200-114 — Choose ONE

A maintenance orchestrator has been authorized to impersonate a narrowly scoped service account. Each operation lasts about fifteen minutes, and policy limits the credential it hands to a worker to twenty minutes. The worker cannot retain a private key, and the orchestrator must use a supported Google credential API. No extended-lifetime exception is configured. Which implementation best matches the credential requirement? Choose ONE.

**A.** Issue the default-lifetime OAuth access token and terminate the worker after twenty minutes.

**B.** Call the IAM Credentials access-token method with a 1,200-second lifetime and required scopes.

**C.** Request an OIDC ID token and use its audience field to express twenty minutes.

**D.** Download a service account key and delete the file after twenty minutes.

**Answer: B**

An access token requested with a supported short lifetime expires independently of local cleanup. A key file's deletion does not revoke copied material, and an ID token audience is not an expiration setting.

**Guide mapping:** 1.2; Limit access-token lifetime without private keys. **Editorial difficulty:** hard.

- **A:** Stopping the worker does not shorten a copied bearer token’s server-enforced validity to the required twenty minutes.
- **B:** Correct: the API can issue a short-lived OAuth access token with the specified lifetime.
- **C:** Audience specifies the token recipient, not the access-token lifetime.
- **D:** Local cleanup cannot make copied private-key material expire.

- [Create short-lived credentials for a service account](https://docs.cloud.google.com/iam/docs/create-short-lived-credentials-direct) — IAM Credentials creates access tokens and ID tokens with appropriate permissions and token parameters.

Sources checked 2026-11-03. Original author ID: `ACCESS-022`.

---

<a id="q115"></a>
### PCSE200-115 — Choose ONE

An outage requires deploying one emergency GKE image before the normal attestation service can recover. The incident commander has approved this specific exception and requires a reviewable audit trail. Other deployments must continue to be blocked if they lack approval. The team can edit the emergency workload manifest and is authorized to use Binary Authorization breakglass. Which approach best preserves the required enforcement boundary? Choose ONE.

**A.** Set the entire production cluster rule to dry-run mode and rely on the change ticket to restrict deployments.

**B.** Put the application repository on the exempt-image list so every tag in that repository can deploy during recovery.

**C.** Use breakglass for the emergency deployment, record and monitor its audit event, and remove the exception when normal release approval is restored.

**D.** Switch the project default rule to allow all images until the incident is closed, then investigate any concurrent releases.

**Answer: C**

The approved exception is one deployment. Workload breakglass provides a targeted bypass with logging; policy-wide relaxation would also affect other releases.

**Guide mapping:** 4.1; Use a narrow auditable deployment exception. **Editorial difficulty:** medium.

- **A:** Dry-run audits noncompliance but permits unrelated unapproved images in that cluster.
- **B:** A repository exemption covers more images than the incident approval.
- **C:** This scopes the bypass to the approved workload and retains evidence for review.
- **D:** Allow-all weakens approval for unrelated deployment attempts.

**Service assumption/limitation:** Authorization and exception approval are explicit scenario assumptions; breakglass does not itself provide an approval workflow.

- [Use breakglass with GKE](https://docs.cloud.google.com/binary-authorization/docs/using-breakglass) — GKE breakglass permits a workload deployment despite policy and generates an audit log.

Sources checked 2026-11-03. Original author ID: `OPS-009`.

---

<a id="q116"></a>
### PCSE200-116 — Choose ONE

A consultancy's HR system emits a confirmed suspension event when a worker begins an extended leave. The security team must prevent new managed-account sign-ins while retaining the user's directory identity and associated data for a potential return. The automation already has appropriately delegated Directory API authorization. Deleting users or relying on a weekly administrator task is unacceptable. Which implementation most directly meets the stated lifecycle requirement? Choose ONE.

**A.** Update the user's suspended state through the Directory API and verify the resulting account state.

**B.** Delete the managed account and recreate it with the same email address when the worker returns.

**C.** Remove the user's Cloud project roles while leaving the managed account enabled.

**D.** Remove the worker from the current application access groups while leaving the managed account enabled.

**Answer: A**

Account suspension is a reversible directory operation. Removing selected Cloud grants does not disable the managed account across its other services, and deletion violates retention of the identity.

**Guide mapping:** 1.1; Automate reversible user suspension. **Editorial difficulty:** medium.

- **A:** Correct: the Directory API supports updating the suspended field.
- **B:** Recreation is not the required preservation of the existing identity.
- **C:** Role removal is incomplete for the managed-account sign-in requirement.
- **D:** This may remove group-based access but does not suspend the managed-account sign-in capability.

**Service assumption/limitation:** Suspension is not represented as instant revocation of every already-issued application credential.

- [Manage user accounts](https://developers.google.com/workspace/admin/directory/v1/guides/manage-users) — The Directory API creates, updates, suspends and deletes managed users.

Sources checked 2026-11-03. Original author ID: `ACCESS-003`.

---

<a id="q117"></a>
### PCSE200-117 — Choose ONE

Solace Brokerage writes completed audit evidence packages to a dedicated Cloud Storage bucket. The approved requirement is that each package remain undeletable and unreplaced for a minimum age, including against a storage administrator who might shorten a configuration by mistake. The archive administrators must still be able to read objects and append new packages. An approved retention schedule has already been tested in a nonproduction bucket, and the organization accepts that the production minimum cannot later be reduced. Backups and versioning are useful recovery measures, but the assessor has specifically requested an enforced retention control. Which configuration most directly satisfies this technical requirement? Choose ONE.

**A.** Configure an unlocked bucket retention policy and monitor policy changes through daily audit-log review.

**B.** Configure the approved bucket retention period and lock the policy, while separately applying least-privilege archive access.

**C.** Configure a lifecycle delete rule at the minimum age and retain the administrators' ability to modify lifecycle rules.

**D.** Enable Object Versioning and give archive administrators permission to delete noncurrent versions after the minimum age.

**Answer: B**

A locked bucket retention policy prevents reducing or removing the minimum, and protects objects until their required age.

**Guide mapping:** 5.1; Map immutable evidence retention to a locked storage policy. **Editorial difficulty:** medium.

- **A:** Monitoring detects a shortened policy but does not prevent it.
- **B:** The lock matches the explicitly approved irreversibility and age requirement.
- **C:** Lifecycle timing is not an immutable minimum-retention boundary.
- **D:** Versioning alone does not stop a privileged deletion of protected evidence.

**Service assumption/limitation:** This concerns technical retention of objects; it does not assert compliance with every requirement of a financial regulation.

- [Bucket Lock](https://docs.cloud.google.com/storage/docs/bucket-lock) — Locking a bucket retention policy permanently prevents reducing or removing that policy and protects unexpired objects against deletion/replacement.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-012`.

---

<a id="q118"></a>
### PCSE200-118 — Choose TWO

All business units send application logs to one security-project bucket. An analyst supporting the retail unit should see only records originating from the retail projects. Investigators need the full bucket. A log view already filters to the retail project identifiers, but the analyst also has an unconditional Logs View Accessor grant on the security project. Testing shows that the analyst can open the all-logs view as well. The analyst needs no project-wide administrative role, and the source-routing design should stay unchanged. Investigators need their existing unrestricted views, so reducing what the shared bucket stores is not acceptable. The retail view has already passed filter-correctness checks. Which two changes correctly implement the intended boundary? Choose TWO.

**A.** Grant the analyst Logs View Accessor on the filtered retail view itself, or an equivalent correctly constrained binding.

**B.** Add the retail filter to the browser default query while leaving all existing project IAM grants in place.

**C.** Remove the analyst project-wide view access and any other grants that provide the unwanted broader log access.

**D.** Replace the filtered view with a saved Logs Explorer query and give the analyst its URL.

**Answer: A, C**

A view is an access boundary only when the principal lacks broader grants. The analyst needs view-specific authorization; a saved query or UI filter is not an authorization restriction.

**Guide mapping:** 4.2; Restrict centralized log access without broader IAM bypass. **Editorial difficulty:** hard.

- **A:** This grants access to the selected subset as a resource-scoped permission.
- **B:** A default query changes presentation, not the effective IAM permissions.
- **C:** Broader access must be removed for the narrow binding to have the intended effect.
- **D:** A shared query does not constrain other queries the principal can issue.

- [Configure log views on a log bucket](https://docs.cloud.google.com/logging/docs/logs-views) — Project-wide viewAccessor permits access to all views; specific-view IAM can restrict a principal to one view.

Sources checked 2026-11-03. Original author ID: `OPS-023`.

---

<a id="q119"></a>
### PCSE200-119 — Choose TWO

A payment application and a marketing application share a project but use distinct runtime service accounts. The payment application must access one payment-provider secret only. Operations also wants a canary deployment to validate a new credential before the rest of the fleet switches, with a predictable rollback if validation fails. Both applications can call Secret Manager directly. Which two changes best implement these access and rollout requirements? Choose TWO answers.

**A.** Make every application read latest so publishing a version immediately tests it across the fleet.

**B.** Grant Secret Accessor at project level and rely on secret naming conventions for isolation.

**C.** Pin deployments to explicit secret versions and promote a tested version through the release process.

**D.** Grant Secret Accessor to the payment identity on the specific payment secret.

**Answer: C, D**

Secret-scoped IAM limits blast radius. Explicit versions permit canary testing and rollback without unexpectedly moving every consumer to a new value.

**Guide mapping:** 3.1; Scope Secret Manager access and validate credential rollout. **Editorial difficulty:** hard.

- **A:** Immediate global consumption defeats controlled canary validation.
- **B:** Names are not an access boundary and project scope exposes other secrets.
- **C:** Version-pinned configuration supports deliberate promotion and rollback.
- **D:** This grants access only to the required secret.

- [Secret Manager best practices](https://docs.cloud.google.com/secret-manager/docs/best-practices) — Use secret-scoped access, controlled version rollout and API retrieval; disable before destruction.

Sources checked 2026-11-03. Original author ID: `DATA-013`.

---

<a id="q120"></a>
### PCSE200-120 — Choose ONE

A company is onboarding twelve product teams, each with separate development and production projects. Central security needs an organization-wide baseline, production-only restrictions, and a common access boundary for each team's production operators. New projects should receive the intended controls through placement rather than repeated manual grants. There is no requirement for a separate organization per team. Which hierarchy is the most appropriate starting design? Choose ONE.

**A.** Place all projects directly under the organization and grant every product operator an organization-wide role.

**B.** Use labels as the only grouping mechanism and rely on labels to inherit folder IAM permissions.

**C.** Keep a flat project hierarchy and duplicate all team and environment policies in each new project manually.

**D.** Use folders that reflect the relevant environment and team boundaries, then apply baseline and delegated policies at their intended ancestor scopes.

**Answer: D**

Folders supply real inheritance and delegation boundaries. A hierarchy aligned with shared control requirements makes new-project placement operationally meaningful.

**Guide mapping:** 1.5; Structure projects for scalable delegated controls. **Editorial difficulty:** medium.

- **A:** This gives operators access across teams and loses the production-only boundary.
- **B:** Labels do not create a policy inheritance hierarchy.
- **C:** This can express controls but misses the requirement to inherit them automatically through project placement.
- **D:** Correct: choose folder boundaries around the groups of resources that share controls.

- [Create folders](https://docs.cloud.google.com/resource-manager/docs/creating-managing-folders) — Folders group projects and support delegated administration and inherited policies.

Sources checked 2026-11-03. Original author ID: `ACCESS-044`.

---

<a id="q121"></a>
### PCSE200-121 — Choose ONE

A fleet of private Ubuntu VMs reports inventory successfully to VM Manager. The OS Config API is enabled and each VM has a healthy agent. A patch job starts, but installation fails when apt attempts to download packages. The network permits access to Google APIs through Private Google Access and intentionally denies general internet egress. Security requires a centrally approved package baseline and does not want public addresses added to the VMs. The application team proposes granting the VM service account broader OS Config permissions because the job is managed by Google. What is the best corrective action? Choose ONE.

**A.** Configure a reachable approved internal package repository and point the VMs package managers at it.

**B.** Grant the VM account OS Config administrator because inventory permissions cannot authorize package downloads.

**C.** Increase the maintenance window until VM Manager transfers the missing packages through the OS Config API.

**D.** Add another Private Google Access route and leave the distribution repository configuration unchanged.

**Answer: A**

VM Manager orchestrates the native package manager; it does not host or relay the OS packages. A controlled reachable repository satisfies both connectivity and baseline requirements.

**Guide mapping:** 4.1; Separate patch orchestration from package-source connectivity. **Editorial difficulty:** medium.

- **A:** This supplies the required package source without public addresses or unrestricted egress.
- **B:** IAM expansion cannot repair the observed package-repository network failure.
- **C:** More time cannot make an unreachable repository reachable.
- **D:** Private Google Access to Google APIs does not generally provide access to Ubuntu distribution repositories.

- [About Patch](https://docs.cloud.google.com/compute/vm-manager/docs/patch) — OS Config uses native package managers; VMs need repository access, and local repositories can control the baseline.

Sources checked 2026-11-03. Original author ID: `OPS-011`.

---

<a id="q122"></a>
### PCSE200-122 — Choose ONE

A service desk sends troubleshooting narratives to an external quality team. The recipient needs technical descriptions, but the release policy prohibits stable identity tokens and recovery of names or email addresses. A pilot currently writes inspection findings to BigQuery and then sends the untouched source text. Every ticket must remain represented in the release, and the source system must retain its originals for internal support. What should the engineer change in the export path to meet the disclosure requirement? Choose ONE answer.

**A.** Apply redaction only to a structured email field and continue forwarding the original narrative field.

**B.** Discard every narrative containing a PII finding and release only tickets with no findings.

**C.** Replace names and emails with stable reversible tokens and establish an investigation re-identification service.

**D.** Apply de-identification redaction to detected identifying spans and release the transformed copy.

**Answer: D**

Inspection identifies sensitive spans but does not itself remove them from released text. A redaction step on the export copy meets the no-identity/no-recovery requirement while preserving internal originals.

**Guide mapping:** 3.1; Separate data inspection from irreversible release transformations. **Editorial difficulty:** medium.

- **A:** The sensitive values occur inside narratives, so transforming a separate field leaves the demonstrated release path open.
- **B:** Dropping tickets removes required technical cases; the scenario requires every ticket to remain represented with identifying spans transformed.
- **C:** Reversible stable tokens preserve linkability and recovery capabilities expressly prohibited by the release policy.
- **D:** Redaction changes the release copy without requiring source deletion.

- [Transformation reference](https://docs.cloud.google.com/sensitive-data-protection/docs/transformations-reference) — Redaction, bucketing and tokenization have different utility and reversibility.

Sources checked 2026-11-03. Original author ID: `DATA-006`.

---

<a id="q123"></a>
### PCSE200-123 — Choose ONE

Birch Group operates a custom risk engine on Compute Engine, analytics in BigQuery and corporate collaboration in Google Workspace. A proposed control matrix assigns every security requirement to the infrastructure team because the products share one cloud provider. Application owners object that they cannot patch Google's underlying BigQuery infrastructure, while the identity team notes that its Workspace data-sharing configuration still needs review. The audit requirement is to name accountable owners and attach evidence for the controls the company actually operates, plus appropriate provider assurance for inherited controls. The company is not changing platforms during this audit. Which revision best resolves the ownership problem? Choose ONE.

**A.** Assign all compute and analytics controls to Google, retaining only Workspace account lifecycle management as a customer obligation.

**B.** Assign all controls to the customer as a conservative measure and require internal patch evidence for every underlying service host.

**C.** Use one SaaS responsibility template for all three products, then replace missing customer evidence with the provider's certificates.

**D.** Map each control to the service and operation, separating provider infrastructure responsibilities from customer application, identity, configuration and data obligations.

**Answer: D**

The ownership boundary depends on service and feature. Provider assurance covers inherited controls; customer evidence covers its own implementation.

**Guide mapping:** 5.1; Build control ownership by service and operation instead of applying a single cloud-wide owner. **Editorial difficulty:** medium.

- **A:** Customer application, access and data obligations also exist in compute and analytics.
- **B:** An owner cannot produce valid operational evidence for provider-managed hosts it does not operate.
- **C:** A single SaaS template does not fit the mixed architecture.
- **D:** This assigns owners to actual responsibilities and matches the required evidence.

- [Shared responsibilities and shared fate on Google Cloud](https://docs.cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate) — Responsibilities vary by service model and feature; customers retain responsibility for access policies and their data.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-018`.

---

<a id="q124"></a>
### PCSE200-124 — Choose TWO

A document-conversion VM fetches objects with an attached service account and runs third-party conversion code on attacker-controlled documents. The account has input/output bucket access and also inherits project-wide Storage Object Admin. The conversion code needs neither Google API credentials nor instance metadata. Network rules already block public ingress, but the team worries that a converter compromise could request metadata credentials locally. Which two measures directly reduce this risk? Choose TWO answers.

**A.** Require the Metadata-Flavor header and assume third-party conversion code cannot construct that header.

**B.** Reduce the attached identity's permissions to the exact input and output resources required.

**C.** Rely on the absence of an external IP to block the converter's local metadata requests.

**D.** Sandbox the converter so it cannot query the metadata endpoint or access the trusted fetcher's credentials.

**Answer: B, D**

Local metadata credentials are reachable independently of public ingress. Sandbox isolation reduces the converter's credential access; removing the inherited project-wide Storage Object Admin grant and retaining only required bucket permissions reduces the credential's blast radius.

**Guide mapping:** 3.1; Constrain metadata exposure to untrusted VM processes. **Editorial difficulty:** hard.

- **A:** The header is not an identity boundary against a compromised local process able to issue metadata requests.
- **B:** Restricted permissions reduce the exposed identity's blast radius.
- **C:** Public addressing is unrelated to the host-local metadata path.
- **D:** This establishes a boundary around the untrusted converter.

- [About VM metadata](https://docs.cloud.google.com/compute/docs/metadata/overview) — Processes able to query metadata can read its values; sandbox untrusted processes.
- [Secret Manager best practices](https://docs.cloud.google.com/secret-manager/docs/best-practices) — Use secret-scoped access, controlled version rollout and API retrieval; disable before destruction.

Sources checked 2026-11-03. Original author ID: `DATA-017`.

---

<a id="q125"></a>
### PCSE200-125 — Choose ONE

A three-tier application places web, application and database VMs in separate subnets of one custom VPC. An inherited application-era allow rule permits all internal TCP traffic between all three subnets. The approved model permits web-to-application TCP/8443 and application-to-database TCP/5432, but forbids direct web-to-database access. The audit also requires explicit TLS between permitted peers, which is not yet configured. What is the best control change while preserving the three-subnet architecture? Choose ONE.

**A.** Keep the all-internal allow because different subnet addresses create an implicit isolation boundary between tiers.

**B.** Remove the broad permission, allow only the two intended tier flows with scoped sources and targets, and configure TLS between the permitted peers.

**C.** Retain the broad allow and rely on different subnet CIDR ranges plus separate instance groups to enforce the approved flow matrix.

**D.** Add the two narrow allow rules at lower priority while retaining the earlier broad allow as an availability fallback.

**Answer: B**

Subnets in the same VPC are routable, so their separation alone does not enforce the tier model. Narrow effective firewall permissions enforce the flow matrix, and explicit TLS supplies the required encrypted application channels.

**Guide mapping:** 2.2; Enforce explicit flows between N-tier workloads. **Editorial difficulty:** hard.

- **A:** Subnet placement does not neutralize the broad firewall permission.
- **B:** This establishes the approved network paths and the required encrypted channels.
- **C:** Address and instance-group separation does not override an effective broad internal allow.
- **D:** A matching broad allow still permits the prohibited flow.

**Service assumption/limitation:** The scenario concerns VM tiers; GKE Pod isolation would additionally require appropriate Kubernetes networking controls.

- [VPC firewall rules](https://docs.cloud.google.com/firewall/docs/firewalls) — VPC firewall decisions depend on rule priority, target and source scope; tracked connections are stateful.
- [Encryption from the load balancer to the backends](https://docs.cloud.google.com/load-balancing/docs/ssl-certificates/encryption-to-the-backends) — Explicit secure protocols supply auditable application encryption in addition to underlying network encryption.

Sources checked 2026-11-03. Original author ID: `NETWORK-027`.

---

<a id="q126"></a>
### PCSE200-126 — Choose TWO

A branch uses Private Google Access for on-premises hosts over Interconnect. API DNS resolves to the intended private VIP and requests enter the connected VPC through a region-A attachment. During a route-policy change, the preferred return route to the branch points through region B; the APIs become unreachable. The branch still requires private connectivity, and administrators want a precise validation checklist. Which TWO statements apply to this incident? Choose TWO.

**A.** The supported Google API destination must be routed through the hybrid connection; ordinary public API resolution is not a substitute for this configuration.

**B.** Enabling PGA on an unrelated VPC subnet guarantees hybrid return traffic independently of Cloud Router's selected routes.

**C.** Any return attachment in any region is equivalent because VPC networks are global, so asymmetric regional routing cannot explain the failure.

**D.** Return routing to the branch must use a tunnel or VLAN attachment in the request's originating region; correct the cross-region asymmetry.

**Answer: A, D**

Hybrid PGA requires appropriate special-VIP routing in both directions. The documented regional return-path restriction makes the cross-region asymmetry relevant even though the VPC is global.

**Guide mapping:** 2.3; Validate hybrid PGA request and return path requirements. **Editorial difficulty:** hard.

- **A:** This preserves the required special-VIP private access path.
- **B:** A subnet feature does not override the hybrid route selection.
- **C:** The hybrid PGA service has a specific regional return-path requirement.
- **D:** This directly repairs the observed route-policy regression.

- [Configure Private Google Access for on-premises hosts](https://docs.cloud.google.com/vpc/docs/configure-private-google-access-hybrid) — Hybrid PGA requires VIP-directed DNS and routing over VPN or Interconnect, including a regional return path.

Sources checked 2026-11-03. Original author ID: `NETWORK-044`.

---

<a id="q127"></a>
### PCSE200-127 — Choose ONE

A retailer's organization firewall policy denies new ingress TCP/3389 connections to all production VMs at priority 900. A project administrator adds a classic VPC firewall allow rule at priority 100 for the support subnet, but new RDP sessions still fail. The target VM and source range match both rules, and no earlier organizational exception exists. The security team approves only this support subnet as an exception. Which change implements that exception? Choose ONE.

**A.** Attach a regional network firewall policy containing the same support allow and remove the classic VPC allow.

**B.** Lower the numeric priority of the VPC allow rule to 1 so it outranks the organization policy rule.

**C.** Add an organizational allow exception for the approved source and targets with a higher priority than the organizational deny.

**D.** Change network policy enforcement to BEFORE_CLASSIC_FIREWALL so the existing classic allow is evaluated before organizational rules.

**Answer: C**

The organization-level terminal deny is reached before lower policy layers. A narrowly targeted exception in that policy must precede it; numerical priorities are not a single global ordering.

**Guide mapping:** 2.1; Troubleshoot hierarchical firewall decisions. **Editorial difficulty:** hard.

- **A:** A regional policy is evaluated too late to override the organizational denial.
- **B:** Classic-rule priority cannot override a terminal decision in an earlier hierarchical policy.
- **C:** A scoped, earlier organizational allow satisfies the approved exception.
- **D:** The enforcement-order setting rearranges classic and network policies, not their precedence over hierarchical policies.

- [Evaluation order for firewall policies and rules](https://docs.cloud.google.com/firewall/docs/firewall-policies-rule-eval-order) — Policy layers are evaluated in order; terminal actions stop evaluation, while goto_next delegates.

Sources checked 2026-11-03. Original author ID: `NETWORK-001`.

---

<a id="q128"></a>
### PCSE200-128 — Choose ONE

A company is onboarding dozens of projects monthly beneath a production folder. Security needs a centrally administered copy of selected audit and network logs, including logs from projects created later. Application teams must retain their existing project-level routing for troubleshooting. They must not receive administrative access to the central destination. A proposed design has each project owner create a new sink during onboarding, but two recent projects were missed. The organization permits a folder administrator to configure collection once. The central filter has been tested against sample events, and all required source categories are already generated before routing. Which design best removes the onboarding gap while preserving the required local behavior? Choose ONE.

**A.** Use a non-intercepting aggregated folder sink with child inclusion, a validated filter, and destination write permission for its writer identity.

**B.** Create a folder sink without child inclusion and rely on folder IAM inheritance to include project log entries.

**C.** Use an intercepting aggregated sink for every log and assume all existing child sinks will continue receiving matching entries.

**D.** Create a sink in the central project with a filter naming the production folder and no source-side collection.

**Answer: A**

An aggregated sink with child inclusion covers descendant projects, including future ones. Non-interception permits their own sinks to continue processing entries; IAM on the destination remains separate.

**Guide mapping:** 4.2; Centralize future project logs while preserving local operational copies. **Editorial difficulty:** hard.

- **A:** This centrally establishes collection while preserving project routing.
- **B:** IAM inheritance is not equivalent to aggregated sink child inclusion.
- **C:** Interception suppresses matching entries from most child sinks and conflicts with the local-routing requirement.
- **D:** A destination-project sink does not pull logs from other projects merely because its filter names them.

- [Collate and route organization- and folder-level logs](https://docs.cloud.google.com/logging/docs/export/aggregated_sinks) — Aggregated folder sinks can include child resources and can be non-intercepting.

Sources checked 2026-11-03. Original author ID: `OPS-021`.

---

<a id="q129"></a>
### PCSE200-129 — Choose ONE

A development tool in an internal-only VM must call a Google API that is reachable through private.googleapis.com but is not supported by VPC Service Controls. A separate sensitive-data workflow uses restricted.googleapis.com and must keep that tighter service reachability. The tool receives connection failures after administrators apply the restricted DNS mapping to every API name. The unsupported API is explicitly approved for the development environment. Which design conclusion is correct? Choose ONE.

**A.** Use an approved private.googleapis.com path for the development tool and preserve restricted reachability for the sensitive workflow.

**B.** Keep the restricted mapping and add a broader TCP/443 egress firewall allow to the same restricted VIP addresses.

**C.** Keep the restricted mapping and add more permissive perimeter ingress and egress rules for the already-approved development identity.

**D.** Add the unsupported API name to a service perimeter so restricted.googleapis.com begins serving it automatically.

**Answer: A**

The two VIP families have different service reachability. An unsupported API cannot be made available on the restricted VIP by IAM or a perimeter configuration.

**Guide mapping:** 2.3; Select the correct Google API VIP based on service support. **Editorial difficulty:** hard.

- **A:** This respects the approved development need without broadening the sensitive environment.
- **B:** The network path already reaches the VIP; its supported-service set is the problem.
- **C:** Perimeter exceptions do not make an unsupported API available on the restricted VIP.
- **D:** A perimeter cannot add unsupported service capability to the VIP.

**Service assumption/limitation:** Use separate network/DNS scope or another reviewed separation mechanism so the development exception does not create a sensitive-workload bypass.

- [Private access options for services](https://docs.cloud.google.com/vpc/docs/private-access-options) — PGA, PSC and private services access address different private-connectivity needs.
- [Set up private connectivity to Google APIs and services](https://docs.cloud.google.com/vpc-service-controls/docs/set-up-private-connectivity) — Restricted VIP routing uses the default internet gateway privately; DNS and hybrid custom advertisements are separate requirements.
- [Configure Private Google Access for on-premises hosts](https://docs.cloud.google.com/vpc/docs/configure-private-google-access-hybrid) — Hybrid PGA requires VIP-directed DNS and routing over VPN or Interconnect, including a regional return path.

Sources checked 2026-11-03. Original author ID: `NETWORK-036`.

---

<a id="q130"></a>
### PCSE200-130 — Choose ONE

A company has approved Preview access to Agent Gateway for agents hosted in Agent Runtime. A payroll agent uses a registered MCP server, and its identity can authenticate successfully. After policy enforcement is enabled, outbound calls are denied. The destination is in the correct registry and the target service accepts the intended credentials, but no matching egress access policy exists. Which change addresses the missing authorization while keeping destination access narrow? Choose ONE answer.

**A.** Grant the agent identity iap.resources.egressViaIAP through an explicit access policy scoped to the approved destination.

**B.** Grant the agent access to the MCP server's application API but leave gateway egress authorization absent.

**C.** Register the MCP server and grant the agent permission to list its registry metadata, without an egress access grant.

**D.** Grant egress access to the human deployer and retain the same ungranted agent principal.

**Answer: A**

Registration identifies a destination; an explicit access policy authorizes the agent to reach it. The managed gateway evaluates the agent identity and required egress permission.

**Guide mapping:** 3.3; Authorize Agent Gateway destinations explicitly. **Editorial difficulty:** hard.

- **A:** This supplies the missing destination-specific authorization.
- **B:** Target-service credentials cannot substitute for the gateway's independent access check.
- **C:** Directory visibility and a registry record do not authorize outbound destination access.
- **D:** The gateway evaluates the outbound agent identity, not the human who deployed it.

**Service assumption/limitation:** Preview availability is explicitly assumed; do not generalize the stated hosted-runtime support to every compute platform.

- [Agent Gateway for Runtime and Gemini Enterprise](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-managed-overview) — Destination access needs explicit IAM permission; registry registration alone is insufficient.

Sources checked 2026-11-03. Original author ID: `DATA-045`.

---

<a id="q131"></a>
### PCSE200-131 — Choose ONE

A security team removes the default route from an isolated VPC. Internal-only VMs retain Private Google Access, resolve approved Google API names to 199.36.153.4/30, and have a narrow TCP/443 egress allow, but API connections now time out. General internet access must remain unavailable. There is no VPN or appliance path for these API requests. The affected VMs carry only the application tag. Which route change directly restores only the intended restricted API connectivity? Choose ONE.

**A.** Restore 0.0.0.0/0 through default-internet-gateway and remove the egress restriction because PGA requires unrestricted internet routing.

**B.** Enable Private Google Access again and leave the route table without a route matching the restricted VIP.

**C.** Add a static route for 199.36.153.4/30 using default-internet-gateway as next hop; traffic to that VIP remains on Google's network.

**D.** Add the VIP route through default-internet-gateway but restrict its applicability to VMs tagged api-access.

**Answer: C**

Private API VIP traffic still requires the documented route. The next hop's name does not mean these destinations traverse the public internet; a narrow VIP route suffices here.

**Guide mapping:** 2.3; Retain a private Google API route after removing internet egress. **Editorial difficulty:** medium.

- **A:** The broader route and removal of filtering exceed the requirement.
- **B:** The subnet setting cannot replace the missing route.
- **C:** This restores the missing eligible route without restoring a general default route.
- **D:** A route tagged api-access does not apply to VMs carrying only application, so it does not restore the affected clients’ path.

- [Set up private connectivity to Google APIs and services](https://docs.cloud.google.com/vpc-service-controls/docs/set-up-private-connectivity) — Restricted VIP routing uses the default internet gateway privately; DNS and hybrid custom advertisements are separate requirements.
- [VPC routes and route applicability](https://docs.cloud.google.com/vpc/docs/routes) — Network tags can limit static-route applicability to matching VM instances; an unmatched tag leaves these clients without that route.

Sources checked 2026-11-03. Original author ID: `NETWORK-035`.

---

<a id="q132"></a>
### PCSE200-132 — Choose ONE

A development team enables Cloud NGFW TLS inspection for supported outbound HTTP/1.1 over TLS. The endpoint association references the intended TLS inspection policy, the matching rule enables TLS inspection, and the CA pool permissions are correct. Browser clients now report an unknown certificate authority for previously working public websites. Packet inspection shows certificates issued through the inspection CA hierarchy. These managed clients do not pin server certificates. What is the appropriate remediation? Choose ONE.

**A.** Import every destination website's public root certificate into the firewall's private-server trust configuration.

**B.** Distribute the inspection CA trust chain to the managed client trust stores and verify inspected sessions.

**C.** Distribute only the public website issuers' root certificates to client trust stores while leaving the inspection CA untrusted.

**D.** Replace the inspection profile with an ordinary TCP/443 allow and keep the decryption requirement in policy documentation.

**Answer: B**

The clients now validate certificates generated by the inspection service. They need to trust that issuer; trusting backend issuers on the firewall addresses the opposite side of the connection.

**Guide mapping:** 2.1; Establish client trust for Cloud NGFW TLS inspection. **Editorial difficulty:** hard.

- **A:** Server trust configuration does not establish client trust in the inspection issuer.
- **B:** Trusting the intended inspection hierarchy resolves this specific error without bypassing inspection.
- **C:** The intercepted session presents the inspection issuer's certificate, so public website roots alone do not fix client validation.
- **D:** This restores reachability by abandoning the required inspection.

- [Set up TLS inspection](https://docs.cloud.google.com/firewall/docs/setup-tls-inspection) — Clients must trust the inspection certificate chain; policy and rule configuration enable decryption.
- [TLS inspection overview](https://docs.cloud.google.com/firewall/docs/about-tls-inspection) — TLS inspection uses a CA pool, an endpoint association policy and dynamically issued server certificates.

Sources checked 2026-11-03. Original author ID: `NETWORK-006`.

---

<a id="q133"></a>
### PCSE200-133 — Choose ONE

Meridian Research has a legacy list organization policy that explicitly denies one value at the regulated folder. A temporary integration in one child project needs that value, and the control owner has approved a project-only exception. The policy administrator adds an allow rule at the project and selects Merge with parent. After propagation, the integration still fails. Other child projects must retain the denial. The administrator is authorized to replace the project policy and has a reviewed list of every restriction that must remain effective there. Which action best implements the approved exception without broadening it to the rest of the folder? Choose ONE.

**A.** Keep Merge with parent and place the project allow value before the inherited deny value in the configuration.

**B.** Grant the integration service account a broader resource role so that its IAM authorization overrides the organization-policy denial.

**C.** Remove the denial from the folder and add the integration project's value to the folder allow list.

**D.** Replace the inherited policy at the exception project with an explicit reviewed policy, then verify its effective policy and the unchanged sibling policies.

**Answer: D**

In a merged legacy list policy, deny wins. A reviewed project replacement can implement the stated exception without modifying sibling policy.

**Guide mapping:** 5.1; Choose a narrowly scoped legacy list-policy exception and verify inheritance. **Editorial difficulty:** hard.

- **A:** List order does not make an allow override a merged deny.
- **B:** IAM authorization does not override an organization-policy restriction.
- **C:** This changes the boundary for sibling projects.
- **D:** Replacement fits the approved scope; verification guards against accidentally dropping other restrictions.

**Service assumption/limitation:** This scenario explicitly concerns a legacy list constraint supporting the stated override; do not generalize merge semantics to every managed constraint.

- [Hierarchy evaluation](https://docs.cloud.google.com/organization-policy/hierarchy-evaluation) — Legacy list-policy merging reconciles inherited policies, with deny values taking precedence; child replacement differs from merging.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-010`.

---

<a id="q134"></a>
### PCSE200-134 — Choose TWO

A retailer is preparing support tickets for a model-training experiment. The experiment needs issue categories and technical descriptions but not customer names or contact details. The training job should read only an approved export, while the original ticket archive remains available to a separate support system. The team wants controls that reduce both unnecessary identifying content and the impact of accidental access from training code. Which two measures directly satisfy these requirements? Choose TWO answers.

**A.** Grant the training identity raw-archive access and rely exclusively on an instruction not to read personal information.

**B.** Keep every identifier in the export but rotate its storage CMEK before each training run.

**C.** Grant the training runtime identity access only to the approved export and required output location.

**D.** Inspect and redact unnecessary identifiers in the approved training export, validating retained utility.

**Answer: C, D**

Data minimization reduces sensitive content presented to training. A narrowly scoped runtime identity prevents training code from bypassing that export by reading the raw archive.

**Guide mapping:** 3.3; Minimize sensitive training inputs and runtime data reach. **Editorial difficulty:** hard.

- **A:** A natural-language instruction does not constrain storage API authorization.
- **B:** At-rest encryption remains transparent to authorized training readers.
- **C:** Resource-scoped permissions enforce the intended training-data boundary.
- **D:** Transformation reduces unnecessary personal data while preserving task-relevant fields.

- [Transformation reference](https://docs.cloud.google.com/sensitive-data-protection/docs/transformations-reference) — Redaction, bucketing and tokenization have different utility and reversibility.
- [Use a custom service account](https://docs.cloud.google.com/gemini-enterprise-agent-platform/machine-learning/general/custom-service-account) — Custom training runtime access uses a specified service account and ADC.

Sources checked 2026-11-03. Original author ID: `DATA-039`.

---

<a id="q135"></a>
### PCSE200-135 — Choose TWO

An application encrypts small records directly with a symmetric Cloud KMS key. Its owner creates a new primary version, verifies that new writes use that version, and proposes destroying the previous version that afternoon. Existing records still contain ciphertext produced with the previous version, and no re-encryption process has run. Quarterly recovery exercises also restore older backups containing that ciphertext. The retention schedule requires those backups to remain usable, and the security team has approved a staged retirement rather than immediate irreversible removal. A successful test of new writes is therefore insufficient evidence that old material is no longer needed. Which TWO steps are required before the team can reasonably consider destroying the previous version under these constraints? Choose TWO answers.

**A.** Re-encrypt active records only and retain historical ciphertext backups without preserving their key dependencies.

**B.** Re-encrypt retained ciphertext under the replacement version and account for backups or other dependent copies.

**C.** Validate remaining dependencies and use a reversible disable-and-observe phase before destruction.

**D.** Assume changing the primary version also updates every stored ciphertext's key reference.

**Answer: B, C**

Rotation affects future encryption; it does not rewrite existing ciphertext. Inventory, migration and a reversible validation phase reduce the risk of permanently losing historical data.

**Guide mapping:** 3.2; Retire old key versions after dependency migration. **Editorial difficulty:** hard.

- **A:** Quarterly restore requirements include backups; migrating only current records does not make their historical ciphertext independent of the old key.
- **B:** Historical and backup dependencies must be migrated or retained with usable keys.
- **C:** A monitored disable phase can expose overlooked dependencies before irreversible loss.
- **D:** Primary-version selection does not transform existing ciphertext.

- [Key rotation](https://docs.cloud.google.com/kms/docs/key-rotation) — Rotation creates versions; it does not automatically re-encrypt data or disable previous versions.
- [Destroy and restore key versions](https://docs.cloud.google.com/kms/docs/destroy-restore) — Scheduled destruction is recoverable before expiry; disable and dependency review precede destruction.

Sources checked 2026-11-03. Original author ID: `DATA-023`.

---

<a id="q136"></a>
### PCSE200-136 — Choose ONE

A migration service uses automatic IAM authentication through the Cloud SQL Auth Proxy to reach PostgreSQL. It can establish a database session but receives permission denied when selecting a protected reporting table. The service should read only that table and must not administer the instance or modify data. Its network path, IAM login permissions, and database-user registration are confirmed. Which remaining layer should the engineer configure to satisfy the requirement? Choose ONE answer.

**A.** Grant the database user the necessary schema usage and table SELECT privileges in PostgreSQL.

**B.** Grant the service Cloud SQL Instance User at project scope and leave PostgreSQL object privileges unchanged.

**C.** Grant CONNECT on the database but leave schema and table privileges unchanged.

**D.** Grant the service Cloud SQL Client and route all queries through the same authenticated proxy.

**Answer: A**

IAM database authentication establishes identity; database object privileges still govern SQL operations. The successful session isolates the problem from connection and authentication controls.

**Guide mapping:** 3.1; Separate Cloud SQL connection permission from database grants. **Editorial difficulty:** hard.

- **A:** Narrow SQL privileges match the exact read-only requirement.
- **B:** IAM login is already successful; repeating or broadening it does not grant SELECT on the table.
- **C:** CONNECT alone allows a database session, not SELECT on a protected table.
- **D:** The proxy is already establishing sessions; connection authorization is separate from SQL object access.

**Service assumption/limitation:** Database privilege behavior is PostgreSQL-specific; Cloud SQL IAM authentication is not a substitute for database authorization.

- [IAM authentication for Cloud SQL for PostgreSQL](https://docs.cloud.google.com/sql/docs/postgres/iam-authentication) — Connectors automate refresh of one-hour IAM database authentication tokens over encrypted connections.
- [Manage users with IAM database authentication](https://docs.cloud.google.com/sql/docs/postgres/add-manage-iam-users) — IAM-authenticated database users still require database privileges, including SELECT grants.

Sources checked 2026-11-03. Original author ID: `DATA-012`.

---

<a id="q137"></a>
### PCSE200-137 — Choose ONE

A financial services company changes the LDAP search base used by its established GCDS job. The first simulation now proposes suspending hundreds of Google users even though HR reports no departures. The company's administrators must preserve existing access while identifying whether the new filter is correct. The directory remains authoritative, and manually maintaining a separate cloud membership list would introduce drift. What is the best next step? Choose ONE.

**A.** Run the synchronization immediately because the directory is authoritative, then recover affected users.

**B.** Raise the suspension threshold and apply the changed LDAP scope before investigating the missing source records.

**C.** Apply only additions indefinitely while retaining the unverified search base and stop reconciling departures.

**D.** Stop the apply run, inspect search results and exclusions, correct the scope, and re-simulate before applying.

**Answer: D**

A reconciliation result is only as valid as its source scope. A sudden mass-removal proposal after a filter change warrants correcting and validating that scope before applying destructive lifecycle actions.

**Guide mapping:** 1.1; Validate directory reconciliation before broad changes. **Editorial difficulty:** hard.

- **A:** Authority does not make a malformed search filter trustworthy.
- **B:** A threshold change does not establish that the new source filter represents the intended employee population.
- **C:** This avoids the immediate mass suspension but retains a broken scope and unmanaged lifecycle drift.
- **D:** Correct: simulation and scope review preserve accounts while diagnosing the discrepancy.

- [Troubleshoot common GCDS issues](https://knowledge.workspace.google.com/admin/users/troubleshoot-common-gcds-issues) — Simulate synchronization and reproduce LDAP query conditions before applying configuration changes.
- [About Google Cloud Directory Sync](https://knowledge.workspace.google.com/admin/users/about-google-cloud-directory-sync) — GCDS synchronizes Google directory users and groups from LDAP rather than authenticating browser sign-ins.

Sources checked 2026-11-03. Original author ID: `ACCESS-007`.

---

<a id="q138"></a>
### PCSE200-138 — Choose ONE

A security team has a working Packet Mirroring deployment for Compute Engine VMs in one region. It adds a second application deployment in another region and wants identical traffic analysis. The existing central collector is behind an internal passthrough Network Load Balancer in the first region. Budget approval allows a second collector, but the team would prefer to reuse the first if supported. They must capture packets from both regional VM groups without moving production workloads. The regional application groups have equivalent tagging, but their source instances remain in their respective regions. Analysts need packet payloads, rather than only centrally exported flow summaries. Which design meets the mirroring placement requirements? Choose ONE.

**A.** Create regional mirroring and collector infrastructure for each region, then consolidate the resulting analysis centrally.

**B.** Put the collector behind a global external Application Load Balancer and keep a single mirroring policy.

**C.** Enable global access on the existing collector forwarding rule and assume this changes Packet Mirroring source-region constraints.

**D.** Extend the existing policy to the remote VMs because one global VPC makes all mirroring collectors region independent.

**Answer: A**

Packet Mirroring is regional: mirrored sources and collector requirements cannot be bypassed merely because the VPC is global. Separate regional collection can feed central analysis.

**Guide mapping:** 4.2; Respect Packet Mirroring regional topology. **Editorial difficulty:** hard.

- **A:** Regional collection respects placement while still allowing centralized findings.
- **B:** An external application load balancer is not the specified mirroring collector topology.
- **C:** Global reachability does not redefine the Packet Mirroring policy region.
- **D:** Global VPC scope does not remove regional mirroring constraints.

- [Packet Mirroring](https://docs.cloud.google.com/vpc/docs/packet-mirroring) — Mirrored sources and the collector load balancer must satisfy Packet Mirroring regional placement requirements.

Sources checked 2026-11-03. Original author ID: `OPS-018`.

---

<a id="q139"></a>
### PCSE200-139 — Choose ONE

A hub VPC forwards corp.example queries to an on-premises DNS server over healthy HA VPN tunnels. Packet capture at the server shows queries sourced from 35.199.192.0/19, which the current firewall drops because it allows only the hub subnet. The router also lacks a return path for that forwarding range through the hybrid connection. A spoke VPC needs the same internal names; its application routes already use VPC peering to reach approved hub services, but this has not made the hub’s DNS resolution configuration available to spoke clients. The enterprise wants to maintain one controlled outbound DNS-forwarding path in the hub, rather than separate forwarding infrastructure in every spoke. Both UDP and TCP DNS must work. Which design resolves the source, return-routing and spoke-resolution requirements? Choose ONE.

**A.** Change the forwarding target to a spoke VM address and rely on VPC peering to propagate the hub's private DNS zones automatically.

**B.** Allow TCP and UDP/53 from the documented forwarding range, route replies back through the hub, and use DNS peering from spoke to hub.

**C.** Create public DNS records for the internal names and route replies for 35.199.192.0/19 through the on-premises internet gateway.

**D.** Allow UDP/53 only from the hub subnet, and configure independent forwarding zones in each spoke to reuse the peering route.

**Answer: B**

Forwarded queries use the documented Google source range and need a matching hybrid return route. DNS peering lets spokes use the hub's resolution context without unsupported direct forwarding across VPC peering.

**Guide mapping:** 2.1; Troubleshoot secure hybrid DNS forwarding. **Editorial difficulty:** hard.

- **A:** VPC peering does not automatically share private-zone visibility.
- **B:** This fixes firewall, return routing and centralized resolution.
- **C:** Public records violate the internal design and the internet path is not the required return route.
- **D:** The observed sources are not the hub subnet, and independent cross-peering forwarding is not the supported design.

- [Best practices for Cloud DNS](https://docs.cloud.google.com/dns/docs/best-practices) — On-premises forwarding needs DNS firewall and return routes for 35.199.192.0/19; DNS peering centralizes forwarding.

Sources checked 2026-11-03. Original author ID: `NETWORK-019`.

---

<a id="q140"></a>
### PCSE200-140 — Choose ONE

A company sets a resource-location organization policy on a folder to restrict new supported resources to approved locations. It then discovers a regional disk created earlier in a location that is now disallowed. The governance team needs an accurate migration plan rather than an assumption that policy enforcement moved or deleted the disk. What should the team conclude and do? Choose ONE.

**A.** Add a project-level exception permanently and classify the existing disk as compliant without inventory or migration review.

**B.** Export a location-compliance inventory and treat its completion as evidence that existing data has been migrated.

**C.** Inventory existing resources but defer preventive enforcement until the last historical resource has been migrated.

**D.** Keep the preventive policy and separately inventory and remediate existing resources according to a migration plan.

**Answer: D**

The documented resource-location example is not retroactive. A preventive policy can govern new supported creation while existing nonconforming resources require separate remediation.

**Guide mapping:** 1.5; Understand preventive resource-location policy limits. **Editorial difficulty:** medium.

- **A:** An exception changes the enforced boundary; it does not establish that the existing location meets the approved requirement.
- **B:** Assessment records a condition; it does not move the disk or establish successful migration.
- **C:** Inventory is useful, but deferring the approved preventive control unnecessarily permits additional nonconforming creation during migration.
- **D:** Correct: it distinguishes prevention from migration.

**Service assumption/limitation:** Location-constraint coverage and operation behavior vary by service; this question uses the documented existing regional-disk case.

- [Quickstart: Enforce an organization policy](https://docs.cloud.google.com/organization-policy/quickstart) — A resource-location policy blocks noncompliant new creation but does not relocate existing resources.

Sources checked 2026-11-03. Original author ID: `ACCESS-049`.

---

<a id="q141"></a>
### PCSE200-141 — Choose ONE

A manufacturing group retains Active Directory as the authoritative employee directory and its existing SAML identity provider for authentication. Employees need managed Google accounts for Workspace as well as Google Cloud. After a pilot imports users and groups with GCDS, new users exist but still encounter Google password sign-in. The team wants automated directory updates and corporate authentication without moving passwords into its provisioning script. Which design best satisfies these requirements? Choose ONE.

**A.** Replace GCDS with Workforce Identity Federation and use its identities for the employees' existing Workspace mailboxes.

**B.** Keep GCDS and synchronize Google passwords, while retaining Google as the browser authentication authority.

**C.** Configure SAML SSO but discontinue directory provisioning once the first employee group can sign in.

**D.** Run GCDS for directory provisioning and configure a third-party SAML SSO profile for the managed users.

**Answer: D**

Provisioning an account and authenticating its holder are separate operations. GCDS supplies directory synchronization; the SSO profile delegates the managed users' sign-in to the IdP.

**Guide mapping:** 1.1; Combine directory synchronization with third-party SSO. **Editorial difficulty:** hard.

- **A:** Workforce federation is useful for Cloud workforce access, but does not replace the required managed Workspace accounts.
- **B:** Password synchronization is a different design; it does not delegate browser authentication to the required corporate IdP.
- **C:** SSO does not maintain the lifecycle and group changes of the required managed accounts.
- **D:** Correct: it addresses both directory state and browser authentication.

- [About Google Cloud Directory Sync](https://knowledge.workspace.google.com/admin/users/about-google-cloud-directory-sync) — GCDS synchronizes Google directory users and groups from LDAP rather than authenticating browser sign-ins.
- [Best practices for federating Google Cloud with an external identity provider](https://docs.cloud.google.com/architecture/identity/best-practices-for-federating) — Provisioning and SSO are separate; maintain protected super administrator access independent of the external IdP.

Sources checked 2026-11-03. Original author ID: `ACCESS-001`.

---

<a id="q142"></a>
### PCSE200-142 — Choose ONE

A deployment controller reads a VM guest attribute named security_scan_passed and grants the VM's service account access to a production dataset when the value is true. An application developer discovers that an unprivileged process inside the VM can update that attribute. The controller must retain useful boot-status reporting, but a compromised application must not be able to authorize its own access. Which correction best separates these trust levels? Choose ONE answer.

**A.** Enable OS Login so only root can write the guest attribute.

**B.** Keep guest attributes for status and base authorization on independently verified scan evidence from a trusted principal.

**C.** Use a less predictable guest-attribute namespace for the authorization value.

**D.** Sign the VM's API requests using its existing broadly privileged service account.

**Answer: B**

Guest attributes are writable by applications and users inside the VM and are not an authenticated application-authorization channel. Independent evidence prevents a workload from approving itself.

**Guide mapping:** 3.1; Treat guest attributes as untrusted status data. **Editorial difficulty:** hard.

- **A:** OS Login governs SSH access, not guest-attribute write authorization.
- **B:** This retains status reporting while removing an untrusted authorization input.
- **C:** Obscurity does not change the documented write capability.
- **D:** The compromised workload already controls the identity that would make the assertion.

- [Setting and querying guest attributes](https://docs.cloud.google.com/compute/docs/metadata/manage-guest-attributes) — Any process in a VM can write guest attributes; they are unsuitable as authenticated security assertions.

Sources checked 2026-11-03. Original author ID: `DATA-016`.

---

<a id="q143"></a>
### PCSE200-143 — Choose ONE

A team removes an analyst's bucket IAM binding, yet the analyst can still download a subset of old Cloud Storage objects. Investigation finds direct object ACL grants from a legacy uploader. Future authorization must be centrally managed through IAM, and supported clients no longer depend on ACL operations. The team can migrate any remaining legitimate ACL-only readers before changing the bucket. Which action addresses the demonstrated access path? Choose ONE answer.

**A.** Enable public access prevention and leave authenticated object ACL grants unchanged.

**B.** Replace the bucket's default object ACL and rely on that replacement to remove old per-object grants.

**C.** Enable uniform bucket-level access after migrating legitimate ACL grants to IAM.

**D.** Remove the analyst from project-level Storage Object Viewer and retain the existing object ACL model.

**Answer: C**

Legacy ACLs and IAM independently grant access. Uniform bucket-level access disables ACL authorization, so the migrated IAM policy becomes the access mechanism.

**Guide mapping:** 3.1; Eliminate unintended ACL access to Cloud Storage. **Editorial difficulty:** medium.

- **A:** Public access prevention targets public principals, not all direct user ACL grants.
- **B:** Default ACL changes govern new objects rather than removing existing object ACL grants.
- **C:** This removes the specific independent authorization path.
- **D:** Project IAM cleanup cannot remove an independent direct object ACL grant.

- [Uniform bucket-level access](https://docs.cloud.google.com/storage/docs/uniform-bucket-level-access) — IAM and ACLs grant access independently unless uniform access disables ACLs.
- [Public access prevention](https://docs.cloud.google.com/storage/docs/public-access-prevention) — Public access prevention restricts public principals but does not block signed URLs.
- [Cloud Storage access control lists](https://docs.cloud.google.com/storage/docs/access-control/lists) — Default object ACLs apply to newly created objects rather than changing existing object ACLs.

Sources checked 2026-11-03. Original author ID: `DATA-009`.

---

<a id="q144"></a>
### PCSE200-144 — Choose ONE

A GKE application passed its vulnerability gate at deployment. Two weeks later, new vulnerability intelligence identifies a severe issue in its running image. The organization accepts the Preview status of Binary Authorization continuous validation with check-based platform policies. It wants recurring detection and a ticket for remediation, while operations must retain control of when Pods are replaced. Which design fits these requirements? Choose ONE.

**A.** Enable Artifact Analysis on the registry and send every new image occurrence to operations without checking which images run in the cluster.

**B.** Enable admission enforcement alone and wait for it to evict existing Pods when the image becomes noncompliant.

**C.** Run the vulnerability gate only when the application release pipeline builds a new image, keeping admission enforcement enabled.

**D.** Enable Artifact Analysis scanning and a continuous-validation vulnerability check, then route violations into the response workflow.

**Answer: D**

Continuous validation can evaluate running Pod images against vulnerability checks and log violations. It does not terminate running Pods, so the response workflow must own remediation.

**Guide mapping:** 4.1; Monitor new vulnerabilities after admission without assuming eviction. **Editorial difficulty:** medium.

- **A:** Registry findings alone do not provide the requested recurring running-Pod policy evaluation and workload association.
- **B:** Admission enforcement does not supply recurring eviction of existing workloads.
- **C:** This checks future builds but leaves unchanged running images unassessed against newly disclosed vulnerabilities.
- **D:** This combines current vulnerability evidence, recurring monitoring, and deliberate remediation.

**Service assumption/limitation:** Check-based continuous validation was documented as Preview when checked; the scenario explicitly accepts this.

- [Continuous validation overview](https://docs.cloud.google.com/binary-authorization/docs/overview-cv) — CV vulnerability checks use Artifact Analysis, report running-Pod violations, and do not terminate Pods.

Sources checked 2026-11-03. Original author ID: `OPS-010`.

---

<a id="q145"></a>
### PCSE200-145 — Choose ONE

Harbor Tickets stores cardholder data in one project. A separate security project receives its audit logs, and a deployment service account in a tooling project can replace the payment application's image and change its runtime identity. Neither supporting project stores cardholder payloads. Management proposes assessing only the payment project, while keeping the supporting projects under the general corporate baseline. Which scope recommendation best addresses the described dependencies? Choose ONE.

**A.** Include the payment project only, with the log and deployment projects listed as provider-managed dependencies.

**B.** Include all projects in the billing account because a shared invoice makes them one technical security boundary.

**C.** Include relevant logging, deployment and administrative components that secure or can affect the payment environment, documenting justified boundaries for unrelated resources.

**D.** Include the payment project and log bucket, but exclude the deployment identity because it handles only image references.

**Answer: C**

Scope follows relevant security and administrative dependencies, not only payload storage or billing membership.

**Guide mapping:** 5.1; Scope security and administrative dependencies alongside payment data. **Editorial difficulty:** hard.

- **A:** Those supporting components are customer-controlled, despite using managed services.
- **B:** Billing association alone does not establish the technical dependencies described.
- **C:** This includes the stated dependencies without assuming every unrelated resource is automatically in scope.
- **D:** The deployment identity can change application execution and must be considered.

**Service assumption/limitation:** This is technical scoping practice, not a substitute for the organization's assessor determining its PCI DSS scope.

- [PCI DSS on Google Cloud](https://cloud.google.com/security/compliance/pci-dss) — Scope includes systems securing and logging the cardholder environment; provider certification does not establish application compliance.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-004`.

---

<a id="q146"></a>
### PCSE200-146 — Choose TWO

A logistics company wants Cloud NGFW to block matching threat signatures in cleartext application traffic from a VM group in one zone. It has already created a threat-prevention security profile and security profile group, and the VPC MTU is supported. There is no earlier terminal firewall decision. The team has created no inspection endpoint or inspection rule yet. Which TWO steps complete this supported inline-inspection design? Choose TWO.

**A.** Create a firewall endpoint only in a neighboring zone and associate it with the VPC, relying on regional routing to inspect this zone.

**B.** Create a rule with the inspection action and correct profile group in a global network firewall policy, but leave that policy unassociated with the workloads’ VPC.

**C.** Add a matching rule in an associated global network firewall policy that applies the security profile group.

**D.** Create a firewall endpoint in the workloads' zone and associate that endpoint with the workloads' VPC.

**Answer: C, D**

Profiles describe inspection behavior but do not put traffic through inspection. An associated zonal endpoint and a matching supported policy action establish the enforcement path.

**Guide mapping:** 2.1; Deploy inline layer-7 intrusion prevention. **Editorial difficulty:** hard.

- **A:** The inspection endpoint must be in the workloads' zone; association alone does not make another zone's endpoint suitable.
- **B:** A real inspection rule in an unassociated policy does not establish enforcement for these workloads.
- **C:** apply_security_profile_group directs matching traffic to inspection.
- **D:** The endpoint must be available to the workload network and zone.

- [Configure intrusion detection and prevention service](https://docs.cloud.google.com/firewall/docs/configure-intrusion-prevention) — Inspection requires a profile group, zonal endpoint association and a matching apply_security_profile_group rule.

Sources checked 2026-11-03. Original author ID: `NETWORK-005`.

---

<a id="q147"></a>
### PCSE200-147 — Choose ONE

A support engineer reports that one service account cannot perform a particular API operation on a known resource. Another service account succeeds with the same request. The security team wants to understand the relevant IAM decision before changing roles, including inherited grants and applicable deny policies supported by the diagnostic tool. They know the failing principal, exact permission, and full resource name. Which investigation should they start with? Choose ONE.

**A.** Generate role recommendations for every account and apply all suggested reductions.

**B.** Run Policy Troubleshooter for that principal, permission, and resource, then review the evaluated policies.

**C.** Use Policy Simulator with an arbitrary larger role and immediately deploy its policy.

**D.** List only the resource's local IAM bindings and ignore its ancestor policies.

**Answer: B**

Policy Troubleshooter is intended to explain a specific access decision. The supplied principal, permission and resource are the relevant inputs; policy visibility and supported features affect completeness.

**Guide mapping:** 1.4; Diagnose a specific IAM access failure. **Editorial difficulty:** medium.

- **A:** Recommendations target excess access, not this immediate access explanation.
- **B:** Correct: it answers the stated why-was-this-denied question.
- **C:** A speculative grant is not a diagnosis.
- **D:** Inherited controls can determine the result, so local-only inspection is incomplete.

**Service assumption/limitation:** Interpret unknown or unsupported diagnostic results as incomplete evidence.

- [Troubleshoot IAM permissions](https://docs.cloud.google.com/policy-intelligence/docs/troubleshoot-access) — Policy Troubleshooter explains a principal-permission-resource access decision.

Sources checked 2026-11-03. Original author ID: `ACCESS-038`.

---

<a id="q148"></a>
### PCSE200-148 — Choose TWO

A customer-support team needs every error record from one application, including timestamps and diagnostic codes. Some of those same records contain jsonPayload.customer_email. The privacy team permits investigators to read that field but forbids support from seeing it. Removing records that contain email would hide the errors support must diagnose. Both groups query the same dedicated Cloud Logging bucket through Logs Explorer, with no alternate exports or broader access paths. Support must not infer emails through direct field queries either. The application emits a dedicated log name that the view can select without inspecting email contents. Which two controls together implement the requirement? Choose TWO.

**A.** Grant each group access to an appropriately filtered application log view so support still receives the needed records.

**B.** Give support Logs Field Accessor and ask them to collapse the sensitive field in the results panel.

**C.** Configure customer_email as a restricted field and grant field access only to the investigators who also have log access.

**D.** Exclude every record containing customer_email from the bucket at the sink so neither group can accidentally query it.

**Answer: A, C**

Log views select records; field-level controls hide selected fields within those records. Investigators need both log access and the additional field permission.

**Guide mapping:** 4.2; Combine record-level and field-level log controls. **Editorial difficulty:** hard.

- **A:** This controls the application record set without discarding necessary errors.
- **B:** Field access would authorize the disclosure; a UI convention is not a control.
- **C:** This enforces the sensitive-field distinction while retaining the diagnostic record.
- **D:** Exclusion removes the needed error records and investigator evidence.

- [Configure field-level access](https://docs.cloud.google.com/logging/docs/field-level-acl) — Restricted fields are omitted without fieldAccessor, which must accompany log access.
- [Configure log views on a log bucket](https://docs.cloud.google.com/logging/docs/logs-views) — Log views allow access to selected subsets of records.

Sources checked 2026-11-03. Original author ID: `OPS-024`.

---

<a id="q149"></a>
### PCSE200-149 — Choose TWO

A retailer has one super administrator account, shared by two engineers and used for email. Its external identity provider recently suffered an outage, delaying an urgent directory recovery. Management requires individual attribution, reduced exposure to email phishing, and a recovery path when either an administrator or the external IdP is unavailable. Routine support staff should retain delegated privileges. Which TWO changes best address the administrator design? Choose TWO.

**A.** Give each administrator a separate daily account and protect privileged accounts with phishing-resistant security keys and recovery arrangements.

**B.** Create individually named super administrator accounts but use each account for its owner's daily mail and browsing.

**C.** Create separate privileged accounts whose only recovery path requires the same external IdP to be available.

**D.** Provide separate named super administrator accounts to designated individuals and retain independent, tested emergency sign-in.

**Answer: A, D**

Use identifiable privileged accounts, more than one designated administrator, independent recovery, and separate daily identities. Strong 2SV reduces the chance that a stolen password becomes an administrative compromise.

**Guide mapping:** 1.1; Protect administrator continuity and attribution. **Editorial difficulty:** hard.

- **A:** Correct: separate daily accounts and security keys reduce privileged exposure.
- **B:** This improves attribution but retains the daily phishing exposure and does not establish independent recovery.
- **C:** Separate identities help attribution, but the recovery path still depends on the failed IdP.
- **D:** Correct: distinct administrators and independent recovery address single points of failure.

- [Security best practices for administrator accounts](https://knowledge.workspace.google.com/admin/users/security-best-practices-for-administrator-accounts) — Use individually attributable admin accounts, separate daily accounts, strong 2SV and multiple super administrators.
- [Best practices for federating Google Cloud with an external identity provider](https://docs.cloud.google.com/architecture/identity/best-practices-for-federating) — Provisioning and SSO are separate; maintain protected super administrator access independent of the external IdP.

Sources checked 2026-11-03. Original author ID: `ACCESS-002`.

---

<a id="q150"></a>
### PCSE200-150 — Choose TWO

A VM without an external IPv4 address must read Cloud Storage through its normal Google API client. It has no Cloud NAT service. DNS resolves the API to the restricted VIP, IAM permissions are valid, and the VPC already has an eligible route through the default internet gateway. Private Google Access is disabled on the VM subnet, and an explicit egress deny currently covers all TCP traffic. Which TWO targeted changes enable the required API path without general internet access? Choose TWO.

**A.** Add a narrow ingress TCP/443 allow from the API VIP addresses while retaining the existing egress deny.

**B.** Add an earlier scoped egress allow for TCP/443 to the selected Google API VIP addresses.

**C.** Assign an external address to the VM and leave the egress deny unchanged.

**D.** Enable Private Google Access on the subnet containing the VM's network interface.

**Answer: B, D**

PGA supplies API connectivity for an eligible internal-only client, but it does not bypass egress filtering. The existing route and correct DNS complete the other stated prerequisites.

**Guide mapping:** 2.3; Configure PGA for internal-only VM clients. **Editorial difficulty:** medium.

- **A:** An ingress allowance does not permit the VM’s denied outbound connection initiation; PGA also remains a separate prerequisite.
- **B:** The specific allow permits the API connection before the broad deny.
- **C:** An external IP violates the intended architecture and does not bypass the explicit deny.
- **D:** This enables the subnet capability needed by the internal-only VM.

- [Private Google Access](https://docs.cloud.google.com/vpc/docs/private-google-access) — PGA is a subnet setting for eligible clients without external IPs and requires appropriate network configuration.
- [Set up private connectivity to Google APIs and services](https://docs.cloud.google.com/vpc-service-controls/docs/set-up-private-connectivity) — Restricted VIP routing uses the default internet gateway privately; DNS and hybrid custom advertisements are separate requirements.

Sources checked 2026-11-03. Original author ID: `NETWORK-033`.

---
## Set 4

<a id="q151"></a>
### PCSE200-151 — Choose TWO

A company uses a newer third-party SAML SSO profile that supports two verification certificates. Its current IdP signing certificate expires next month. Google currently trusts only that certificate, and the IdP signs every response with its corresponding private key. The identity team can publish the replacement public certificate before changing the active signer, and it has a pilot group that can verify real sign-ins during the change window. Critical employees must retain access throughout the rotation; a coordinated instant replacement with no overlap is unacceptable. The IdP private keys must remain with the IdP, and the team must eventually remove obsolete trust after confirming the new signer works. Existing managed-account provisioning and SAML subject mappings are correct. Which TWO steps should the rotation plan include? Choose TWO.

**A.** Replace the old public verification certificate with the new one before changing the IdP's active signing key.

**B.** Verify sign-ins using the new signature and remove the old verification certificate after the overlap is complete.

**C.** Add the new public verification certificate to the profile before switching the IdP's signing key.

**D.** Keep the old certificate as the only trusted certificate after the IdP starts using its new signing key.

**Answer: B, C**

Google verifies the IdP's signature with a public certificate. The two-certificate profile supports an overlap in trust while the IdP changes signing keys.

**Guide mapping:** 1.3; Roll SAML verification certificates without breaking sign-in. **Editorial difficulty:** hard.

- **A:** This removes the old trust before the IdP changes signatures, defeating the required overlap.
- **B:** Correct: test the new path before retiring the old trust.
- **C:** Correct: establish trust for the new signing key before switching.
- **D:** The new signature will not validate against an unrelated old key.

**Service assumption/limitation:** The legacy organization-wide SSO configuration has different certificate-capacity behavior.

- [Technical overview of SAML-based SSO](https://knowledge.workspace.google.com/admin/apps/technical-overview-of-saml-based-sso) — SSO verifies IdP signatures using uploaded public certificates; new SAML profiles support two certificates for rotation.

Sources checked 2026-11-03. Original author ID: `ACCESS-025`.

---

<a id="q152"></a>
### PCSE200-152 — Choose ONE

A software vendor hosts an internal service in its own VPC. A customer wants private access to that single supported service, but both companies use overlapping RFC1918 subnet ranges and will not renumber. They also reject broad network connectivity between all workloads. The vendor can publish the service through a supported load balancer and service attachment, and the customer can allocate an endpoint in its own network. Which design is most suitable? Choose ONE.

**A.** Attach both organizations' existing networks to one Shared VPC without changing their subnet addresses or administrative boundaries.

**B.** Use an unrestricted VPN that advertises both overlapping subnets and rely on destination DNS names to select the correct network.

**C.** Publish the service with Private Service Connect and create an accepted consumer endpoint using the customer's own internal address.

**D.** Create VPC Network Peering and enable import of custom routes so overlapping subnet routes can coexist.

**Answer: C**

PSC supplies service-oriented access rather than full subnet connectivity. It is suitable for independently addressed producer and consumer networks without requiring direct peering of overlapping ranges.

**Guide mapping:** 2.2; Expose one private service without broad network merging. **Editorial difficulty:** hard.

- **A:** Shared VPC does not merge arbitrary existing networks across these boundaries.
- **B:** Ambiguous overlapping routes are not resolved by DNS names once packets are addressed.
- **C:** The endpoint exposes the required service while preserving network separation.
- **D:** Peering does not permit the conflicting subnet routes.

- [Private Service Connect](https://docs.cloud.google.com/vpc/docs/private-service-connect) — PSC provides service-specific private endpoints without full VPC peering.
- [VPC Network Peering](https://docs.cloud.google.com/vpc/docs/vpc-peering) — Peering is nontransitive, does not exchange firewall rules, and requires nonoverlapping IPv4 subnet ranges.
- [Designing networks for migrating enterprise workloads: Architectural approaches](https://docs.cloud.google.com/architecture/network-architecture) — Layer-4 PSC service publication supports overlapping consumer and producer addresses.

Sources checked 2026-11-03. Original author ID: `NETWORK-026`.

---

<a id="q153"></a>
### PCSE200-153 — Choose TWO

A release pipeline scans and approves the image currently tagged candidate. Another team can move that tag before a GKE deployment starts. The security team requires the deployed bytes to be exactly those reviewed and wants a deployment-time check even if someone bypasses the pipeline. The cluster supports Binary Authorization and no exemption is intended for this application. Which two changes together meet these requirements? Choose TWO.

**A.** Put the approval in a Kubernetes label and let any deployment editor update that label.

**B.** Deploy the reviewed image by digest rather than resolving a mutable tag at rollout time.

**C.** Keep candidate mutable but grant the deployment account read-only Artifact Registry access.

**D.** Require a valid attestation for the approved digest using an enforcing Binary Authorization policy.

**Answer: B, D**

Digest pinning selects the reviewed content; enforced attestation checks make the approval requirement apply at admission. Registry read permission and ordinary workload labels do not establish release approval.

**Guide mapping:** 4.1; Bind deployment approval to immutable image identity. **Editorial difficulty:** medium.

- **A:** An editable label is not a cryptographically verified attestation.
- **B:** The digest makes the intended image identity explicit and stable.
- **C:** Read-only deployment access does not prevent another team from moving the tag.
- **D:** Admission enforcement rejects a digest lacking the required trusted approval.

- [Binary Authorization concepts](https://docs.cloud.google.com/binary-authorization/docs/key-concepts) — Require-attestations rules verify signed image digests and block nonconforming deployments.

Sources checked 2026-11-03. Original author ID: `OPS-004`.

---

<a id="q154"></a>
### PCSE200-154 — Choose ONE

Arden Diagnostics has approved a two-region storage boundary for a new clinical service. Its project already contains a production database and archived exports outside that boundary. The team applies a resource-location organization policy and confirms that a new out-of-boundary test bucket is rejected. Cutover must preserve recovery evidence, and the security lead needs a defensible statement about the existing workload. Which next action best establishes compliance with the approved boundary? Choose ONE.

**A.** Reapply the same location policy at organization scope and wait for propagation before taking the existing inventory as compliant.

**B.** Record the rejected creation as proof of the boundary, then migrate only the active database because archives cannot accept writes.

**C.** Inventory existing data, replicas and archives; verify each service's location behavior; execute a retention-aware migration and verify the resulting inventory.

**D.** Move the project under a regional folder, retaining existing resources until their next normal maintenance event.

**Answer: C**

A successful creation denial proves a preventive rule for that resource type. It says nothing about relocating pre-existing data. The migration must account for recovery and retention dependencies.

**Guide mapping:** 5.1; Separate preventive location guardrails from existing-resource remediation. **Editorial difficulty:** hard.

- **A:** A broader scope still does not make the location constraint retroactive.
- **B:** Read-only archives still contain regulated data under the stated requirement.
- **C:** This checks existing exposure and verifies the migration without discarding required recovery evidence.
- **D:** A folder move changes policy inheritance; it does not move stored resources.

- [Restrict resource locations](https://docs.cloud.google.com/organization-policy/restrict-locations) — Location constraints restrict new supported resources, do not relocate existing resources, and are not universal storage or processing commitments.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-001`.

---

<a id="q155"></a>
### PCSE200-155 — Choose TWO

A research team compares self-managed training on Compute Engine VMs with managed custom training on Gemini Enterprise Agent Platform. Both options execute the team's Python code and selected dependencies. A proposal claims that choosing managed training eliminates the team's obligation to maintain vulnerable application packages and configure data permissions. The team needs an accurate ownership model before approving either option. Which two statements correctly guide the security plan? Choose TWO answers.

**A.** For self-managed VMs, treat IAM-restricted access as sufficient reason to omit guest OS patch management.

**B.** For managed training, retain customer responsibility for application dependencies, data permissions, and selecting supported container versions.

**C.** For managed training, treat customer-supplied container packages as automatically patched in place by the platform.

**D.** For self-managed VMs, plan customer ownership of guest OS and training-software maintenance.

**Answer: B, D**

Managed training transfers infrastructure operations but not customer application and data responsibilities. IaaS additionally requires customer management of guest software, including the OS.

**Guide mapping:** 3.3; Allocate security duties across IaaS and managed training. **Editorial difficulty:** hard.

- **A:** IAM access controls and patching address different failure modes.
- **B:** Managed platform security does not remove these application-level obligations.
- **C:** The customer must update its selected artifacts and dependencies rather than assume an in-place repair.
- **D:** The guest stack is part of the customer's IaaS responsibility.

- [Agent Platform shared responsibility](https://docs.cloud.google.com/gemini-enterprise-agent-platform/machine-learning/shared-responsibility) — Customers secure applications and access, and select upgraded containers; Google secures the managed platform.
- [Google security overview: shared responsibility](https://docs.cloud.google.com/docs/security/overview/whitepaper) — IaaS leaves customer guest software and data responsibilities beyond Google's underlying infrastructure.

Sources checked 2026-11-03. Original author ID: `DATA-040`.

---

<a id="q156"></a>
### PCSE200-156 — Choose ONE

An integration team configures a 30-day rotation schedule and Pub/Sub topic for an external vendor API credential stored in Secret Manager. After the first interval, the topic receives a rotation event, but the vendor still accepts the old credential and no new secret version exists. The vendor supports overlapping active credentials. The team needs automatic rotation with a safe deployment transition. What missing component should it implement? Choose ONE answer.

**A.** A CMEK rotation schedule on the secret's encryption key, replacing the vendor credential automatically.

**B.** A second Pub/Sub topic so Secret Manager can directly update both the vendor and the application.

**C.** A secret expiration timestamp that deletes the old secret before applications request a replacement.

**D.** A subscriber that creates a vendor credential, stores a new version, rolls consumers forward, then retires the old credential.

**Answer: D**

Secret Manager rotation scheduling sends notifications; customer automation performs external credential creation and rollout. Overlap enables validation before retiring the old credential.

**Guide mapping:** 3.1; Implement the work behind Secret Manager rotation notifications. **Editorial difficulty:** medium.

- **A:** Rotating storage encryption does not rotate the credential contained in the secret.
- **B:** Adding a topic does not implement an external API integration.
- **C:** Deleting first creates an avoidable outage and does not provision replacement credentials.
- **D:** This supplies the required vendor-specific actions and controlled transition.

- [Create rotation schedules in Secret Manager](https://docs.cloud.google.com/secret-manager/docs/secret-rotation) — Rotation schedules deliver Pub/Sub notifications; a subscriber implements credential rotation.

Sources checked 2026-11-03. Original author ID: `DATA-014`.

---

<a id="q157"></a>
### PCSE200-157 — Choose ONE

A company uses Secure Web Proxy to allow only /packages/ downloads from a vendor HTTPS site. TLS inspection works for managed browsers after deployment of the enterprise inspection root. A legacy signed updater now fails because it pins the vendor's certificate; its pin cannot be changed this quarter. The updater runs on dedicated VMs with a distinct service account that Secure Web Proxy can match. Security approves a narrowly bounded temporary exception for that updater's identity and vendor hostname, accepting hostname-level control for those requests. What should the team do? Choose ONE.

**A.** Create a no-inspection exception matching the dedicated updater service account and vendor hostname, while retaining inspection and path rules for other traffic.

**B.** Bypass TLS inspection for the vendor hostname for every source identity, retaining inspection on other hostnames.

**C.** Add the vendor's public certificate chain to the proxy's server trust configuration while keeping interception for the pinned updater.

**D.** Install another copy of the inspection root; certificate pinning will then accept the generated vendor certificate automatically.

**Answer: A**

Certificate pinning can reject the interception certificate even when its issuer is trusted. The approved exception must acknowledge loss of decrypted path visibility for the exempted flows.

**Guide mapping:** 2.1; Handle HTTPS path inspection and certificate pinning. **Editorial difficulty:** hard.

- **A:** The distinct proxy-matchable source identity permits the approved narrowly scoped exception. Exempted flows lose decrypted path visibility; other traffic retains inspection.
- **B:** This may restore the pinned updater but also exempts other sources from the vendor path controls, exceeding the specifically approved identity exception.
- **C:** Backend certificate trust does not make the updater accept a substituted certificate that violates its pin.
- **D:** Trusting an issuer does not generally override an application's certificate pin.

**Service assumption/limitation:** An inspection bypass cannot enforce the same encrypted URL-path checks on the bypassed traffic.

- [TLS inspection overview](https://docs.cloud.google.com/secure-web-proxy/docs/tls-inspection-overview) — HTTPS path inspection needs TLS decryption; certificate-pinned traffic can be scoped out using session conditions.

Sources checked 2026-11-03. Original author ID: `NETWORK-016`.

---

<a id="q158"></a>
### PCSE200-158 — Choose ONE

An auditor asks the cloud platform team which principals have a specified read permission on a collection of supported resources through the organization's IAM allow policies. The answer must account for inherited roles and available group expansion rather than sampling recent API calls. The auditor understands that this inventory is not proof of actual use or a complete verdict about every other enforcement layer. Which Policy Intelligence capability is the best starting point? Choose ONE.

**A.** Policy Simulator, because a hypothetical policy always inventories the current organization.

**B.** An audit-log search, because principals absent from logs have no permissions.

**C.** Role recommendations, because a recommended removal lists every principal that has access.

**D.** Policy Analyzer for IAM allow policies, using an appropriately scoped access query.

**Answer: D**

Policy Analyzer answers who-can-access-what questions about allow policies. Historical activity and recommended role changes answer different questions.

**Guide mapping:** 1.4; Inventory who has access through IAM allow policies. **Editorial difficulty:** medium.

- **A:** Simulation primarily assesses change impact rather than this current-policy query.
- **B:** Lack of observed activity does not imply lack of permission.
- **C:** Recommendations do not replace a complete allow-access inventory.
- **D:** Correct: this matches the requested allow-policy inventory.

**Service assumption/limitation:** Group visibility, supported resource coverage and other enforcement layers bound the result.

- [Policy Intelligence overview](https://docs.cloud.google.com/policy-intelligence/docs/overview) — Policy Analyzer examines allow access while recommendations and troubleshooters support distinct tasks.

Sources checked 2026-11-03. Original author ID: `ACCESS-039`.

---

<a id="q159"></a>
### PCSE200-159 — Choose ONE

A records team rotates the Cloud KMS key used as its Cloud Storage bucket's default CMEK. New uploads show the replacement version, but object metadata for older records still references the previous version. The team intends to retire that old version only after every retained live object has moved, and a separate inventory accounts for noncurrent versions. Which operation addresses the unchanged encryption of those live objects? Choose ONE answer.

**A.** Patch each object's metadata to replace its recorded KMS version without rewriting object data.

**B.** Update only the bucket's default CMEK setting and treat the saved configuration as evidence all old objects migrated.

**C.** Disable the old version first so Cloud Storage must re-encrypt objects on the next read.

**D.** Rewrite the existing objects using the intended CMEK version and verify the resulting encryption metadata.

**Answer: D**

Cloud Storage does not retroactively rewrite existing objects merely because the default key's primary version changes. A rewrite migrates object protection; retained versions need separate accounting.

**Guide mapping:** 3.2; Migrate existing Cloud Storage objects after CMEK rotation. **Editorial difficulty:** hard.

- **A:** The encryption setting is not changed by a metadata-only patch; a rewrite is required.
- **B:** A bucket default does not retroactively rewrite existing object protection.
- **C:** Disabling the needed key can prevent reads and rewrite rather than force migration.
- **D:** Rewriting and verification provide an explicit migration path.

- [Customer-managed encryption keys in Cloud Storage](https://docs.cloud.google.com/storage/docs/encryption/customer-managed-keys) — Cloud Storage CMEK access and rotation are service-specific; existing objects require rewrite to change protection.
- [Key rotation](https://docs.cloud.google.com/kms/docs/key-rotation) — Rotation creates versions; it does not automatically re-encrypt data or disable previous versions.

Sources checked 2026-11-03. Original author ID: `DATA-028`.

---

<a id="q160"></a>
### PCSE200-160 — Choose ONE

A temporary auditor receives a bucket-level Storage Object Viewer binding with a condition that expires Friday. On Monday, the auditor can still read the objects. Uniform bucket-level access is enabled, the condition syntax is valid, and the account has no special administrative privilege. Investigation finds that the auditor is also in a group with unconditional Storage Object Viewer at the project. What is the most accurate diagnosis and fix? Choose ONE.

**A.** Conditions affect only write permissions, so read-only access cannot be time limited.

**B.** The bucket condition should automatically override project inheritance; reopen the same policy in the console.

**C.** Move the expiration timestamp earlier because inherited roles are evaluated against the oldest condition.

**D.** The unconditional project grant still authorizes access; remove or appropriately narrow that independent access path.

**Answer: D**

Allow grants are additive. A condition limits its own binding and cannot revoke permissions independently granted by an unconditional ancestor binding.

**Guide mapping:** 1.4; Find an unconditional grant that defeats intended expiry. **Editorial difficulty:** hard.

- **A:** Supported read permissions can be granted conditionally.
- **B:** A child conditional grant does not override a parent allow grant.
- **C:** An unrelated condition is not inherited as a restriction on every role binding.
- **D:** Correct: address the actual unconditional authorization path.

- [Overview of IAM Conditions](https://docs.cloud.google.com/iam/docs/conditions-overview) — Conditional bindings cannot narrow unconditional grants; bucket-level conditions require uniform access.

Sources checked 2026-11-03. Original author ID: `ACCESS-032`.

---

<a id="q161"></a>
### PCSE200-161 — Choose ONE

A company has moved a defined employee group to third-party SAML SSO profiles. Its security team wants that group's corporate password rules enforced by the external IdP. After enabling Google password-expiration enforcement as well, some employees receive confusing Google password-change prompts although their IdP passwords meet policy. The company will retain separately secured Google-authenticated recovery administrators. Which remediation best follows current guidance for the SSO employee group? Choose ONE.

**A.** Turn off Google password enforcement for the SSO group, remove forced-next-sign-in password changes, and enforce the corporate rules at the IdP.

**B.** Introduce password synchronization so Google password expiry becomes the authority for the external IdP's passwords.

**C.** Require a Google password change at every next sign-in for the SSO users until they stop reporting prompts.

**D.** Continue shortening Google password expiry until it matches the external IdP's rules exactly.

**Answer: A**

Current guidance advises disabling password enforcement and forced password changes for users using third-party SSO profiles. The external password authority must enforce its own rules; recovery accounts remain separately governed.

**Guide mapping:** 1.3; Apply password policy at the authentication authority. **Editorial difficulty:** hard.

- **A:** Correct: it addresses the prompt behavior while maintaining the actual IdP password policy.
- **B:** Google password-expiration configuration does not replace the external IdP's password policy.
- **C:** Forced Google password changes are part of the documented SSO-profile issue, not its remediation.
- **D:** Matching durations does not resolve the documented SSO-profile interaction.

**Service assumption/limitation:** Recheck current Workspace SSO-profile guidance before applying this behavior to a real tenant.

- [Enforce and monitor password requirements for users](https://knowledge.workspace.google.com/admin/users/enforce-and-monitor-password-requirements-for-users) — Google-managed password policies do not replace external IdP password policy; guidance addresses SSO profile password prompts.

Sources checked 2026-11-03. Original author ID: `ACCESS-023`.

---

<a id="q162"></a>
### PCSE200-162 — Choose ONE

A payments company has redundant Dedicated Interconnect connections and wants to carry legacy non-TLS traffic between its data center and VPC. Its requirement is IP-layer encryption across the hybrid path, including beyond the physical link to Google's edge. The company wants to retain the private connectivity and use a managed Google Cloud VPN service. Which addition is most appropriate, assuming the necessary supported attachment topology and capacity are provisioned? Choose ONE.

**A.** Deploy Classic VPN over the existing Interconnect attachments and use static routes to replace HA VPN.

**B.** Use plain Interconnect VLAN attachments and treat private addressing as proof that the legacy payloads are encrypted.

**C.** Deploy HA VPN over Cloud Interconnect so the selected hybrid traffic travels through IPsec tunnels on the private connection.

**D.** Enable MACsec alone and document it as IP-layer encryption extending from the data center through the complete VPC path.

**Answer: C**

Interconnect does not supply payload encryption by default. HA VPN over Interconnect adds managed IPsec while retaining the private underlay; MACsec alone has a different protection boundary.

**Guide mapping:** 2.3; Add IP-layer encryption to an Interconnect path. **Editorial difficulty:** medium.

- **A:** Classic VPN is not the supported VPN-over-Interconnect design.
- **B:** Private connectivity and encryption are different properties.
- **C:** This matches the required managed IPsec overlay and private transport.
- **D:** MACsec is link-layer protection to Google's edge, not the requested IP-layer hybrid protection.

**Service assumption/limitation:** The combined deployment's availability also depends on the underlying Interconnect topology.

- [Cloud Interconnect overview](https://docs.cloud.google.com/network-connectivity/docs/interconnect/concepts/overview) — Interconnect is not encrypted by default; HA VPN over Interconnect adds IPsec.
- [HA VPN over Cloud Interconnect overview](https://docs.cloud.google.com/network-connectivity/docs/interconnect/concepts/ha-vpn-interconnect) — HA VPN over Interconnect provides IPsec over private attachments; availability also depends on the underlying topology.

Sources checked 2026-11-03. Original author ID: `NETWORK-042`.

---

<a id="q163"></a>
### PCSE200-163 — Choose TWO

A security alert identifies a suspicious process in a GKE workload. Responders suspect a memory-resident payload and possible writes to the host disk. The incident commander authorizes controlled live evidence acquisition before rebuilding, provided the node is contained and the application can fail over. The team already has a tested forensic access path and a protected evidence project. An operator proposes taking a disk snapshot and immediately restarting the node, asserting that the snapshot preserves everything. The node must also be protected against an automated recreation while acquisition proceeds. This authorization does not permit leaving normal application access open merely to simplify collection. Which two requirements should the response lead enforce instead? Choose TWO.

**A.** Allow automatic repair to recreate the node first, then inspect the replacement for the original suspicious process.

**B.** Treat the disk snapshot as a complete memory image and proceed directly to a reboot after it completes.

**C.** Preserve disk snapshots and relevant logs separately, recognizing that disk snapshots do not include RAM contents.

**D.** Capture required volatile evidence before destructive lifecycle actions, with containment and controlled forensic access.

**Answer: C, D**

Disk and memory are different evidence sources. The authorized live response must preserve needed volatile state before reboot, while disk snapshots and logs retain other parts of the incident record.

**Guide mapping:** 4.2; Preserve disk and volatile evidence during containment. **Editorial difficulty:** hard.

- **A:** A replacement node does not preserve the former node volatile state.
- **B:** Disk snapshots capture disk state, not the running memory image.
- **C:** This preserves durable evidence without overstating what a snapshot captures.
- **D:** This addresses the memory-resident evidence requirement before it is destroyed.

**Service assumption/limitation:** Containment must account for existing connections and the actual topology; adding a firewall rule alone is not claimed to close every established connection.

- [Mitigate security incidents](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/security-mitigations) — Disk snapshots preserve written disk state but not memory; access should be reduced before live inspection.

Sources checked 2026-11-03. Original author ID: `OPS-031`.

---

<a id="q164"></a>
### PCSE200-164 — Choose ONE

A diagnostic plugin runs beside a trusted service on a Compute Engine VM. A review finds a database password in custom metadata and a second copy in an environment dump uploaded by the plugin. The application can be changed, and the untrusted plugin does not need the application's identity or secrets. Which design most directly reduces these two exposure paths while still allowing unattended application startup? Choose ONE answer.

**A.** Remove the environment variable but leave the password in custom instance metadata with a secret-scoped IAM role.

**B.** Move the password to Secret Manager but export its value into the same process environment for plugin diagnostics.

**C.** Retrieve the password with the existing shared VM identity and rely only on secret-level IAM to isolate the plugin.

**D.** Retrieve the password through Secret Manager with a narrowly scoped identity and isolate the plugin from that identity and secret-bearing process.

**Answer: D**

Secret Manager retrieval reduces metadata and environment duplication, while isolation is essential because co-resident untrusted processes must not gain the trusted workload's identity or memory.

**Guide mapping:** 3.1; Reduce secret exposure through application configuration. **Editorial difficulty:** hard.

- **A:** Secret Manager IAM cannot protect a separate plaintext copy in the VM metadata server.
- **B:** Secret storage improves, but the observed environment-dump leak remains.
- **C:** If the plugin can use that same identity, secret-level IAM does not distinguish it from the trusted application.
- **D:** Both storage hygiene and runtime identity isolation address the observed leaks.

- [Secret Manager best practices](https://docs.cloud.google.com/secret-manager/docs/best-practices) — Use secret-scoped access, controlled version rollout and API retrieval; disable before destruction.
- [About VM metadata](https://docs.cloud.google.com/compute/docs/metadata/overview) — Processes able to query metadata can read its values; sandbox untrusted processes.

Sources checked 2026-11-03. Original author ID: `DATA-015`.

---

<a id="q165"></a>
### PCSE200-165 — Choose TWO

A patch campaign installs kernel updates on Linux VMs with rebootConfig set to NEVER. The dashboard shows successful package operations, but a later review finds the old kernel still running. The team must claim the security fix only after the new kernel is active, while respecting approved maintenance periods. It cannot simply interrupt all workloads immediately. Which two actions should be included in the corrective plan? Choose TWO.

**A.** Schedule the required reboot in an approved controlled rollout, then verify the active kernel and application health.

**B.** Increase the original job duration and assume this overrides the explicit NEVER reboot setting.

**C.** Treat package installation success as sufficient evidence that the running kernel has changed.

**D.** Separate package installation evidence from effective remediation, recording pending reboot until the required restart is completed.

**Answer: A, D**

Never-reboot can leave patches incompletely effective. The response must schedule the needed restart and verify the running state rather than conflate installation with remediation.

**Guide mapping:** 4.1; Validate patch completion beyond successful package installation. **Editorial difficulty:** medium.

- **A:** This completes and checks the required operational transition.
- **B:** Duration is not a replacement for the configured reboot policy.
- **C:** The observed old kernel contradicts that conclusion.
- **D:** This maintains an accurate compliance record during the interim.

- [Create patch jobs](https://docs.cloud.google.com/compute/vm-manager/docs/patch/create-patch-job) — NEVER can leave patches not fully applied; reboot configuration and post-patch health steps are distinct controls.

Sources checked 2026-11-03. Original author ID: `OPS-037`.

---

<a id="q166"></a>
### PCSE200-166 — Choose ONE

Willow Payments is recertifying who is granted a sensitive permission on a production bucket through IAM allow policies. Some grants are attached at organization and folder levels; others reference nested groups. The reviewer initially exports only the bucket's direct policy and finds three identities. The control owner requires visibility into granted access rather than a list of who happened to use the permission last month. Group expansion permissions are available, and no group exceeds the documented expansion cap. The review is explicitly of allow-policy grants; a separate workstream will assess deny policies and other enforcement layers. Which evidence collection method best addresses the current review? Choose ONE.

**A.** Run Policy Analyzer only at the bucket's project scope, assuming it will include all organization and folder bindings automatically.

**B.** Export direct bucket bindings and the top-level group names, requiring no membership expansion because groups are themselves IAM principals.

**C.** Use the bucket's Data Access logs to identify recent callers, treating identities absent from those logs as lacking access.

**D.** Run Policy Analyzer at organization scope for the bucket and permission with group expansion, check completeness, and submit the grant paths for owner recertification.

**Answer: D**

The review needs inherited allow grants and human membership, not merely direct bindings or observed activity. Analysis scope must include the relevant ancestors.

**Guide mapping:** 5.1; Produce an appropriately scoped access recertification inventory. **Editorial difficulty:** hard.

- **A:** Policies above the analysis scope are not included in that scoped analysis.
- **B:** Top-level groups do not identify the members whose access must be recertified.
- **C:** Unused permission is still granted permission.
- **D:** This captures the relevant policy scope and expanded grants for the specified review.

**Service assumption/limitation:** Policy Analyzer allow-policy results are not a universal effective-access verdict; inspect completeness and other controls separately.

- [Policy Analyzer for allow policies](https://docs.cloud.google.com/policy-intelligence/docs/policy-analyzer-overview) — Analysis considers allow policies within its scope and supports group expansion with permissions and expansion limits.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-015`.

---

<a id="q167"></a>
### PCSE200-167 — Choose ONE

A company has an HA VPN gateway and two independent on-premises VPN routers. Its engineer creates two IPsec tunnels, one to each peer router, but both originate from interface 0 of the Google gateway. Each tunnel carries a healthy BGP session. The design must qualify for the documented 99.99% availability SLA on the Google side and preserve peer-side redundancy. Which topology correction is required? Choose ONE.

**A.** Add a third tunnel from interface 0 because availability depends only on the total number of established tunnels.

**B.** Replace HA VPN with one Classic VPN tunnel because two independent peer routers make the gateway type irrelevant.

**C.** Place at least one tunnel on each HA VPN gateway interface, connecting to the corresponding independent peer paths.

**D.** Keep both tunnels on interface 0 and set equal BGP priorities; equal-cost routing supplies the missing interface redundancy.

**Answer: C**

Healthy tunnels sharing one Google-side interface do not meet the documented interface-redundancy topology. Both gateway interfaces need tunnels; peer redundancy is retained by using the independent peers.

**Guide mapping:** 2.3; Design HA VPN gateway-interface redundancy. **Editorial difficulty:** medium.

- **A:** Additional tunnels on the same interface do not satisfy the requirement.
- **B:** This removes the required Google-side HA architecture.
- **C:** This supplies the missing Google-interface redundancy.
- **D:** Routing policy does not remove the single-interface failure exposure.

**Service assumption/limitation:** An SLA topology is not a guarantee of uninterrupted application availability; peer and routing behavior still matter.

- [HA VPN topologies](https://docs.cloud.google.com/network-connectivity/docs/vpn/concepts/topologies) — 99.99% Google-side availability requires tunnels on both HA VPN interfaces; failover changes available capacity.

Sources checked 2026-11-03. Original author ID: `NETWORK-041`.

---

<a id="q168"></a>
### PCSE200-168 — Choose ONE

A security engineer creates a CA Service subordinate CSR with a path-length restriction. The offline signing team returns a CA certificate containing the expected public key and subject, but their generic signing template omits the CSR's restriction. They propose uploading it because both signatures validate and the workload leaf certificates will use short lifetimes. The organization requires the intended hierarchy limits to remain enforced. What is the best next step? Choose ONE.

**A.** Upload the certificate and restrict who can request certificates through IAM, treating that as a replacement for the missing CA extension.

**B.** Have the external CA reissue the subordinate certificate preserving the CSR properties, then activate it with the correct chain.

**C.** Upload the certificate and configure a short maximum leaf lifetime in the CA pool as compensation for the omitted path-length restriction.

**D.** Ask the external signer to remove every CA constraint consistently from both its template and the returned chain before activation.

**Answer: B**

CA Service requires the external signer to preserve generated CSR properties, including path-length restrictions. Valid signatures and short leaf lifetimes do not repair missing hierarchy constraints.

**Guide mapping:** 2.1; Preserve CA constraints during external signing. **Editorial difficulty:** hard.

- **A:** IAM restrictions are useful but do not repair the signed certificate's required CSR properties.
- **B:** Reissuing the certificate with preserved constraints fixes the actual defect.
- **C:** A leaf lifetime limit does not preserve the subordinate CSR's required path-length property.
- **D:** Removing constraints weakens the intended hierarchy and does not preserve the generated CSR's properties.

- [Create a subordinate CA from an external CA](https://docs.cloud.google.com/certificate-authority-service/docs/create-sub-ca-from-external-ca) — External signing and activation preserve the existing root; the signed certificate must preserve generated CSR properties.

Sources checked 2026-11-03. Original author ID: `NETWORK-008`.

---

<a id="q169"></a>
### PCSE200-169 — Choose TWO

A factory connects to a VPC through working HA VPN tunnels and uses private source addresses. It must call supported Google APIs through restricted.googleapis.com without internet access. The VPC already has the restricted-VIP route to the default internet gateway, appropriate return routes in the correct region, and firewall permissions. Factory DNS still resolves ordinary public API addresses, and its router has no route for the restricted VIP. Which TWO changes complete the design? Choose TWO.

**A.** Advertise the restricted VIP range to the factory through Cloud Router, or install an equivalent route over the VPN path.

**B.** Map the required Google API names to restricted.googleapis.com with its documented VIP addresses in the factory's DNS resolution path.

**C.** Enable the Private Google Access checkbox on an unused VPC subnet and leave the factory's DNS and routing unchanged.

**D.** Enable Public NAT for the connected VPC and leave the factory's public API resolution and missing restricted-VIP route unchanged.

**Answer: A, B**

Hybrid PGA needs clients to select the special API destination and route it through the hybrid connection. A subnet checkbox does not substitute for either on-premises requirement.

**Guide mapping:** 2.3; Complete on-premises Private Google Access DNS and routing. **Editorial difficulty:** hard.

- **A:** This sends the VIP-bound traffic through the intended private path.
- **B:** This makes the application select the required VIP destination.
- **C:** That subnet setting does not redirect the factory's DNS or routes.
- **D:** This does not complete the required special-VIP routing and DNS design for on-premises hosts.

- [Configure Private Google Access for on-premises hosts](https://docs.cloud.google.com/vpc/docs/configure-private-google-access-hybrid) — Hybrid PGA requires VIP-directed DNS and routing over VPN or Interconnect, including a regional return path.
- [Set up private connectivity to Google APIs and services](https://docs.cloud.google.com/vpc-service-controls/docs/set-up-private-connectivity) — Restricted VIP routing uses the default internet gateway privately; DNS and hybrid custom advertisements are separate requirements.

Sources checked 2026-11-03. Original author ID: `NETWORK-034`.

---

<a id="q170"></a>
### PCSE200-170 — Choose TWO

A platform team mandates keyless authentication for new projects. It enforces a constraint against generating user-managed service account keys, but a red-team validation finds that administrators can still upload their own public keys to service accounts and retain corresponding private keys. Existing approved legacy keys must be inventoried separately. Which TWO actions best close this governance gap and address the residual exposure? Choose TWO.

**A.** Assume disabling key generation also disables authentication with uploaded keys.

**B.** Inventory and remediate existing user-managed keys because prevention of new keys is not their revocation.

**C.** Enable alerts for key-upload audit events while allowing administrators to continue uploading keys.

**D.** Enforce the separate organization constraint that blocks service account key upload, with tightly reviewed exceptions.

**Answer: B, D**

Creation and upload are separate key-establishment paths. Preventive constraints must cover both, while existing credentials require explicit review and remediation.

**Guide mapping:** 1.2; Control both service account key creation and upload. **Editorial difficulty:** hard.

- **A:** The observed upload path disproves the assumption.
- **B:** Correct: already-existing key material remains a separate lifecycle concern.
- **C:** Detection is useful but does not enforce the keyless establishment requirement.
- **D:** Correct: the upload constraint closes the separate establishment path.

- [Best practices for managing service account keys](https://docs.cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys) — Restrict key creation and upload, rotate necessary keys, and disable detected exposed keys.

Sources checked 2026-11-03. Original author ID: `ACCESS-020`.

---

<a id="q171"></a>
### PCSE200-171 — Choose ONE

A bucket contains audit evidence with a 365-day retention policy. A lifecycle Delete rule selects objects older than 90 days, and one 200-day-old object is also under a temporary hold. An operator believes the lifecycle service is malfunctioning because that object remains present. The organization must preserve the retention guarantee and hold. Which interpretation best explains the result and the appropriate operational expectation? Choose ONE answer.

**A.** The Delete rule is eligible by age, but deletion waits until both retention and hold restrictions permit it.

**B.** Removing the temporary hold will cause deletion eligibility immediately, despite the remaining bucket-retention period.

**C.** Add a second age-only Delete rule so one rule can delete objects that the first rule cannot delete.

**D.** The Delete rule's age condition overrides bucket retention but remains blocked only by the temporary hold.

**Answer: A**

Lifecycle deletion respects unfulfilled retention and object holds. Age eligibility does not authorize deletion through those controls, and actual lifecycle processing is asynchronous.

**Guide mapping:** 3.2; Respect retention and holds in lifecycle deletion. **Editorial difficulty:** medium.

- **A:** Both independent restrictions must be satisfied or removed as appropriate.
- **B:** The unfulfilled retention policy remains independently blocking.
- **C:** Another lifecycle rule does not bypass retention or holds.
- **D:** Lifecycle deletion must honor both retention and the hold.

- [Object Lifecycle Management](https://docs.cloud.google.com/storage/docs/lifecycle) — Lifecycle actions are asynchronous and constrained by holds, retention and versioning.

Sources checked 2026-11-03. Original author ID: `DATA-032`.

---

<a id="q172"></a>
### PCSE200-172 — Choose ONE

A fraud research team must join customer events from monthly exports without receiving original email addresses. An independent investigation service must later recover an address from an approved token. The export schema accepts longer strings, and no character-set compatibility is required. The same customer must receive the same token across runs using stable transformation inputs. Which Sensitive Data Protection approach best meets these requirements while avoiding an unnecessary format-preservation constraint? Choose ONE answer.

**A.** Use character masking, retaining the email domain to support joins.

**B.** Generate a fresh random replacement token for every record without retaining a lookup.

**C.** Use keyed HMAC hashing and give investigators the hashing key for reversal.

**D.** Use deterministic AES-SIV tokenization with a stable key and consistent context.

**Answer: D**

AES-SIV deterministic tokenization permits repeatable joins and authorized re-identification when the necessary key and token information are retained. It need not preserve source length or alphabet.

**Guide mapping:** 3.1; Choose reversible deterministic pseudonymization. **Editorial difficulty:** hard.

- **A:** Masking can collapse different customers to the same output and is not reversible.
- **B:** Untracked per-record random replacements break joins and recovery.
- **C:** HMAC supports repeatable pseudonyms but is not decrypted with its key.
- **D:** Determinism and reversibility satisfy both analytical and investigation needs.

- [Pseudonymization](https://docs.cloud.google.com/sensitive-data-protection/docs/pseudonymization) — AES-SIV supports reversible deterministic tokens; FPE preserves alphabet and length; HMAC is not re-identifiable.

Sources checked 2026-11-03. Original author ID: `DATA-003`.

---

<a id="q173"></a>
### PCSE200-173 — Choose ONE

Employees at a healthcare supplier suddenly receive a SAML credentials-could-not-be-verified error after their IdP rotates its signing key. A test confirms that the managed Google account exists, its NameID is correct, and recipient and destination values still match the configured profile. Google retains the prior verification certificate; the old IdP signing key has been retired and rollback is not permitted. The team must restore the intended trust without weakening validation. What is the best next action? Choose ONE.

**A.** Verify and install the public certificate matching the IdP's active signing key in the applicable SSO profile.

**B.** Request permanent rollback to the retired IdP signing key rather than completing verification-certificate rollover.

**C.** Re-provision the users and their group memberships before replacing any certificate.

**D.** Install the IdP HTTPS endpoint certificate as the SAML verification certificate, retaining the active signing configuration.

**Answer: A**

The stated checks eliminate several other SAML causes. The remaining signing-key mismatch is resolved by installing the corresponding trusted public verification certificate.

**Guide mapping:** 1.3; Diagnose a SAML signing-key mismatch. **Editorial difficulty:** medium.

- **A:** Correct: the verification key must match the IdP's active signing key.
- **B:** Rollback is explicitly unavailable and would not complete the required new signing trust.
- **C:** The accounts and NameID have already been verified; recreating identities does not fix the mismatched verification key.
- **D:** The endpoint TLS certificate and the certificate for verifying signed SAML messages are different trust inputs.

- [Troubleshoot single sign-on (SSO)](https://knowledge.workspace.google.com/admin/support/troubleshooting/troubleshoot-single-sign-on-sso) — Certificate mismatch, incorrect NameID and incorrect recipient information can cause SAML sign-in failures.

Sources checked 2026-11-03. Original author ID: `ACCESS-026`.

---

<a id="q174"></a>
### PCSE200-174 — Choose ONE

An artifact has valid Cloud Build provenance identifying the expected repository and builder. Its vulnerability scan also reports a fixable CRITICAL issue that violates the release standard. A deployment engineer proposes accepting the provenance signature as the security approval because the build itself was trustworthy. The organization needs both trustworthy origins and the vulnerability gate, with separately controlled security approval. What should the reviewer require? Choose ONE.

**A.** Accept the provenance because a trusted build service guarantees the contents meet the vulnerability standard.

**B.** Replace provenance verification with the scan report because vulnerability acceptance proves the source repository.

**C.** Verify provenance and independently enforce vulnerability acceptance before issuing the security attestation for that digest.

**D.** Treat the provenance as invalid whenever the scan finds a vulnerability, then rebuild without changing dependencies.

**Answer: C**

Provenance describes and authenticates build origins and process. It does not imply that the result meets an independent vulnerability standard; the security approval must reflect that separate decision.

**Guide mapping:** 4.1; Distinguish provenance from security acceptance. **Editorial difficulty:** hard.

- **A:** Trust in the builder does not imply an absence of vulnerable dependencies.
- **B:** A scan result does not prove source and builder identity.
- **C:** Independent validation preserves both required controls and the separation of approval authority.
- **D:** A valid build record can accurately describe a vulnerable artifact; rebuilding unchanged inputs is not remediation.

- [Generate and validate build provenance](https://docs.cloud.google.com/build/docs/securing-builds/generate-validate-build-provenance) — Provenance records verifiable build data including artifact digests, sources, and builder information.
- [Binary Authorization concepts](https://docs.cloud.google.com/binary-authorization/docs/key-concepts) — Policies can require an attestation signed by an identified attestor.

Sources checked 2026-11-03. Original author ID: `OPS-005`.

---

<a id="q175"></a>
### PCSE200-175 — Choose ONE

Three release engineers currently share a service account JSON key to administer a staging deployment. During an investigation, the service's audit logs show the service account but cannot identify which engineer used the key. The target service records delegation information for impersonated requests. The team wants short-lived access and individual authentication without changing the deployment identity's resource permissions. What should it implement? Choose ONE.

**A.** Have each engineer sign in individually and obtain short-lived credentials by impersonating the deployment service account.

**B.** Issue a separate long-lived service account key to each engineer and record the key owners.

**C.** Attach the account to a shared VM and require engineers to run every command inside the same shell session.

**D.** Distribute the shared key through individually authenticated vault sessions and use checkout records as the only attribution.

**Answer: A**

Impersonation can preserve the initiating identity alongside the service account in supported audit logs and removes the shared private-key workflow.

**Guide mapping:** 1.2; Replace shared keys with attributable impersonation. **Editorial difficulty:** medium.

- **A:** Correct: individual authentication plus delegation provides the required attribution path.
- **B:** Separate keys may improve key-level attribution, but retain private keys and do not meet the short-lived, individually authenticated requirement.
- **C:** A shared workload session still authenticates through the workload account without the required individual delegation.
- **D:** Vault checkout records do not make copied shared credentials short-lived or ensure target requests reflect an individually authenticated initiator.

**Service assumption/limitation:** Audit fields vary by service; the scenario explicitly states delegation logging support.

- [Service account impersonation](https://docs.cloud.google.com/iam/docs/service-account-impersonation) — Impersonation obtains short-lived credentials and usually preserves initiating identity in audit logs.

Sources checked 2026-11-03. Original author ID: `ACCESS-019`.

---

<a id="q176"></a>
### PCSE200-176 — Choose ONE

Monarch Services is moving PostgreSQL from Compute Engine to Cloud SQL. Its control matrix requires evidence for operating-system maintenance, database access reviews and regional disaster recovery. The migration team wants to remove work that the managed service now performs, while retaining customer obligations. The new instance currently has no cross-region recovery design, and application database grants have been copied unchanged. Which revised ownership statement is most accurate? Choose ONE.

**A.** Google maintains the OS, database software and application grants; Monarch only needs to configure a maintenance window and regional recovery.

**B.** Google maintains the underlying OS; Monarch must retain its VM patch agent to patch the managed database binaries and review database access.

**C.** Google maintains the underlying OS and database software; Monarch reviews database access and configures and validates its selected recovery architecture.

**D.** Google maintains the underlying OS and automatically provides regional recovery; Monarch retains database access reviews and application patching.

**Answer: C**

Cloud SQL changes infrastructure ownership, but access and chosen HA/DR configuration remain customer responsibilities.

**Guide mapping:** 5.1; Assign Cloud SQL operational controls to the correct owner. **Editorial difficulty:** medium.

- **A:** Application-specific authentication and authorization remain customer-controlled.
- **B:** Customers do not patch Cloud SQL through a guest VM agent.
- **C:** This assigns provider maintenance and customer configuration obligations correctly.
- **D:** Regional recovery depends on configuration; a managed instance alone is insufficient.

- [Shared Responsibility: Cloud SQL for PostgreSQL](https://docs.cloud.google.com/sql/docs/postgres/shared-responsibility) — Google maintains infrastructure and database software; customers configure access, connectivity, HA and disaster recovery.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-003`.

---

<a id="q177"></a>
### PCSE200-177 — Choose ONE

Two independently administered VPCs are peered. A client VM in the supplier VPC uses a service account named exporter. The receiving VPC has a classic ingress rule allowing that source service account to its ingestion VMs, but new connections fail. Peering routes, destination ports and guest listeners are correct; no other ingress rule permits the traffic. Only the supplier's dedicated source range may reach ingestion, and the team must retain classic VPC rules. Which change addresses the actual mismatch? Choose ONE.

**A.** Change the receiving rule to match only the ingestion target service account, with no source restriction, while keeping the approved-source requirement.

**B.** Use the supplier's narrowly allocated source IP range in the receiving VPC rule; classic source-service-account matching does not identify VMs across peering.

**C.** Copy the same source-service-account rule to the supplier VPC so peering imports it into the receiving VPC.

**D.** Grant the exporter service account Viewer in the receiving project so its source identity becomes visible to the ingress matcher.

**Answer: B**

Classic VPC source-service-account selectors resolve VM interfaces in the rule's own VPC. A scoped source address rule fits the stated cross-peering deployment.

**Guide mapping:** 2.2; Respect firewall identity scope across peering. **Editorial difficulty:** hard.

- **A:** This may allow connectivity but removes the required supplier-source restriction rather than replacing it accurately.
- **B:** This replaces the unsupported identity selector with an applicable source criterion.
- **C:** Peering exchanges routes, not firewall rules.
- **D:** IAM visibility does not extend the selector's network scope.

**Service assumption/limitation:** Do not generalize this classic-rule limit to secure Tags in network firewall policies, whose supported peering behavior differs.

- [VPC Network Peering](https://docs.cloud.google.com/vpc/docs/vpc-peering) — Peering is nontransitive, does not exchange firewall rules, and requires nonoverlapping IPv4 subnet ranges.

Sources checked 2026-11-03. Original author ID: `NETWORK-025`.

---

<a id="q178"></a>
### PCSE200-178 — Choose ONE

An internal reporting application runs on Compute Engine behind a global external Application Load Balancer with IAP enabled. A penetration test finds that another VM can call the backend directly and submit a forged x-goog-authenticated-user-email header. The application currently trusts that header. The team will retain IAP and must protect application authorization even if a future firewall change reopens a direct path. Which change provides the required defense in depth? Choose ONE.

**A.** Validate the signed IAP JWT, including signature, issuer, audience and time claims, and restrict backend ingress to the intended load-balancer path.

**B.** Move the backend to a private subnet and trust any request whose source address is inside the VPC's address range.

**C.** Accept the unsigned email header only when its domain matches the corporate domain and the request uses HTTPS.

**D.** Add a Cloud Armor IP allowlist to the load balancer and continue trusting the unsigned email header on the backend.

**Answer: A**

Network restrictions reduce bypass paths, while verification of the signed assertion prevents a caller on such a path from inventing an IAP-authenticated identity.

**Guide mapping:** 2.1; Prevent backend bypass of web IAP. **Editorial difficulty:** hard.

- **A:** The combined measures address network bypass and forged identity claims.
- **B:** Private source addresses do not prove that the request passed through IAP.
- **C:** A caller can forge the header's domain; TLS alone does not establish that IAP authorized the request.
- **D:** A load-balancer policy cannot authenticate a request that bypasses that load balancer.

- [Securing your app with signed headers](https://docs.cloud.google.com/iap/docs/signed-headers-howto) — Validate the IAP assertion signature and audience; unsigned identity headers can be forged on bypass paths.
- [Identity-Aware Proxy overview](https://docs.cloud.google.com/iap/docs/concepts-overview) — Backend access paths must be secured independently of enabling IAP on a load balancer.

Sources checked 2026-11-03. Original author ID: `NETWORK-010`.

---

<a id="q179"></a>
### PCSE200-179 — Choose ONE

A manufacturer inspects free-text maintenance tickets before sharing them with a research partner. Its employee identifiers and spare-part numbers both contain eight digits. Tests show that identifiers normally follow 'employee number', while part numbers follow 'component'. Globally lowering the likelihood threshold produces excessive redaction. The team needs context-sensitive detection while retaining useful engineering details. Which configuration is the best starting point, followed by validation on representative tickets? Choose ONE answer.

**A.** Keep the custom pattern but raise the global minimum likelihood without adding contextual rules.

**B.** Use the eight-digit custom pattern alone and assign every match the highest likelihood.

**C.** Use a custom identifier pattern with a nearby employee-number hotword rule and a suitable likelihood threshold.

**D.** Exclude every maintenance ticket containing the word component from sensitive-data inspection.

**Answer: C**

A custom detector plus proximity-based hotword rule makes context influence likelihood. Representative validation remains necessary because detection is not perfect.

**Guide mapping:** 3.1; Tune PII detection with contextual inspection rules. **Editorial difficulty:** hard.

- **A:** A global threshold alone cannot distinguish matching numeric identifiers from matching part numbers.
- **B:** This still treats component numbers as employee identifiers and retains the observed over-redaction.
- **C:** The pattern identifies candidates and the hotword distinguishes the relevant context.
- **D:** Ticket-level exclusion can suppress real employee identifiers elsewhere in the same ticket.

- [Customizing match likelihood](https://docs.cloud.google.com/sensitive-data-protection/docs/creating-custom-infotypes-likelihood) — Hotword rules use proximity context to adjust match likelihood.

Sources checked 2026-11-03. Original author ID: `DATA-002`.

---

<a id="q180"></a>
### PCSE200-180 — Choose ONE

Investigators see periodic egress from a group of Compute Engine VMs. VPC Flow Logs show destination addresses and byte counts, but the incident team needs to inspect the contents of a custom unencrypted protocol during an approved collection window. The team must avoid capturing traffic from unrelated database VMs on the same subnet. A collector is available in the same region, and the network owner authorizes narrowly scoped mirroring. The protocol does not use TLS, so decrypting application traffic is not part of this task. Packet collection must remain restricted to the approved systems and interval. Which collection design provides the missing evidence with the requested scope? Choose ONE.

**A.** Enable firewall policy rule logging on the egress allow rule and reconstruct application messages from connection records.

**B.** Route the current flow logs to BigQuery and treat a longer retention period as a substitute for packet capture.

**C.** Use Packet Mirroring to select the suspect instances and filter the relevant egress traffic to the forensic collector.

**D.** Increase VPC Flow Logs sampling to the maximum and extract the application payload from each flow record.

**Answer: C**

Packet Mirroring captures packet headers and payloads; flow and firewall logs contain network metadata. Selecting the suspect instances avoids subnet-wide capture.

**Guide mapping:** 4.2; Choose packet evidence rather than sampled flow summaries. **Editorial difficulty:** hard.

- **A:** Connection records are not application message captures.
- **B:** Retention and SQL analysis cannot recover packet bytes absent from the source.
- **C:** This supplies packet evidence and narrows collection to the authorized sources and traffic.
- **D:** Higher sampling improves flow visibility but does not turn summaries into payload capture.

- [Packet Mirroring](https://docs.cloud.google.com/vpc/docs/packet-mirroring) — Packet Mirroring copies selected instance traffic including headers and payloads and supports direction and traffic filters.
- [VPC Flow Logs](https://docs.cloud.google.com/vpc/docs/flow-logs) — VPC Flow Logs provide sampled network-flow records for analysis.

Sources checked 2026-11-03. Original author ID: `OPS-017`.

---

<a id="q181"></a>
### PCSE200-181 — Choose ONE

A company has three nonoverlapping VPCs. Development peers with a shared-services VPC, and shared-services peers with a testing VPC. Development and testing are not directly peered. Teams enable custom-route import and export on both existing peerings and expect development clients to reach testing subnet addresses through the middle VPC. Firewall rules already permit the intended flows. No router appliance or other transit service exists. What should the architect conclude? Choose ONE.

**A.** A Shared VPC attachment between development and shared-services is required merely to make the existing peerings transitive.

**B.** The peerings do not provide this transitive path; add a direct authorized connection or a supported transit architecture.

**C.** Custom-route import automatically makes the middle VPC a transit router for both peered subnet routes.

**D.** Adding a lower-priority firewall allow in shared-services will activate forwarding between its two peering connections.

**Answer: B**

VPC Network Peering is nontransitive. Route-exchange switches and permissive firewalls do not transform two independent peerings into a transit connection.

**Guide mapping:** 2.2; Recognize nontransitive VPC peering boundaries. **Editorial difficulty:** medium.

- **A:** Shared VPC is a different architecture and does not make these peerings transitive.
- **B:** A deliberate direct or supported transit path is required.
- **C:** Custom-route exchange does not export a peer's peering routes as transit.
- **D:** Firewall permission cannot create a missing supported routing path.

- [VPC Network Peering](https://docs.cloud.google.com/vpc/docs/vpc-peering) — Peering is nontransitive, does not exchange firewall rules, and requires nonoverlapping IPv4 subnet ranges.

Sources checked 2026-11-03. Original author ID: `NETWORK-024`.

---

<a id="q182"></a>
### PCSE200-182 — Choose ONE

A gateway calls a private application that validates Google-signed OIDC ID tokens for a specific audience. The gateway is already authenticated and may mint tokens for one designated service account. It must not mint OAuth access tokens or sign arbitrary data on that account's behalf. The application invocation permission is configured separately. Which IAM grant most closely matches the token-generation requirement? Choose ONE.

**A.** Service Account Key Admin on the designated service account.

**B.** Service Account Token Creator on the designated service account.

**C.** Service Account User on the designated service account.

**D.** Service Account OpenID Connect Identity Token Creator on the designated service account.

**Answer: D**

The ID-token-only role contains getOpenIdToken without the additional signing and access-token permissions in Token Creator. Invocation authorization remains a separate requirement.

**Guide mapping:** 1.2; Select narrowly scoped short-lived ID token permission. **Editorial difficulty:** hard.

- **A:** Key administration permits a much more powerful credential path.
- **B:** This works technically but includes capabilities expressly prohibited by the requirement.
- **C:** This permits attachment, not the requested ID token generation.
- **D:** Correct: this is the narrow predefined role for ID token creation.

- [Roles for service account authentication](https://docs.cloud.google.com/iam/docs/service-account-permissions) — Service Account User permits attachment; Token Creator permits short-lived credentials; ID-token-only creation has a narrower role.
- [Create short-lived credentials for a service account](https://docs.cloud.google.com/iam/docs/create-short-lived-credentials-direct) — IAM Credentials creates access tokens and ID tokens with appropriate permissions and token parameters.

Sources checked 2026-11-03. Original author ID: `ACCESS-018`.

---

<a id="q183"></a>
### PCSE200-183 — Choose ONE

A SIEM integration went live today through a new Pub/Sub log sink. The incident team also needs the previous seven days of logs, which still exist in a Cloud Logging bucket. A colleague proposes widening the sink time filter to include last week and waiting for the logs to replay. The SIEM supports batch ingestion of JSON files from Cloud Storage as well as streaming. Which plan correctly handles both time periods? Choose ONE.

**A.** Widen the sink timestamp filter to include last week and replay the Pub/Sub subscription from that timestamp.

**B.** Delete and recreate the sink with the same filter because sink creation replays all retained bucket contents.

**C.** Keep the sink for new arrivals and use a supported historical copy/export workflow from the retained bucket for the seven-day backfill.

**D.** Increase the Pub/Sub subscription retention because that causes old Cloud Logging records to be published to the topic.

**Answer: C**

Sinks route entries as they arrive; they do not retrospectively replay stored history. Retained bucket data can be copied to Cloud Storage for a separate batch process.

**Guide mapping:** 4.2; Backfill retained historical logs separately from streaming export. **Editorial difficulty:** medium.

- **A:** A subscription can replay only messages already published; the new sink never published the older Logging entries.
- **B:** Recreating a sink changes its future routing start, not its historical coverage.
- **C:** This uses distinct mechanisms for streaming new entries and recovering retained history.
- **D:** Subscription retention only applies to messages that entered Pub/Sub.

- [Route log entries](https://docs.cloud.google.com/logging/docs/routing/overview) — Sinks cannot route entries received before creation; retained log data can be copied retroactively to Cloud Storage.

Sources checked 2026-11-03. Original author ID: `OPS-028`.

---

<a id="q184"></a>
### PCSE200-184 — Choose TWO

A research team needs internal hostnames for a new application. Records must be resolvable by the production VPC but must not be published through public DNS. The team proposes a Cloud DNS private zone and asks whether enabling DNSSEC on that zone is also required. No on-premises clients or other VPCs need resolution. Which TWO statements should guide the initial configuration and security review? Choose TWO.

**A.** Create the zone without any authorized VPCs because the containing project's VMs automatically receive private-zone access.

**B.** Enable DNSSEC on the private zone and publish its DS record publicly to keep the records confidential.

**C.** Authorize the production VPC on the private zone so its clients can resolve the internal records.

**D.** Cloud DNS private zones do not support DNSSEC; use their network visibility controls and appropriate administrative access controls.

**Answer: C, D**

Private-zone visibility is controlled by its authorized VPC list. DNSSEC is not supported for these zones and should not be confused with hiding records from public DNS.

**Guide mapping:** 2.1; Configure private DNS visibility and supported security settings. **Editorial difficulty:** medium.

- **A:** A private zone with no authorized networks is not implicitly visible to project VMs.
- **B:** This is unsupported and confuses DNS authenticity with confidentiality.
- **C:** The authorization creates the intended query visibility.
- **D:** This correctly separates product capability and visibility control.

- [Key terms: private zone](https://docs.cloud.google.com/dns/docs/key-terms) — Private zones are queryable only from authorized VPC networks and do not support DNSSEC.

Sources checked 2026-11-03. Original author ID: `NETWORK-018`.

---

<a id="q185"></a>
### PCSE200-185 — Choose ONE

A software vendor uses a hosted CI provider whose OIDC issuer is shared by many customers. Production deployments must accept only the vendor's approved repository, and security is concerned that repository names could later be deleted and reclaimed. The provider supplies immutable numeric repository and owner IDs as signed claims. Which trust configuration best protects the production federation boundary? Choose ONE.

**A.** Match only the token's audience because all customers of the issuer use different repositories.

**B.** Trust any token from the issuer and restrict access only by the text repository name.

**C.** Store a service account key in the approved repository and rotate it when repository names change.

**D.** Map and validate the numeric owner and repository claims, and bind only the approved workload principal set.

**Answer: D**

A shared issuer establishes token provenance, not the required tenant or repository boundary. Immutable numeric identifiers avoid the name-reuse problem documented for deployment federation.

**Guide mapping:** 1.2; Constrain a deployment federation trust. **Editorial difficulty:** hard.

- **A:** Audience validation is necessary but does not by itself prove the approved repository.
- **B:** The issuer is shared and name reuse is an explicit threat.
- **C:** A static key does not implement the requested federation boundary.
- **D:** Correct: stable signed identifiers and restricted IAM bindings narrow the trusted workload.

- [Configure Workload Identity Federation with deployment pipelines](https://docs.cloud.google.com/iam/docs/workload-identity-federation-with-deployment-pipelines) — Restrict shared issuers by attributes; numeric repository and owner IDs resist name reuse.

Sources checked 2026-11-03. Original author ID: `ACCESS-014`.

---

<a id="q186"></a>
### PCSE200-186 — Choose ONE

A company requires a security attestation before GKE deploys an image. Its CI service account can upload images and use the attestation signing key. Every application developer can modify the build configuration that runs as that account. The attestor and enforcement policy are correct, but a review shows that a developer can add a signing step without running the scanner. Which change most directly repairs the trust boundary? Choose ONE.

**A.** Keep signing permissions unchanged and require developers to add a security-approved label to each image.

**B.** Give the same build account a second signing key and require signatures from both keys.

**C.** Move attestation issuance to a separately controlled verifier identity and prevent developer-controlled builds from using its key or impersonating it.

**D.** Move the signing key to another project while retaining the build account signing permission on that key.

**Answer: C**

Admission trusts the attestation issuer. If developer-controlled code can use that issuer, it can assert approval without satisfying the checks. The verifier must own the decision and its signing authority.

**Guide mapping:** 4.1; Protect signing authority from the code being evaluated. **Editorial difficulty:** hard.

- **A:** A label controlled by developers adds no independent authority.
- **B:** Two keys controlled by the same untrusted build do not create independent approval.
- **C:** This removes the path by which application code can manufacture its own approval.
- **D:** A project boundary alone does not help when the same build principal retains signing access.

- [Default Cloud Build service account: trigger privileges](https://docs.cloud.google.com/build/docs/cloud-build-service-account) — Repository writers can influence code executed with the trigger service account privileges.
- [Binary Authorization concepts](https://docs.cloud.google.com/binary-authorization/docs/key-concepts) — Attestors provide the verification identity and multi-project setups support separation of duties.

Sources checked 2026-11-03. Original author ID: `OPS-006`.

---

<a id="q187"></a>
### PCSE200-187 — Choose ONE

A design company hires a specialist partner for a six-month analytics project. Partner employees authenticate to their own OIDC identity provider and need supported Google Cloud console and CLI workflows. They do not need Gmail or other Workspace accounts. The company wants to avoid creating and synchronizing a second user directory while granting access to approved partner groups. Which approach best fits this identity requirement? Choose ONE.

**A.** Provision a dedicated managed Google account for every partner employee and configure SAML SSO for that directory.

**B.** Configure Workforce Identity Federation, map the partner attributes, and authorize the approved federated principals through IAM.

**C.** Issue each contractor a service account identity and grant individual impersonation access through the partner's shared operator account.

**D.** Synchronize every partner employee into Cloud Identity before allowing any Cloud access.

**Answer: B**

Workforce federation supports external people, their IdP authentication, and attribute-based IAM access without synchronized Google accounts. The scenario explicitly does not require Workspace accounts.

**Guide mapping:** 1.1; Select Workforce Identity Federation for external people. **Editorial difficulty:** medium.

- **A:** This is a viable architecture but introduces the second directory lifecycle the company wants to avoid.
- **B:** Correct: this is the intended human-federation use case.
- **C:** This still relies on shared human authentication and substitutes workload identities for workforce federation.
- **D:** Synchronization is a viable different architecture but defeats the explicit directory requirement.

**Service assumption/limitation:** Confirm supported products and workforce feature limitations for an actual deployment.

- [Workforce Identity Federation](https://docs.cloud.google.com/iam/docs/workforce-identity-federation) — External workforce identities can authenticate without synchronized Google accounts; attributes determine IAM access.

Sources checked 2026-11-03. Original author ID: `ACCESS-005`.

---

<a id="q188"></a>
### PCSE200-188 — Choose ONE

Mallow Research's approved requirements specify EU data locations and EU-based Google support personnel for covered support access. It does not require external key custody. The team has verified its services against the relevant package support lists and is choosing a folder's Assured Workloads package. A residency-only package is cheaper, while the EU Data Boundary and Support package explicitly covers the requested support controls. Which choice directly fits the stated requirement? Choose ONE.

**A.** Choose the residency-only package and rely on the support requester's EU email domain to constrain support staffing.

**B.** Choose the residency-only package and use customer IAM conditions to select the geographic location of Google's support personnel.

**C.** Choose EU Data Boundary and Support, validate its scope and conditions, and configure customer IAM separately.

**D.** Choose the residency-only package and add regional CMEK keys as a replacement for provider support-location controls.

**Answer: C**

Residency and support-personnel geography are separate controls. The package with the explicit support boundary fits the requirement.

**Guide mapping:** 5.1; Select a control package with the required support-personnel geography. **Editorial difficulty:** medium.

- **A:** The requester's email domain does not establish the provider staffing control.
- **B:** Customer IAM does not configure the package's provider support assurance.
- **C:** This selects the required package while retaining customer access responsibilities.
- **D:** Regional keys address key handling, not the stated personnel location requirement.

**Service assumption/limitation:** Package names, supported services and personnel conditions can change; validate the selected package before deployment.

- [Assured Workloads control packages](https://docs.cloud.google.com/assured-workloads/docs/control-packages) — Regional data boundaries differ in personnel/support controls; EU Data Boundary and Support combines EU locations with EU-based support.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-021`.

---

<a id="q189"></a>
### PCSE200-189 — Choose ONE

An existing Premium organization has Security Health Analytics custom modules enabled and supported. Its key-management standard requires every in-scope CryptoKey to have rotationPeriod set and no longer than 30 days. A proposed detector checks has(resource.rotationPeriod) AND resource.rotationPeriod > duration("2592000s"). Test fixtures include a compliant key, a key with 60-day rotation, and a key with no rotationPeriod. The latter key produces no finding. The standard has no exemption for omitted rotation. The in-scope resources are symmetric encryption keys that support automatic rotation. A separate inventory check confirms all three fixtures are included, ruling out resource-selection errors. Which correction should the reviewer make before rollout? Choose ONE.

**A.** Change the conjunction to has(resource.rotationPeriod) OR resource.rotationPeriod > duration("2592000s") and deploy after testing the 60-day fixture.

**B.** Return TRUE only when rotationPeriod is present and at most 30 days, because custom modules flag valid resources.

**C.** Flag only periods exceeding 30 days and let a general inventory export establish that every key has been assessed.

**D.** Flag absence OR a present period exceeding 30 days, and test both violating fixtures and the compliant fixture.

**Answer: D**

A custom module emits a finding when its predicate is true. The original conjunction excludes absent values, so the rule must explicitly flag absence as well as an excessive period.

**Guide mapping:** 4.1; Express a complete supported SHA custom-module predicate. **Editorial difficulty:** hard.

- **A:** This flags compliant keys simply because the property exists and does not correctly express the missing-field violation.
- **B:** This reverses the detector and would flag compliant keys.
- **C:** Inventory inclusion does not make a missing rotation period violate a predicate that checks only excessive present values.
- **D:** This matches both ways to violate the stated standard and tests the boundary.

**Service assumption/limitation:** Assumes an existing SHA-enabled supported organization; this is not a claim about new Premium activation.

- [Use custom modules for Security Health Analytics](https://docs.cloud.google.com/security-command-center/docs/custom-modules-sha-create) — Custom modules use CEL and trigger findings when the expression is TRUE; test resource fixtures are supported.
- [Code a custom module for Security Health Analytics](https://docs.cloud.google.com/security-command-center/docs/custom-modules-sha-code) — Resource properties and has checks must match supported API resource definitions.

Sources checked 2026-11-03. Original author ID: `OPS-015`.

---

<a id="q190"></a>
### PCSE200-190 — Choose ONE

Orchid Records uses a Cloud KMS software key in one region to encrypt a custom application's archive envelopes. Its newly approved boundary requires the key material for new archive data to remain in a different region. The application calls Cloud KMS directly and can select a new key resource after a controlled rollout. Historical ciphertext must remain recoverable under an approved migration exception until it is re-encrypted. The team has already identified every archive referencing the old key. One engineer proposes moving the key-owning project to a folder whose name matches the target region. What is the technically sound migration plan? Choose ONE.

**A.** Create a key in the approved location, update the application and migrate historical envelopes under the exception, retiring the old key only after dependency verification.

**B.** Create a key in the approved region, switch new writes to it, and complete destruction of old key versions before migrating retained ciphertext.

**C.** Move the key-owning project and update its IAM conditions; the key's physical region follows the project's effective boundary.

**D.** Rotate the existing key's primary version; all new versions automatically use the folder's approved region.

**Answer: A**

Cloud KMS resources cannot change location after creation. A new regional key and controlled dependency migration meet the stated requirement.

**Guide mapping:** 5.1; Distinguish key locality from project ownership and IAM location. **Editorial difficulty:** medium.

- **A:** This changes locality while preserving recovery during the approved transition.
- **B:** The new key meets locality for new writes, but destroying old key versions before migration makes the retained ciphertext unrecoverable.
- **C:** Project hierarchy changes do not move key material.
- **D:** Rotation does not move the containing key to another location.

- [Cloud KMS locations](https://docs.cloud.google.com/kms/docs/locations) — Cloud KMS and HSM key material is confined to the chosen location and resources cannot move locations after creation.
- [Destroy and restore key versions](https://docs.cloud.google.com/kms/docs/destroy-restore) — Completed destruction of a key version removes its key material and prevents decryption of ciphertext that still depends on that version.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-014`.

---

<a id="q191"></a>
### PCSE200-191 — Choose ONE

Two teams submit managed custom training jobs in one Gemini Enterprise Agent Platform project. The experiments require different Cloud Storage datasets, and neither team should be able to read the other's data through its training container. Both jobs currently use the default training identity. Researchers may submit jobs only with approved runtime identities. Which configuration best provides differentiated data access without splitting every experiment into a separate project? Choose ONE answer.

**A.** Assign a custom runtime service account to each job with only that job's dataset and output permissions.

**B.** Give both researchers access to both datasets but remove their console access after job submission.

**C.** Use one shared service account and put separate service account key files in each dataset bucket.

**D.** Give the shared service agent both datasets and put different bucket names in the job arguments.

**Answer: A**

Custom service accounts provide per-job permissions in the training container. Resource names or console restrictions do not constrain an identity that can call storage APIs.

**Guide mapping:** 3.3; Use per-job runtime identities for managed custom training. **Editorial difficulty:** medium.

- **A:** Per-job identities implement the documented fine-grained access pattern.
- **B:** Researcher console access is separate from training-container runtime permissions.
- **C:** Key files add long-lived credentials while leaving the shared principal's broad authority.
- **D:** Job arguments do not remove the shared identity's ability to reach both datasets.

**Service assumption/limitation:** The current documentation calls this Agent Platform; some APIs and resource identifiers retain Vertex AI names.

- [Use a custom service account](https://docs.cloud.google.com/gemini-enterprise-agent-platform/machine-learning/general/custom-service-account) — Custom training runtime access uses a specified service account and ADC.

Sources checked 2026-11-03. Original author ID: `DATA-041`.

---

<a id="q192"></a>
### PCSE200-192 — Choose ONE

A firewall policy has two overlapping ingress rules within the same policy layer. A higher-priority allow rule has logging disabled; a lower-priority allow rule for a narrower source range has logging enabled. New test TCP connections from that range succeed, but the team sees no corresponding connection records. Routing and Logs Viewer access are confirmed, and propagation time has elapsed. What should the engineer do to obtain evidence without changing the allowed traffic? Choose ONE.

**A.** Narrow the lower-priority logged rule to the exact test source address while leaving both rule priorities unchanged.

**B.** Increase the wait between repeated packets in the same active connection while leaving logging disabled on the winning rule.

**C.** Enable logging on the rule that actually wins evaluation, then retest with new connections.

**D.** Enable VPC Flow Logs and use its connection metadata as proof of which firewall policy rule allowed each test.

**Answer: C**

Logging occurs on the applicable firewall rule. A lower-priority overlapping rule does not produce a second record when a higher-priority rule decides the connection.

**Guide mapping:** 4.2; Diagnose logging on a nonmatching firewall rule. **Editorial difficulty:** medium.

- **A:** More specific matching fields do not outweigh the higher-priority rule in the stated policy layer.
- **B:** Connection timing cannot produce rule logs when the effective rule has logging disabled.
- **C:** This instruments the effective rule while preserving its allow decision.
- **D:** Flow metadata can corroborate the traffic but does not replace the requested effective-rule connection record.

- [Troubleshoot firewall policy rules log issues](https://docs.cloud.google.com/firewall/docs/troubleshoot/firewall-policies-logs) — A higher-priority matching rule without logging prevents a lower-priority logged rule from generating the expected record.

Sources checked 2026-11-03. Original author ID: `OPS-036`.

---

<a id="q193"></a>
### PCSE200-193 — Choose ONE

An application currently uses a software-protected Cloud KMS key for envelope encryption. A new internal requirement demands HSM protection for future wrapping operations and for retained wrapped DEKs. The requirement allows a staged migration, and the team must continue decrypting older recordings during it. An administrator proposes changing the existing CryptoKey's protection level to HSM. Which plan correctly handles the protection-level boundary and continuity requirement? Choose ONE answer.

**A.** Rotate the existing software-protected key and require the next version's cryptographic operations to run in Cloud HSM.

**B.** Create an HSM-protected key, rewrap the retained DEKs through an authorized migration, and retain old-key access until dependencies are verified.

**C.** Create an HSM-protected key for new writes and destroy the software key before migrating historical wrapped DEKs.

**D.** Copy the old wrapped DEKs into a new bucket protected by an HSM CMEK and treat their application wrapping as migrated.

**Answer: B**

Protection level is a key property, not a label that moves existing software versions into hardware. A new HSM key and explicit DEK rewrapping provide migration while preserving access.

**Guide mapping:** 3.2; Change key protection level through a new key and migration. **Editorial difficulty:** hard.

- **A:** Rotation within the same software key does not change its protection level.
- **B:** This changes the wrapping boundary and addresses historical dependencies deliberately.
- **C:** Historical wrapped DEKs still depend on the old key.
- **D:** Bucket encryption adds a storage layer but does not replace the DEKs' existing application KEK dependency.

**Service assumption/limitation:** This scenario is specifically SOFTWARE-to-HSM migration; it does not generalize to every supported external-key protection-level transition.

- [Import a key version into Cloud KMS](https://docs.cloud.google.com/kms/docs/importing-a-key) — Import-only restricts versions to imported material; automatic rotation otherwise generates material in KMS.
- [Envelope encryption](https://docs.cloud.google.com/kms/docs/envelope-encryption) — Local DEKs encrypt bulk data; KMS KEKs wrap DEKs and never leave KMS.
- [Cloud HSM](https://docs.cloud.google.com/kms/docs/hsm) — HSM keys use managed FIPS 140-2 Level 3 hardware through the Cloud KMS interface.
- [Cloud KMS key purposes and algorithms](https://docs.cloud.google.com/kms/docs/algorithms) — The SOFTWARE-to-HSM protection boundary requires a new appropriately protected key rather than ordinary rotation of the existing software key.

Sources checked 2026-11-03. Original author ID: `DATA-036`.

---

<a id="q194"></a>
### PCSE200-194 — Choose ONE

Juniper Analytics must present two evidence bundles: a provider assurance review for services used during the audit period, and evidence that its own workload configurations meet an internal control framework. The organization has an eligible Security Command Center tier and has defined the workload scope. Some requested provider reports are confidential. Which approach best produces the two bundles? Choose ONE.

**A.** Use Compliance Manager's workload findings as provider assurance and attach a current architecture diagram as proof of operating effectiveness.

**B.** Use a current provider certificate for the first bundle and a clean one-time vulnerability scan as the complete workload-control evidence.

**C.** Use Compliance Reports Manager for applicable provider reports; use Compliance Manager assessments and customer operational evidence for workload controls, respecting report-sharing restrictions.

**D.** Use Compliance Reports Manager for both bundles, adding project numbers to the provider reports to establish workload-specific coverage.

**Answer: C**

The sources answer different questions: assurance over provider controls versus evidence over the customer's scoped implementation and operation.

**Guide mapping:** 5.1; Separate provider assurance evidence from customer control assessments. **Editorial difficulty:** medium.

- **A:** Workload findings do not establish the provider audit coverage.
- **B:** A vulnerability scan addresses only a subset of the workload framework.
- **C:** This uses both evidence sources with the appropriate scope and handling.
- **D:** Adding project identifiers does not turn provider reports into customer control assessments.

- [Compliance Reports Manager](https://cloud.google.com/security/compliance/compliance-reports-manager) — The portal supplies provider audit reports and certificates, with confidentiality conditions on some resources.
- [Compliance Manager overview](https://docs.cloud.google.com/security-command-center/docs/compliance-manager-overview) — Framework deployments bind controls to customer resource scope; detective controls detect without preventing; audit controls gather evidence in eligible tiers.

Sources checked 2026-11-03. Original author ID: `COMPLIANCE-008`.

---

<a id="q195"></a>
### PCSE200-195 — Choose ONE

A historical Cloud Storage archive uses customer-supplied encryption keys held by the company's archive application. A new pipeline must read the archive through Storage Transfer Service, and the application still has all required keys. A design review proposes granting the transfer identity bucket access and assuming it will retrieve the supplied keys from Cloud KMS. The team wants a supported managed-transfer path. What should it do before relying on that pipeline? Choose ONE answer.

**A.** Change only the bucket's default encryption key to CMEK and start the transfer for all historical objects.

**B.** Use a supported rewrite process with the supplied keys to migrate objects to an encryption option supported by the transfer service.

**C.** Store the supplied key in Secret Manager and grant the managed transfer identity access to that secret.

**D.** Create new CMEK objects but retain the old CSEK objects as the transfer job's source selection.

**Answer: B**

Cloud Storage CSEK requires the actual supplied key for relevant operations, and Storage Transfer Service does not support these objects as CSEK inputs. Migrate through an authorized process before using the managed transfer path.

**Guide mapping:** 3.2; Recognize service-specific CSEK integration limitations. **Editorial difficulty:** hard.

- **A:** Changing the default does not migrate the existing CSEK-encrypted objects.
- **B:** A supported encryption migration removes the documented transfer limitation.
- **C:** Secret storage does not add CSEK support to Storage Transfer Service.
- **D:** The managed job would still encounter the unsupported original input objects.

**Service assumption/limitation:** Supplemental CSEK comparison; this is Cloud Storage behavior, not a claim about all Google Cloud services.

- [Customer-supplied encryption keys in Cloud Storage](https://docs.cloud.google.com/storage/docs/encryption/customer-supplied-keys) — Cloud Storage CSEK requests require customer-supplied key material; transfer service support differs.

Sources checked 2026-11-03. Original author ID: `DATA-029`.

---

<a id="q196"></a>
### PCSE200-196 — Choose TWO

A storage operations team is subject to an organization-level deny rule for a supported deletion permission. An approved emergency service account is listed as an exception principal in that rule, but it has no allow role granting the permission. Its deletion request still fails. Security wants ordinary operations identities to remain denied while enabling only this service account's narrowly scoped task. Which TWO statements should guide the correction? Choose TWO.

**A.** A project allow binding for ordinary operators overrides the organization deny for those operators.

**B.** Grant the emergency account the required permission through an appropriately scoped allow role after checking other applicable denies.

**C.** Excluding the account from this deny rule removes only that rule's denial; other applicable controls still matter.

**D.** The deny exception itself grants the denied permission to the emergency service account.

**Answer: B, C**

A deny exception is not a permission grant. The service account still requires an allow path, and every other applicable deny must also permit the operation.

**Guide mapping:** 1.4; Combine deny exceptions with explicit allow access. **Editorial difficulty:** hard.

- **A:** An applicable inherited deny takes precedence over allow roles.
- **B:** Correct: authorization needs the permission as well as the absence of an applicable denial.
- **C:** Correct: the exception is local to that deny rule's effect.
- **D:** An exception removes a prohibition from this rule; it does not create authorization.

**Service assumption/limitation:** The deletion permission's support for IAM deny is explicitly stipulated.

- [Deny access to resources](https://docs.cloud.google.com/iam/docs/deny-access) — Deny rules can exclude exception principals; an exception is not an allow grant.
- [Deny policies](https://docs.cloud.google.com/iam/docs/deny-overview) — Deny rules apply before allow grants and inherit from organization, folder or project attachment points.

Sources checked 2026-11-03. Original author ID: `ACCESS-043`.

---

<a id="q197"></a>
### PCSE200-197 — Choose TWO

A hospital is adding an analytics project to a service perimeter. Scheduled jobs call multiple supported services, and their full dependency chain is not yet documented. The team must observe likely disruption before enforcing the proposed boundary, but the current production perimeter must remain in effect. It will test representative daily and monthly workflows. Which TWO actions correctly use VPC Service Controls for this rollout? Choose TWO.

**A.** Create an explicit proposed dry-run configuration and inspect its violation logs while retaining the existing enforced configuration.

**B.** Replace the enforced perimeter with an unrestricted one so dry-run violations are easier to interpret.

**C.** Use observed legitimate violations to refine narrow exceptions, retest representative workflows, and deliberately promote the reviewed configuration.

**D.** Treat a dry-run configuration as an active prevention control and report that blocked exfiltration attempts are already denied by it.

**Answer: A, C**

Dry run evaluates the proposed configuration without enforcing it. The existing enforced perimeter remains the preventive control until the reviewed change is explicitly enforced.

**Guide mapping:** 2.2; Validate perimeter changes without treating dry run as enforcement. **Editorial difficulty:** hard.

- **A:** This separates observation of the proposal from existing enforcement.
- **B:** Weakening the existing perimeter is unnecessary and violates the requirement.
- **C:** This uses evidence to refine and safely promote the intended change.
- **D:** Dry-run observations do not mean the proposed boundary denied requests.

- [Dry run mode for service perimeters](https://docs.cloud.google.com/vpc-service-controls/docs/dry-run-mode) — Dry-run configurations log would-be violations without enforcing the proposed perimeter.
- [Best practices for enabling VPC Service Controls](https://docs.cloud.google.com/vpc-service-controls/docs/enable) — Use dry run and actual application traffic to identify and resolve perimeter dependencies before enforcement.

Sources checked 2026-11-03. Original author ID: `NETWORK-030`.

---

<a id="q198"></a>
### PCSE200-198 — Choose TWO

A media platform wants application-layer encryption for multi-gigabyte recordings before placing them in object storage. It needs a central place to audit key use but cannot send each whole recording to the Cloud KMS Encrypt API. Recordings from different customers must not reuse the same data-encryption key. The application already has an approved authenticated-encryption library. Which two design decisions correctly divide bulk-data encryption and central key management? Choose TWO answers.

**A.** Export the Cloud KMS key-encryption key into each worker to avoid remote wrapping calls.

**B.** Store plaintext data-encryption keys beside recordings because object storage is already encrypted.

**C.** Wrap each data-encryption key with Cloud KMS and store the wrapped key with the encrypted recording.

**D.** Generate a fresh local data-encryption key for each recording and encrypt the recording locally.

**Answer: C, D**

Envelope encryption uses locally generated DEKs for bulk data and centrally controlled KEKs to wrap them. The KEK remains in KMS, and persisted DEKs must themselves be encrypted.

**Guide mapping:** 3.2; Design DEK and KEK handling for envelope encryption. **Editorial difficulty:** hard.

- **A:** The KEK should remain centrally protected rather than be exported to workers.
- **B:** Plaintext DEKs undermine the application encryption boundary if the stored bundle is disclosed.
- **C:** A wrapped DEK enables recovery through authorized KMS use without plaintext key storage.
- **D:** A fresh DEK provides the requested per-recording separation without bulk KMS calls.

- [Envelope encryption](https://docs.cloud.google.com/kms/docs/envelope-encryption) — Local DEKs encrypt bulk data; KMS KEKs wrap DEKs and never leave KMS.

Sources checked 2026-11-03. Original author ID: `DATA-022`.

---

<a id="q199"></a>
### PCSE200-199 — Choose ONE

A security team enforces a managed boolean organization constraint at a parent folder. It approves one temporary project exception and an authorized policy administrator sets an explicit non-enforcing override on that project. Reviewers argue that the parent and child settings should merge so the parent's true value always wins, as with a denied value in a list policy. For this supported override, which interpretation is correct? Choose ONE.

**A.** Keep the child policy but expect its non-enforcing value to list-merge with the parent’s enforcing value.

**B.** The explicit supported project override determines this project's behavior; managed constraints are inherited or overridden rather than list-merged.

**C.** Delete the explicit child policy and expect the project to remain non-enforcing despite its enforcing parent.

**D.** Managed boolean constraints always merge true and false values, producing true whenever an ancestor enforces.

**Answer: B**

Managed constraints use inheritance or an explicit override, not the list-value merge model. An authorized project exception does not change the parent or siblings.

**Guide mapping:** 1.5; Interpret a managed-constraint project override. **Editorial difficulty:** hard.

- **A:** That applies list-constraint merging semantics to a managed boolean constraint instead of its supported override behavior.
- **B:** Correct: inspect the effective project policy and govern the approved exception.
- **C:** Removing the override restores applicable inheritance rather than preserving the approved exception.
- **D:** This incorrectly applies list-policy reconciliation to a managed boolean constraint.

**Service assumption/limitation:** The scenario stipulates a constraint and context supporting this authorized override.

- [Hierarchy evaluation](https://docs.cloud.google.com/organization-policy/hierarchy-evaluation) — List organization policies may merge; deny values win; managed constraints are inherited or overridden, not merged.

Sources checked 2026-11-03. Original author ID: `ACCESS-050`.

---

<a id="q200"></a>
### PCSE200-200 — Choose ONE

A company is retiring an older Compute Engine design that uses CSEK-encrypted Persistent Disks. It still holds the source keys and must move to the supported CMEK design. A maintenance window permits replacing disks, and a tested snapshot-based migration is acceptable. The project team proposes editing each existing disk's encryption setting in place. Which plan follows the documented migration model while preserving recoverability during validation? Choose ONE answer.

**A.** Set a project CMEK preference and reattach the original CSEK disks without recreating their data.

**B.** Copy the CSEK disk into another CSEK disk, then update only the copy's key resource reference.

**C.** Create CMEK-encrypted replacement disks from the protected source snapshots using the source keys, then validate and cut over.

**D.** Replace the raw CSEK value with a Cloud KMS resource name on each existing disk.

**Answer: C**

Compute Engine documents replacement resources for migration from CSEK; the existing disk's encryption cannot simply be switched in place. Source keys and controlled cutover remain necessary.

**Guide mapping:** 3.2; Migrate deprecated Compute Engine CSEK resources. **Editorial difficulty:** medium.

- **A:** A preference for new resources does not migrate an existing disk's encryption.
- **B:** The required migration is to a newly CMEK-encrypted resource, not an in-place key-type edit.
- **C:** This follows the snapshot-to-new-disk migration pattern and permits validation.
- **D:** A KMS identifier is not an in-place replacement for the existing disk's CSEK.

**Service assumption/limitation:** Supplemental service-specific CSEK migration. Specific migration and general deprecation pages disagree on dates; no disputed date is tested.

- [Deprecation of CSEK in Compute Engine](https://docs.cloud.google.com/compute/docs/deprecations/csek-deprecation-in-compute-engine) — Compute CSEK is deprecated; migration creates CMEK-encrypted replacement resources.

Sources checked 2026-11-03. Original author ID: `DATA-030`.

---