Practice Test #1

Incorrect. Moving the application to Compute Engine is unnecessary because Cloud Run already supports Cloud Logging and can call Google Cloud APIs directly, including Error Reporting. The problem is about customizing how errors are reported, not about needing VM-level control or a different runtime environment. Introducing Compute Engine would add operational burden such as instance management, patching, and scaling configuration without providing a unique capability required by the question. On the exam, platform migrations are usually wrong when the existing managed service already supports the needed feature set.

Incorrect. Google Kubernetes Engine is also an unnecessary platform change for this scenario because the application can remain on Cloud Run and still integrate with Error Reporting and Cloud Logging. The requirement is to enrich and control error-reporting data, not to gain orchestration features like sidecars, daemonsets, or custom node-level agents. Migrating to GKE would increase complexity and operational overhead while not being required for service/version attribution or structured error logging. The best practice is to keep the managed serverless platform when it already supports the observability APIs you need.

Incorrect. Keeping the service on Cloud Run is the right direction, but this option is too narrow because it only mentions installing the Node.js Error Reporting client library. The question specifically asks for customized error data handling and explicit service/version control, and the most complete supported mechanism in the answer set is to use the Error Reporting API together with structured Cloud Logging. A client library may help capture exceptions, but the option does not clearly address the full customization and logging design required by the scenario. Therefore, C is not the best answer even though Cloud Run itself is still the correct platform to use.

gcr.io stores images in the US multi-region, not “global.” For a GKE cluster in asia-northeast1, this typically introduces higher latency and potential intercontinental egress compared to an Asia location. While GCR is scalable, the distance can reduce effective aggregate pull throughput and make it harder to meet a strict 10-minute rollout window for 30 nodes pulling 1.5-GB images.

eu.gcr.io stores images in the EU multi-region. This aligns with the Jenkins build agents in europe-west1 for pushes, but the dominant requirement is fast pulls by the production GKE nodes in asia-northeast1. Pulling from Europe to Asia adds latency and cross-region traffic, which can become a bottleneck during concurrent node pulls and increases the risk of missing the deployment window.

A private registry on a Compute Engine VM in asia-northeast1 may be geographically close, but it is not inherently scalable for 30 concurrent large pulls and introduces significant operational overhead (patching, scaling, HA, backups, TLS, auth). It can become a single point of failure and may require load balancing and multi-VM architecture to match GCR’s reliability and throughput.

Managing IAM changes via Terraform pull requests is a strong operational practice (auditable, reviewable, repeatable), but it is not an enforcement mechanism. A user with sufficient permissions could still remove the lien or change IAM directly using the Console, gcloud, or API. The question requires a technical control that guarantees only org-authorized principals can remove the lien, which Terraform workflow alone cannot ensure.

VPC Service Controls creates service perimeters to reduce data exfiltration risk for supported Google APIs. It does not provide a governance control for lien removal or project deletion, and enabling it for container.googleapis.com is unrelated to resourcemanager liens. This option confuses security boundary controls with resource governance controls; it would not meet the requirement to restrict who can remove the lien.

Removing resourcemanager.projects.updateLiens from identities bound directly to the host project is insufficient and fragile. Permissions can be granted through inherited IAM bindings at the folder or organization level, and project-level admins might still be able to adjust IAM depending on their roles. The requirement calls for a centralized, enforceable restriction tied to org-level authority, which is better achieved with Organization Policy.

Incorrect. GitHub Enterprise Packages is not a Google Cloud-native artifact service and does not integrate with VPC Service Controls. Even with centralized identity, it won’t provide Google Cloud repository-level IAM controls, Cloud Audit Logs in the same way, or perimeter enforcement. It also typically requires internet access from gateways unless additional complex networking is built, violating the “no public egress at deployment time” requirement.

Incorrect. Cloud Storage can store binaries, but serving plugins from storage.googleapis.com over HTTPS is not an OCI registry and won’t be uniformly compatible with OCI clients expecting registry endpoints, manifests, and auth flows. While Cloud Storage can be used with IAM and can be placed behind VPC-SC, the solution changes the distribution mechanism and loses OCI-native workflows, making it a poor fit for “remain compatible with OCI clients.”

Incorrect. A self-managed registry on GKE increases operational burden (patching, scaling, HA, backups) and does not satisfy the requirement for VPC Service Controls enforcement because VPC-SC applies to Google-managed services/APIs, not arbitrary workloads. NetworkPolicies and private ingress help, but they don’t provide the same perimeter-based exfiltration protections, unified Google Cloud auditability, or simplified IAM at the repository level.

Synthetic canaries improve detection and alerting, which is useful for observability and faster incident response. However, they do not address the root cause: uncontrolled production changes and intentional load tests that saturate production capacity. Canaries might simply alert you sooner while customers still experience latency and errors. Prevention via environment isolation and gated releases is required to meet the availability/latency SLOs.

A single lower-capacity dev cluster shared by developers and testers reduces cost but fails the requirement to load test at realistic scale. At 25% of production capacity, performance results won’t reflect production behavior (autoscaler thresholds, saturation points, p95 latency). Also, mixing dev and QA workloads increases contention and instability, and it still doesn’t create a safe pre-production gate for configuration experiments and migrations.

Locking down production access is directionally correct (reduce direct changes), but scheduling one controlled update per year is not viable for a real-time payments API. It would block feature delivery, security patching, and urgent fixes, increasing long-term risk. The goal is not to stop change, but to make change safe through CI/CD, testing, approvals, and progressive delivery with rollback.