PCA practice questions and answers

Correct answer: B — Prompt a Gemini model from Model Garden with a few-shot prompt grounded on the company's own classification policy, measure accuracy on a held-out sample, and move to supervised fine-tuning only if the 92% target is missed.

With no labeled data and a two-week deadline, a foundation model that is already trained is the only option that can produce results in days. Grounding the prompt on the company's own classification policy pushes accuracy up without any training run, and token pricing gives a predictable per-document cost. Measuring first tells you whether fine-tuning is even needed. Option A takes months of compute and a very large corpus, so it cannot meet the deadline. Option C spends the entire two weeks labeling before anyone knows if labeling is required. Option D rests on a false claim: base models often clear domain classification targets with good prompting, and fine-tuning as step one adds cost and delay for no measured reason.

Correct answer: C — Create an IAM deny policy on the folder that denies the release approval permissions to the build engineers group, and grant the approval role only to a separate release managers group.

IAM deny policies are evaluated before allow policies, so a deny rule blocks the release approval permissions for the build engineers group even though those permissions arrive through an inherited Editor grant. Pairing that with the approval role granted only to release managers gives a clean separation of duties. A is heavy-handed and fragile: it breaks other teams and any future Editor grant re-opens the hole. B is the tempting answer, but a condition scopes where the role applies, and the engineers would still hold approval permissions on anything that matches the tag. D grants exactly the permission the audit forbids and replaces prevention with detection.

Correct answer: B — Create a Filestore instance on the Regional service tier and mount it over NFS from the pods and the VMs.

The Filestore Regional service tier serves NFS, which gives full POSIX semantics including file locking, it scales well past 20 TiB, and it replicates data across zones in the region so the share survives the loss of one zone. Cloud Storage FUSE (option A) puts a file interface on object storage: there is no real file locking, directory renames are not atomic and metadata operations are slow, so a POSIX application breaks or corrupts data. Filestore Basic SSD (option C) gives the right protocol but lives in one zone, so it fails the zone-loss requirement. Multi-writer Hyperdisk (option D) shares a raw block device with a small number of instances and needs a cluster file system on top; mounting one ext4 volume read-write from many clients corrupts it, and it is not a shared POSIX share for pods across nodes.

Correct answer: B — Add resource limits for the GPU accelerator type to the cluster's node auto-provisioning configuration so it is allowed to create GPU node pools.

Node auto-provisioning only creates node pools for resource types that appear in its resource limits. If no limit is set for the accelerator type, for example nvidia-l4, NAP will never provision a GPU node pool and the pods stay Pending forever. Option A is unnecessary: GKE adds the GPU toleration automatically to pods that request nvidia.com/gpu, so the missing toleration is not the blocker. Option C is a real requirement on some node images, but with zero GPU nodes in the cluster the DaemonSet has nothing to install on. Option D fails because Autopilot GPU pods still need a cloud.google.com/gke-accelerator node selector and both requests and limits, so the unchanged spec will not schedule there either.

Correct answer: C — Buy three-year resource-based commitments in europe-west1 for the steady baseline only, and serve the peaks with autoscaled on-demand instances and Spot VMs where work can be retried.

Commitments should cover only the capacity that is always running, because you pay for a commitment whether or not you use it, and the variable top is cheaper on demand or, for retryable work, on deeply discounted Spot VMs. A and B both commit to peak capacity, so the company pays for the peak 24 hours a day; B also takes the smaller flexible discount rate for the baseline it could have covered at the higher resource-based rate. D is wrong on a hard fact: a resource-based commitment is tied to a region and machine family and cannot be moved or cancelled, and only a flexible spend-based commitment travels across regions and families in exchange for a lower discount. Sustained use discounts apply automatically to eligible on-demand usage and never to committed or Spot usage, so they are a bonus, not a plan.

Correct answer: C — Enable IAP on the backend service, grant IAP-secured Web App User to the employee group, bind an Access Context Manager access level that requires a Chrome Enterprise Premium device policy plus the approved regions, and add an ingress firewall rule that allows TCP 22 from 35.235.240.0/20.

Identity-Aware Proxy checks identity and authorization before the request reaches a backend, and a Chrome Enterprise Premium access level adds context: an Endpoint Verification device policy proves the laptop is corporate managed, and region conditions restrict the country. For shell access, IAP TCP forwarding tunnels SSH from the range 35.235.240.0/20, so an ingress rule for that range on port 22 removes any need for external IPs. Option B only checks IP, so an unmanaged personal laptop inside an approved country still gets in, and adding external IPs re-exposes the VMs. Option A opens SSH to the whole internet, and a Cloud Armor policy protects HTTP(S) load balancer traffic, not SSH sessions. Option D keeps the VPN the company is trying to retire.

Correct answer: C — Pilot light: a cross-region Cloud SQL replica kept in sync in us-west1, images and Terraform ready, and application instances started only at failover.

Pilot light keeps only the expensive-to-rebuild part warm, which is the data. The cross-region Cloud SQL replica streams changes continuously, so the RPO stays in minutes, and starting instances from prepared images with Terraform fits comfortably inside 4 hours. Backup and restore fails the RPO because a nightly backup can lose a full day of orders. Warm standby and hot multi-region both meet the numbers easily, but each pays for idle compute every hour of every year, and the requirement asks for the lowest steady-state cost among the options that qualify. Whatever the pattern, the failover must be tested on a schedule, because an untested DR plan does not have an RTO, only a hope.

Correct answer: B — It can summarize an incident using the project's own logs and metrics, suggest likely causes, draft gcloud commands and Terraform configuration, and give cost and design recommendations, but an engineer must review and test every suggestion before it goes through the normal deployment pipeline.

Gemini Cloud Assist is grounded in the customer's own environment, so it can help investigate an incident from that project's logs and metrics, propose likely causes, draft gcloud commands and Terraform, and surface cost and design recommendations. What it does not do is change anything for you: its output is a suggestion that an engineer reviews, tests and then promotes through the same code review and deployment pipeline as any hand-written change. Option A describes autonomous remediation, which the product does not perform and which would bypass change control. Option C understates it, because the assistant does have context on the resources in the project. Option D is wrong: no fine-tuning step is required to use it.

Correct answer: C — Setting PUBSUB_EMULATOR_HOST, FIRESTORE_EMULATOR_HOST, SPANNER_EMULATOR_HOST and BIGTABLE_EMULATOR_HOST makes the standard client libraries talk to the emulators, but the emulators do not enforce IAM, do not apply production quotas and do not reproduce production performance.

Each emulator is picked up by the normal client library through its own environment variable, so no application code changes and no credentials are required. That is why option A and the key file half of option B are wrong, and emulators are free to run, which kills the rest of option B. The important limitation for an architect is what the emulators leave out: they accept any caller without checking IAM, they do not apply production quotas or rate limits, and their latency and throughput say nothing about production, so permission tests and load tests must still run against real services in a test project. Option D claims the opposite of that behaviour.

Correct answer: B — Enable the high availability configuration so the instance has a synchronous standby in a second zone of europe-west1.

Cloud SQL high availability writes every transaction synchronously to a standby in a second zone of the same region, so a zone failure loses nothing (RPO = 0) and the automatic failover finishes in about a minute. A cross-region read replica replicates asynchronously, so promoting it can lose the last transactions in flight, which breaks RPO = 0, and promotion is a manual step. Point-in-time recovery and backups both create a brand new instance from stored data, which takes far longer than 5 minutes. Note the limit of the correct answer: HA protects against a zone failure, not a whole-region failure. Surviving the loss of europe-west1 still needs a cross-region replica, and that design cannot offer RPO = 0.

Correct answer: A, D — In the IAM audit configuration, turn on Data Access audit logs with the DATA_READ log type for Cloud Storage. · Create an organization-level aggregated sink that exports the audit logs to a Cloud Storage bucket that has a locked retention policy.

Data Access audit logs are disabled by default for Cloud Storage because of their volume, so DATA_READ must be turned on explicitly in the IAM audit configuration before object reads are recorded at all. Immutability then comes from an organization-level aggregated sink into a Cloud Storage bucket protected by a locked retention policy: once the policy is locked it cannot be shortened or removed, and objects cannot be deleted before their retention expires, not even by an owner. Option B is not a step anyone needs to take, because Admin Activity audit logs, which include IAM policy changes, are always written and cannot be turned off. Option C only changes a retention setting that an administrator can lower again later, so it is not tamper-evident. Option E records network flows, not who read which object.

Correct answer: B — Start with the Cloud Monitoring dashboard to confirm when and by how much latency changed, then compare Cloud Trace spans before and after that time to find the call that grew, then open Error Reporting for grouped exceptions from that service.

The investigation should move from the symptom to the cause: Monitoring pins the exact start time and size of the regression, Cloud Trace breaks a slow request into spans so the dependency whose span time grew is visible, and Error Reporting then supplies grouped stack traces from that specific service. C is the trap the scenario is built around, because a latency regression often produces no new exceptions at all, so an empty Error Reporting view proves nothing. A is not wrong in principle but reading raw logs across every service without a time window or a suspect span is slow and usually inconclusive. D looks for CPU inside the checkout service, which will not reveal time spent waiting on a downstream call.

Correct answer: A — Deterministic encryption with a KMS-wrapped key, then run a re-identification risk analysis job on the remaining quasi-identifiers such as postcode, age and gender.

Deterministic encryption maps the same input to the same token every time, so referential integrity is preserved and analysts can still join tables, while the key stays wrapped by Cloud KMS and only privileged callers can re-identify. Risk analysis on the remaining quasi-identifiers is the necessary second step, because removing the direct identifier does not stop someone joining postcode plus age plus gender back to a real person. Option B destroys the join: every distinct customer collapses into the same mask. Option C states a false reason. Joins need determinism, not format preservation, and format-preserving encryption adds an alphabet definition and minimum-length constraints for no benefit here. Option D breaks joins on purpose by re-salting per load, and hashing is not reversible.

Correct answer: A — Use Infrastructure Manager when the team wants Google Cloud to run Terraform and manage state and locking without building pipeline infrastructure; each deployment names a service account, and the caller must be allowed to act as it with roles/iam.serviceAccountUser.

Infrastructure Manager is the managed way to run Terraform: Google Cloud executes the configuration, stores and locks the state, and each deployment runs as a service account that you specify and grant the roles the resources need, while the principal creating the deployment needs permission to act as that service account. Running Terraform from a CI job is still fully supported and is the better fit when the team already owns a pipeline and wants plan output in pull requests, so B is false. C is false: there is no automatic conversion, and the templates must be rewritten. D is wrong because downloaded service account keys are a long-lived credential that should be replaced by Workload Identity Federation or service account impersonation.

Correct answer: A — Rehost the database on Compute Engine sole-tenant nodes with node affinity labels and bring the existing per-core licenses, then plan the replatform as a later project.

Sole-tenant nodes give the customer a dedicated physical server whose physical core count is visible and auditable, which is exactly what a per-physical-core BYOL agreement requires, and node affinity labels prove which workloads run on which node. Rehosting needs no application change, so nine months is realistic. Be clear about the money: sole-tenant nodes carry a sole-tenancy premium and are billed per node whether or not the node is full, and the license fee continues until the replatform happens. Option B fails compliance because a multi-tenant VM shares a host, so the vendor cannot count physical cores. Option D has the same problem: a GKE node pool is still multi-tenant Compute Engine VMs unless it is placed on sole-tenant nodes. Option C misses a hard data center exit date, which is not negotiable.

Correct answer: A — Order Dedicated Interconnect at a colocation facility in the same metropolitan area, run the pricing service in the closest region, and create a Private Service Connect endpoint for Google APIs that is advertised to on-premises over the Interconnect, with on-premises DNS forwarding googleapis.com to that endpoint.

Dedicated Interconnect gives a private 10 or 100 Gbps circuit into Google's network from the same metro, which is the only option here with predictable low latency and low jitter, and placing the workload in the nearest region keeps the round trip short. A Private Service Connect endpoint for Google APIs gives a private internal IP that can be advertised over the Interconnect, and on-premises DNS must resolve googleapis.com to that address for the traffic to stay private. HA VPN (option B) still rides the public internet, so latency and jitter vary, and each tunnel is capped around 3 Gbps. Direct Peering (option C) has no VPC attachment and no availability SLA, and it sends traffic to public API endpoints. Option D pushes API traffic out through NAT to the public internet, which is exactly what the requirement forbids, and 100 Mbps is far too small.

Correct answer: A — In Cloud Trace, filter traces to those with latency above 3 seconds and read the span breakdown of those individual requests to see which downstream call or dependency consumed the time.

Cloud Trace stores individual request traces with per-span timing, so filtering on high latency shows exactly which spans in the slow requests were slow, which is normally a downstream RPC, a lock, a retry or a cold start. That is the only tool here that can isolate the tail. Cloud Profiler aggregates CPU and heap samples across the whole population, so a rare slow request is averaged away, and with CPU already low a flame graph will not explain time spent waiting on I/O, which rules out option B. Option C only helps when the symptom is memory growth. Option D re-measures a problem the team has already measured and still never says why.

Correct answer: C — The 99.95% target leaves an error budget of about 21.6 minutes in a 30-day month. The internal SLO should be stricter than the SLA, for example 99.99%, so the team gets warning before the contract is broken.

A 30-day month is 43,200 minutes, and 0.05% of that is 21.6 minutes of allowed unavailability. The SLA is the external promise that carries penalties; the SLO is the internal target, and it should be tighter than the SLA so the error budget burns and alerts fire before the contract is at risk. Option A gets the arithmetic wrong (43 minutes is the budget for 99.9%) and sets the SLO equal to the SLA, which means the team learns it has failed at the same moment the customer does. Option B swaps the two definitions, and CPU utilisation is a resource metric, not a user-facing SLI. Option D uses the correct SLI formula but 4.32 minutes is the budget for 99.99%, not 99.95%.

Correct answer: D — Page on a 14.4x burn rate over a 1-hour window with a 5-minute short window for confirmation, and open a ticket on a 1x burn rate over a 3-day window.

Burn rate says how fast the error budget is being consumed compared to a steady 1x. A 14.4x burn rate held for one hour spends about 2% of the 30-day budget in that hour, which is fast enough to need a human right away, and the short 5-minute window stops a single blip from paging. A 1x burn over three days is slow damage: it deserves investigation but not a 3 a.m. call, so it files a ticket. Option C has the two backwards, because 1x is exactly the budget spend the SLO allows, so it would page constantly, and a 3-day window can never detect a fast outage in time. Option B alerts only after users have already lost the whole month's budget. Option A keeps a symptom that does not map to user pain: high CPU with healthy responses is not an outage, and an outage can happen at low CPU.

Correct answer: C — Deploy a Google Cloud VMware Engine private cloud with at least three nodes, create a private connection between the VMware Engine network and the VPC network, and extend on-premises connectivity with Cloud Interconnect or HA VPN.

Google Cloud VMware Engine gives a dedicated VMware stack with vCenter, vSAN and NSX, so native vSphere APIs and existing tooling keep working and the VMs move without conversion. A production private cloud needs at least three nodes for vSAN resilience, a private connection carries traffic to the VPC network, and Cloud Interconnect or HA VPN carries traffic back to the data center. A works technically but throws away the vSphere API surface and forces the tooling to be rewritten. B is wrong because a single-node private cloud is only for evaluation, has no SLA and a limited lifetime, and Cloud NAT is for outbound internet traffic, not private VPC connectivity. D is unsupported and leaves the bank operating the hypervisor itself.

Correct answer: D — Enable VM Manager, make sure the OS Config agent runs on every VM, and create a recurring patch deployment that selects VMs by label and runs inside a maintenance window.

VM Manager OS patch management is built for exactly this: it needs the OS Config agent on each VM plus the OS Config API enabled, and a recurring patch deployment runs patch jobs on a schedule, targets instances by label or zone, respects a maintenance window, and reports per-VM patch compliance. The reboot behaviour is part of the patch configuration, so you can let it reboot only when an update requires it. The Ops Agent (option B) collects logs and metrics only; it never installs patches, which makes it the most tempting wrong answer. Startup scripts (option A) run only at boot, give no compliance report and no control over timing. Immutable golden images (option C) are a good pattern for stateless managed instance groups, but rebuilding and replacing 4,000 long-lived VMs every week is far more work than a patch policy.

Correct answer: A, D — Create a Private Service Connect endpoint in the consumer VPC that targets the service attachment published by the vendor. · Create a Private Service Connect network endpoint group in the consumer VPC that points at the vendor's service attachment, and put it behind an internal Application Load Balancer.

VPC Network Peering merges the two route tables, so Google Cloud rejects a peering whose subnet ranges overlap, and exporting custom routes does not change that. Private Service Connect solves the problem because the consumer allocates its own endpoint address and traffic is translated on the way to the producer, so the two address plans never have to agree. Both forms work: a Private Service Connect endpoint (A) for a simple forwarding rule, or a Private Service Connect backend behind an internal Application Load Balancer (D) when the consumer wants load balancing and Cloud Armor in front. C fails because Network Connectivity Center spokes also require unique ranges and the hub does no address translation. E is not possible across two organizations, and it would still leave the ranges overlapping.

Correct answer: D — Deploy Migration Center discovery to collect guest and performance data over a representative period, run a performance-based right-sizing assessment and TCO report, and commit only to the steady baseline that the report shows.

Migration Center right-sizing is only as good as its input: without collected CPU, memory and disk performance data it can only echo what was provisioned on-premises, which is usually far larger than what is actually used. Collecting performance data over a representative period produces a right-sized machine shape list and a TCO report, and the steady part of that profile is the safe amount to commit to. A is the classic trap of committing to allocated rather than used capacity. B pays full on-demand price for the whole estate first and delays the discount for months. C over-sizes on purpose and locks that mistake in for three years, since resource-based commitments cannot be cancelled.

Correct answer: A — Move state to a versioned Cloud Storage bucket with the gcs backend, which locks the state object during an apply, then write a matching resource block for core-vpc and bring it in with an import block.

Local state has no sharing and no locking, so two engineers running apply at the same time overwrite each other's state and can destroy live resources; the file also holds resource attributes that belong in a controlled bucket, not a laptop. The gcs backend solves both problems on its own: it stores state centrally and locks the state object for the duration of an apply, so no separate lock table or collection is needed, which is why option C is wrong. Bucket versioning gives a way back if a state write goes bad. For core-vpc, Terraform needs a resource block plus an import, because import records an existing resource in state and never invents the configuration for it. Option B commits secrets to Git and misuses -refresh-only, which only updates state for resources Terraform already tracks. Option D drops locking on an assumption that stops being true the day the team grows.

Correct answer: C — Create public uptime checks for the checkout page from several geographic regions, add a synthetic monitor for the multi-step checkout journey, add a private uptime check for the internal inventory API, and configure the alerting policy to fire only when the check fails from at least two regions for a sustained duration.

Checking from several geographic locations is what makes the signal represent the customer's view rather than the server's, and a synthetic monitor goes further by running the real multi-step journey instead of fetching a single URL. The inventory API has no public address, so it needs a private uptime check that runs inside the network. The false-page problem is solved in the alerting policy: requiring failures from at least two locations and a sustained duration filters out a single flaky probe or a few seconds of deployment noise. Option A pages on one probe from one place, which is the definition of a noisy alert. Option B measures server-side and backend health, so it stays green when DNS, TLS or a CDN path is broken for real users. Option D relies on a human remembering to snooze, and a forgotten snooze hides a genuine outage.

Correct answer: B — Order Transfer Appliance units, copy the data to them on site, and ship them to Google for upload into the bucket.

Do the arithmetic first. A 1 Gbps link carries at most about 10.8 TB per day, so 500 TB needs roughly 46 days even if no other traffic used the link at all, which is more than twice the deadline. Options A and C both put more senders behind the same 1 Gbps bottleneck, so they cannot help. Option D would eventually give enough bandwidth, but ordering, provisioning and turning up a Dedicated Interconnect circuit in a colocation facility takes weeks on its own, so it misses a three-week deadline. Transfer Appliance moves the data offline: two TA300 units (about 300 TB usable each) hold 500 TB, and the on-site copy runs at LAN speed instead of over the WAN.

Correct answer: B, E — Enable execution caching on the pipeline so a step whose inputs and component specification have not changed reuses the output of the previous run. · Create an Eventarc trigger on the Cloud Storage bucket that starts a Cloud Run function, and have that function submit a new pipeline run.

Execution caching is built into the pipeline service: when a step's inputs and its component definition match a previous successful execution, the cached output is reused and the step is skipped, which is exactly the waste the team wants to remove. Eventarc on the bucket's object finalize event, wired to a Cloud Run function that calls the pipeline API, turns a new data batch into a new run with no polling. Option C is wrong about what Model Monitoring does: it watches a deployed model for training-serving skew and drift, and it never controls pipeline step execution. Option D rebuilds caching by hand and then has to be maintained forever. Option A makes one step faster but still re-runs every unchanged step.

Correct answer: C — Adding the 60 projects to the metrics scope of one scoping project lets dashboards and alerting policies in that project use metrics from all of them, but logs are not included, so an aggregated log sink at folder or organization level is still needed.

A metrics scope is the list of projects whose time series a scoping project can read. Once the 60 projects are added, charts, dashboards and alerting policies created in the scoping project can select metrics from any of them, which is what central monitoring means in practice. What the metrics scope does not do is centralize anything else: Cloud Logging is a separate service, so cross-project log search needs an aggregated sink at the folder or organization level pointing at a log bucket or BigQuery, and quotas remain per project and per service. That makes option A and option D false. Option B describes the behaviour you get only when you never configure a metrics scope at all.

Correct answer: D — Four Interconnect connections across two metros, two edge availability domains in each metro, with four VLAN attachments to Cloud Routers in two regions and global routing enabled.

The 99.99% topology needs four connections and four VLAN attachments spread over two metros, with two edge availability domains inside each metro, terminating on Cloud Routers in two regions with global dynamic routing turned on. Option A is the documented 99.9% topology: two edge availability domains protect against maintenance in one domain, but a single metro is still one failure point. Option B adds capacity, not diversity, because it is still one metro and one Cloud Router. Option C has two metros but only one connection in each, so planned maintenance in a single edge availability domain drops a whole metro. For comparison, HA VPN reaches 99.99% with a single gateway that has two interfaces, two peer devices and BGP on Cloud Router, which is why it is often the cheaper way to hit the same number when bandwidth allows.

Correct answer: D — Put both analytics projects in a VPC Service Controls perimeter with bigquery.googleapis.com as a restricted service, add an ingress rule tied to an access level for the corporate network, and add no egress rule for outside projects.

VPC Service Controls is the only control that stops data leaving a boundary, because it checks the source and destination project of every API call, not just whether the caller has permission. With BigQuery restricted and no egress rule allowing the personal project, the copy job is blocked even though the analyst still holds Data Viewer, and the ingress rule with an access level keeps corporate queries working. IAM changes such as option A only decide who may read the data, and the analyst is meant to read it. Firewall rules control network paths, not API-level data movement, and analysts can call BigQuery from anywhere, so option B fails. The resource location constraint in option C limits where resources are created, not where data is copied to.

Correct answer: B — Grant roles/iam.workloadIdentityUser on the service account to principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/ci-pool/attribute.repository/acme-corp/payments-api.

Workload Identity Federation swaps the GitHub OIDC token for a short-lived Google credential, so no key file exists anywhere. The impersonation binding must be roles/iam.workloadIdentityUser on the service account itself, and the member must be a principalSet scoped by the mapped attribute, so only workflows from acme-corp/payments-api can impersonate it. Option C uses the pool-wide principalSet, which lets any repository in the org take the production identity, so it is federated but not least privilege. Option D grants token creation at project level, which is broader than one service account, and dropping the attribute condition lets tokens from any GitHub organization reach the pool. Option A keeps the very key the policy bans.

Correct answer: A — Cloud Run, with the service request timeout set to 3600 seconds and minimum instances left at 0.

Cloud Run services accept a request timeout of up to 60 minutes, so a 45-minute request fits, and the service scales to zero between bursts, so idle cost is nothing. GKE Autopilot could run the workload but the team has no Kubernetes skills, and the cluster keeps running (and billing) even when no requests arrive. A managed instance group cannot scale below one instance and boots VMs far too slowly for a sudden burst. App Engine standard is the classic trap here: with automatic scaling a request is killed at 10 minutes, so the 45-minute job never completes.

Correct answer: D — Disabling a key version makes objects encrypted with that version unreadable until it is enabled again, while a destroy request starts a waiting period, 30 days by default, during which the version can still be restored.

Disabling is reversible and only blocks cryptographic operations, so the data is intact but cannot be decrypted until the version is enabled again. Destroying is delayed on purpose: the version moves to a scheduled-for-destruction state for a configurable waiting period, 30 days by default, and can be restored until it expires, after which the ciphertext is unrecoverable. A is the common misconception: rotation only changes which version encrypts new data, and old versions must stay enabled to read old data. C confuses disabling with destruction. B misstates Cloud External Key Manager, which is for keys that must be held and controlled in an external key management system outside Google Cloud, not for a rotation schedule.

Correct answer: C — Spanner with the nam-eur-asia1 multi-region instance configuration and the default strong reads.

Only Spanner gives external consistency, which is the guarantee that every client sees transactions in true commit order, and it splits data across servers so write throughput grows by adding nodes. The nam-eur-asia1 configuration places voting replicas on three continents, which is exactly why it costs more per node than a regional config, and that premium buys the global consistency and the 99.999% availability SLA. Cloud SQL and AlloyDB both have one writable primary, so writes do not scale horizontally, and their cross-region replicas are asynchronous, so remote readers can see stale data. Bigtable with multi-cluster routing is eventually consistent across clusters and has no cross-row transactions, which a ledger needs.

Correct answer: D — Use the Document AI Invoice parser for the standard fields, and uptrain it or add a Custom Extractor only for the purchase requisition code.

The Invoice parser is a prebuilt processor that already extracts invoice number, date, supplier, line items and totals across many layouts, with per-field confidence scores and no training data at all. Only the one non-standard field needs custom work, so the labeling effort drops to a handful of documents from three suppliers. Option C discards a pretrained model that already solves 95% of the problem and buys a large labeling and retraining burden. Option B is the most fragile choice: regular expressions over raw OCR text break whenever a supplier moves a box. Option A can work, but it gives no per-field confidence out of the box, costs tokens on every page, and the team has explicitly signed up to maintain prompts per layout, which is the opposite of least maintenance.

Correct answer: C — Attach VerifyAPIKey to identify the partner app, a Quota policy for the 1 million monthly allowance, and a SpikeArrest policy to smooth traffic to 50 per second.

The three policies do different jobs. VerifyAPIKey identifies which partner app is calling so the counter can be kept per partner. Quota counts requests against a contract over a long interval such as a month and returns 429 once the allowance is used. SpikeArrest does not count anything: it shapes the instantaneous rate, smoothing bursts so the backend never sees more than 50 per second. Option A fails because Quota is a counter, not a traffic shaper, and a per-second quota would also make monthly reporting impossible. Option B fails because SpikeArrest keeps no running total, so a partner could exceed the contract and nothing would stop it. Option D adds identity and caching but leaves both the burst problem and the contract limit unenforced.

Correct answer: C — Deploy a single global external Application Load Balancer with backend services in all three regions, enable Cloud CDN on the backend services, and attach a Cloud Armor security policy.

A global external Application Load Balancer gives you one anycast IP address announced from every Google edge location. It picks the closest healthy backend and shifts traffic between regions inside the load balancer, so failover does not wait for any DNS record to change. Cloud CDN and Cloud Armor attach to the backend services of an HTTP(S) load balancer, which this design provides. Option A gives each region its own IP address and makes failover depend on DNS TTLs and resolver caches, which can hold a dead region for minutes. Option B fails because Cloud CDN cannot be enabled on a passthrough Network Load Balancer, which does not terminate HTTP. Option D still puts the failover decision in DNS.

Correct answer: C — Create a Model Armor template that enables prompt injection and jailbreak detection, Sensitive Data Protection screening and malicious URL detection, then screen the user prompt before the model call and screen the model response before returning it.

Model Armor is the managed screening service for generative AI traffic. You define a template with the filters you need, then call it twice: once on the user prompt before it reaches Gemini, and once on the model response before it reaches the customer. That covers prompt injection, jailbreak attempts, sensitive data and malicious URLs without writing detection logic yourself. Cloud Armor (option A) is a network and web application firewall; the similar name is the trap, but it inspects HTTP requests, not prompt content. The model's built-in safety filters (option B) block harmful content categories such as harassment or hate speech; they are not designed to catch prompt injection or data leaking out in a response. Option D is custom code that regular expressions will never keep up with, and it screens only the prompt, leaving the response unchecked.

Correct answer: B — Write every reading to Bigtable using a row key of device ID plus a reversed timestamp, and use a Bigtable change stream with the Dataflow template that writes to BigQuery for analytics.

Bigtable is built for very high sustained write rates and single-digit millisecond key lookups, and a row key of device ID plus reversed timestamp puts the newest reading for a device first. Bigtable is poor at ad-hoc SQL, so a change stream feeding BigQuery gives analysts the history without a second write path in the application. A is wrong because BigQuery point lookups take seconds and each one scans and bills data. C fails on scale: Firestore is a document store for application state, not a 500,000 writes per second time-series sink. D is wrong because a single Cloud SQL primary cannot take that write rate at all.

Correct answer: D — Apply a team label to every resource, enable the detailed usage cost export to BigQuery, build per-team views and a dashboard on that data, and create budgets that publish notifications to Pub/Sub at the 80% threshold.

The detailed usage cost export writes resource-level rows including labels into BigQuery, which is what lets you attribute cost correctly even when several teams share one project. Budgets publish to a Pub/Sub topic, so the 80% signal can be routed to chat, email or a ticket without anyone watching a console. Option C is the classic trap: a Cloud Billing budget is an alerting tool only and never blocks spend. Actually capping spend means writing automation that disables billing on the project, which takes every service in that project offline. Option A creates 40 billing accounts to administer and still cannot split a shared project. Option B is not defensible chargeback because headcount has no relationship to consumption.

Correct answer: A — Add a shutdown script that writes the current checkpoint to Cloud Storage, because the VM gets roughly 30 seconds after the preemption notice before it is stopped.

Compute Engine sends a preemption notice and then gives the guest about 30 seconds before the instance is stopped, which is exactly the window a shutdown script should use to flush a checkpoint to durable storage such as Cloud Storage. B is impossible: Spot VMs must use the TERMINATE host maintenance policy and are never live migrated. C confuses Spot with the old preemptible 24-hour limit; Spot VMs have no fixed maximum runtime and a scheduled restart does not protect anything. D is wrong because a recreated instance starts with empty memory, so without an external checkpoint the six hours of work are lost. Spot is the wrong choice when the job cannot be interrupted or restarted, or when guaranteed capacity and an SLA are required.

Correct answer: A, C — Configure the delivery pipeline stage with a canary deployment strategy and enable deploy verification, so each traffic percentage phase runs a verify job that checks error rate and latency before the next phase is promoted. · Create a Cloud Deploy automation with a repair rollout rule whose repair phase is rollback, so a failed rollout returns to the last successful release without a human.

The canary strategy splits traffic in defined percentage phases on both GKE and Cloud Run targets, and deploy verification runs a verify job as part of the rollout, which is where the error rate and latency checks live. Together they give a metric-verified canary. The automation repair rollout rule is what turns a failed rollout into an automatic rollback to the last successful release, so no engineer has to act. Option D reimplements rollback outside the delivery pipeline, which means two systems can disagree about the current release. Option E controls how pods are replaced inside a single Kubernetes rollout and does nothing about traffic percentages, verification or rollback, and it has no Cloud Run equivalent. Option B only buys time for a manual cancel, which is not automatic rollback.

Correct answer: B — Run a canary: send 1% of traffic to the new version, then 10%, then 50%, with rollback triggers agreed in advance on error rate and p99 latency compared to the current version, scheduled before the freeze window and approved by the change advisory board.

A canary exposes a small slice of real customers first, so a regression is contained to roughly 1% of traffic instead of all of it. The rollback triggers must be objective numbers agreed before the release, such as error rate above the current version by a set margin or p99 latency above a set threshold, because a human judgement call at 02:00 is slow and inconsistent. Scheduling before the freeze and getting the change advisory board approval keeps the release inside company policy and tells support and finance when to watch. Option A switches every customer at once and uses a subjective trigger. Option C has no traffic isolation and uses customer complaints as the detection signal, which is the slowest signal there is. Option D breaks the freeze and delays the rollback decision by a day.

Correct answer: C — Upgrade a log bucket to use Log Analytics, set its retention to 1,095 days, and run SQL queries against the bucket, linking it to a BigQuery dataset if joins with other data are needed.

A log bucket upgraded for Log Analytics keeps the logs where they already land, supports custom retention up to 3,650 days, and lets the team run SQL directly on the bucket, with an optional linked dataset when the query must join other BigQuery tables. Its cost driver is Cloud Logging ingestion plus per-GB retention beyond the free 30 days; querying is included. A fails the requirement outright: a log-based metric is an aggregate counter or distribution, so the raw entries the investigation needs are gone. B works but adds a second copy and its cost driver is BigQuery storage plus bytes scanned per query, which grows fast at this volume. D is the cheapest to store but the slowest to use, because every investigation begins with a manual load job.

Correct answer: A — Publish the reviewed Terraform modules as Service Catalog solutions, let teams deploy them through Infrastructure Manager, and enforce organization policy constraints such as the one that blocks external IP addresses.

Service Catalog lets the platform team publish versioned, reviewed solutions that product teams can launch themselves, Infrastructure Manager runs the Terraform with a service account instead of human credentials, and organization policy constraints stop a non-compliant resource from ever being created, even if someone edits the input values. Option B gives teams speed but removes the guardrail entirely, and a monthly log review finds violations after the fact instead of preventing them. Option C has the same problem plus human Owner credentials running applies from laptops, which is unauditable. Option D can enforce declarative configuration, but it adds a cluster to run and maintain, gives no curated versioned catalog, and namespace access alone still does not prevent an external IP unless organization policy is set as well.

Correct answer: B — Enable dynamic port allocation on the gateway and set a higher maximum ports per VM.

Because every connection goes to the same destination IP and port, each connection must use its own source port, so the 64 ports per VM run out on the busiest nodes while quieter nodes are fine. Dynamic port allocation lets Cloud NAT raise a node's port count on demand up to the maximum you set, which handles the busy hours without over-allocating the rest of the day. Adding NAT IP addresses raises the pool total but does not raise the per-VM allocation, so the busy node still hits 64. Endpoint-independent mapping does not add ports, and it cannot be enabled at the same time as dynamic port allocation. Giving nodes external IPs throws away the private cluster security posture and does not belong in the fix.

Correct answer: B — Use a Database Migration Service continuous migration job; the outage is set by stopping writes on Oracle, letting the remaining change data drain, and then promoting the AlloyDB cluster and repointing the application.

A continuous Database Migration Service job does the initial full load and then keeps applying change data capture from Oracle, so the replica stays close to the source while the application keeps running. The only outage is the cutover itself: stop writes, wait for replication lag to reach zero, promote the AlloyDB cluster and repoint connections. A is wrong because Datastream plus Dataflow is a data pipeline to an analytics sink, not a managed transactional migration, and you would have to write and own the apply logic. C and D both require a full dump inside the outage window, which for 4 TB means hours of downtime; D is the specific trap of picking a one-time job when only a continuous job gives near-zero downtime.

Correct answer: D — Ramp traffic up gradually over a period longer than the autoscaler cool-down plus instance warm-up time, and watch database connection-pool saturation next to instance count and latency.

An autoscaler reacts to observed metrics and then waits for the cool-down and initialization period before counting a new instance, so the ramp rate has to be slower than the time it takes capacity to arrive, otherwise the test measures warm-up, not scaling. Watching the database connection pool at the same time matters because more instances mean more connections, and Cloud SQL connection limits are very often the real ceiling. A guarantees a latency spike that says nothing about whether autoscaling works. B pins capacity at peak so the autoscaler never runs and nothing is proven. C makes the single client VM the bottleneck and skips the real load balancer path.

Correct answer: B — Coldline storage for the whole five years.

Two reads a year is exactly the access pattern Coldline is priced for. Per GB over 60 months in a standard region, Coldline costs about $0.24 in storage plus about $0.20 in retrieval fees (10 full reads at $0.02/GB), roughly $0.44. Archive stores more cheaply (about $0.07) but charges $0.05/GB to read, so ten reads add about $0.50 and push the total above Coldline. Nearline stores at more than twice Coldline's rate, so its cheaper retrieval does not make up the difference. Option D just adds 30 days of expensive Standard storage on top of the Archive retrieval fees. Minimum storage duration is not the deciding factor here because nothing is deleted early: five years clears Archive's 365-day and Coldline's 90-day minimums, so no early-deletion charge applies to any option.

Correct answer: A, C — Set the constraints/gcp.resourceLocations organization policy on the folder with the allowed value in:eu-locations. · Set the constraints/gcp.restrictServiceUsage organization policy on the folder to deny the services that cannot be limited to EU locations.

The resource location constraint is the control that blocks creation of resources outside the allowed value group, and in:eu-locations covers EU regions and multi-regions. It is paired with the resource service usage constraint so that teams cannot simply switch to a service that the location constraint does not cover. B is the trap: organization policies are not retroactive, so the existing us-central1 buckets keep running and must be found and moved by hand. D is wrong because a VPC Service Controls perimeter limits data exfiltration across a network boundary and has no location setting. E hands the ability to override the policy to the very teams it is meant to constrain.

Correct answer: B, C — Add truncated exponential backoff with random jitter to the client, and cap the total number of retries per request. · Check the quota usage metric for that API in Cloud Monitoring, and request an increase for the specific limit that is being hit through Cloud Quotas.

HTTP 429 and 503 are the API telling the client to slow down, so the two fixes address the two possible causes. Truncated exponential backoff with jitter is the client-side fix: it spreads retries out instead of hammering the API, and the jitter stops all threads from retrying at the same instant. If the backoff is in place and calls still fail, the ceiling is the project quota, so you look at the quota usage metric in Cloud Monitoring to confirm which limit is saturated and raise that limit through Cloud Quotas. Option A is the classic mistake: instant retries add load and make the throttling worse. Option D increases the request rate, which is the direct cause of the 429s. Option E changes local compute, which has no effect on a server-side rate limit.

Correct answer: D — Protect the database with a Backup and DR Service backup plan that writes to a backup vault with enforced retention, and run scheduled restore tests into an isolated project, recording the measured recovery time and data loss.

A backup that has never been restored is an assumption, not a recovery plan. Backup and DR Service gives a backup plan with a defined schedule and retention, and a backup vault whose enforced retention cannot be shortened or deleted by the project's own administrators. The evidence the auditor wants is the record of scheduled restore tests into an isolated project with the actual elapsed restore time and the actual data loss, compared against the four-hour RTO and the 15-minute RPO. Option A makes backups more frequent but still proves nothing about restore time, and a screenshot is not evidence of recoverability. Option B protects against a regional failure but does nothing for logical corruption, which replicates to the replica, and it does not measure RTO. Option C protects exported files from overwrite; it says nothing about whether the database can be brought back inside four hours.

Correct answer: A — Define the steady state as p99 latency below the SLO and error rate below the SLO threshold at normal traffic; in staging, delete every instance in one zone at once; confirm the autohealing health check marks them unhealthy, the regional MIG recreates capacity in the surviving zones, and the SLIs stay inside the steady state; only then repeat in production with a defined blast radius and abort conditions.

A chaos experiment starts with a measurable steady-state hypothesis expressed in user-facing SLIs, runs first where a wrong answer is cheap, and only moves to production once the recovery path is proven and abort conditions exist. Removing an entire zone is the correct way to simulate a zonal outage for a regional MIG, and the thing being proven is that the autohealing health check detects the failure and the group rebuilds capacity in the remaining zones without breaching the SLO. Note that the autohealing health check is separate from the load balancer health check and should be more conservative, because an over-aggressive one causes a restart storm. Option B removes the multi-zone property that the experiment exists to test. Option C has no control group and no safe abort, and CPU utilisation is not a customer-visible signal. Option D checks SSH liveness, not application health, and a one-second threshold will delete healthy instances that are merely slow.

Correct answer: A, C — Enable Binary Authorization on the production cluster with a policy that requires an attestation from a named attestor and denies every other image. · Run Artifact Analysis vulnerability scanning in the pipeline and create the attestation only when no critical vulnerabilities are found.

The two halves have to meet: something must sign an image only after it passes the scan, and something must refuse to run anything unsigned. Artifact Analysis scanning plus a conditional attestation step in Cloud Build is the signing half, and a Binary Authorization policy on the cluster with a require-attestation rule and a default deny is the enforcement half. Without the policy the attestation is just metadata that nobody checks, and without the scan step the policy signs whatever the pipeline produces. Immutable tags stop tag reuse but do nothing about a laptop-built image pushed under a new tag. Image streaming is a start-up performance feature, and Shielded GKE Nodes protect the node's boot integrity, not the provenance of the workload image.

Correct answer: A, D — Enable object versioning on the bucket so overwritten and deleted objects are kept as noncurrent versions. · Set a soft delete retention policy on the bucket so deleted objects can be restored during the retention window.

Object versioning turns a delete or an overwrite into a noncurrent version that any user with storage permissions can restore themselves, which covers the accidental case. A soft delete retention policy covers the malicious case: even a deleted live object, and its deleted versions, stay recoverable for the retention window and cannot be purged early by the attacker. A locked retention policy is wrong because it is irreversible and blocks the legitimate customer deletion requirement. The lifecycle rule in option C shortens the protection window rather than adding protection. Option E hardens access control, but a legitimate credential can still delete, and it gives the data team no way to restore anything.