Practice Test #1

Checking CPU/memory can help diagnose whether the region is overloaded, but it does not immediately restore availability for users currently seeing 502s. Also, 100% 502s across a region often indicates a broader failure (health check, networking, ingress/proxy, endpoint readiness) rather than just resource saturation. In SRE response, mitigation comes before deep metric analysis.

Adding large node pools is a slow, potentially expensive change and is not a first-response action during an active outage. It assumes capacity is the root cause, which is not supported by the symptom (HTTP 502 across the region). Scaling may not fix misconfigurations, network failures, or load balancer/NEG health issues. Prefer traffic shift first, then targeted remediation.

Logs are valuable for root cause analysis (e.g., ingress/controller errors, upstream resets, TLS issues), but they are not the first step when a regional outage is causing total failures and rapid SLO burn. SRE best practice is to mitigate user impact first (traffic reroute), then use logs/metrics/traces to diagnose and implement a permanent fix.

Cloud Debugger is designed for inspecting application state (snapshots) and adding logpoints without redeploying, not for continuous CPU/heap profiling. Emitting debug logs with timing data increases logging volume and overhead, lacks statistically meaningful function-level CPU/heap attribution, and becomes a quasi-custom pipeline for performance analysis. It also doesn’t naturally provide aggregated profiling views over time comparable to Cloud Profiler.

Exposing a /metrics endpoint and using a timing library is closer to custom metrics collection than managed profiling. Cloud Monitoring uptime checks are for availability/endpoint checks and are not intended to scrape Prometheus-style metrics at scale across many pods/namespaces and on-prem servers. Even with Managed Service for Prometheus, you’d still be collecting metrics, not CPU/heap profiles with function-level attribution, and you’d be operating more instrumentation and ingestion components.

A third-party APM agent can provide profiling, but it violates the requirement to avoid building/operating your own metrics pipeline and adds operational complexity (agent management, licensing, data export, storage, and visualization). Exporting to a bucket/database for later analysis is not a managed, integrated profiling experience in Google Cloud and increases cost and maintenance. For the exam, prefer first-party managed observability services when requirements match.

Incorrect. Removing the Organization Policy would resolve the immediate error but breaks compliance and governance requirements. In regulated fintech environments, location constraints are typically mandated for data residency and risk management. The question explicitly requires remaining compliant and keeping secret data only in allowed EU regions, so weakening or removing the guardrail violates the stated constraints and best practices.

Incorrect. Creating the secret with automatic replication is exactly what caused the violation. Automatic replication is treated as a global location because Google controls where replicas are stored, which may include regions outside europe-west1 and europe-west3. Under constraints/gcp.resourceLocations, global resources or resources with non-deterministic placement commonly fail creation.

Incorrect. Adding global to the allowed list would permit automatic replication but would no longer guarantee that secret material stays only in europe-west1 and europe-west3. “Global” implies Google-managed placement that can span beyond the intended regions, undermining strict data residency requirements. This option also weakens organizational governance controls, contrary to the compliance requirement.

Scheduling individual calls is too slow and does not scale when you have multiple stakeholder groups (execs, support, city partners) and only 30 minutes. It also increases the risk of inconsistent messaging and missing key facts. SRE practice favors a single written source of truth (sitrep/ISD) that everyone can reference, with follow-up meetings only if needed for specific audiences.

A full postmortem requires careful data gathering, timeline validation, contributing factor analysis, and action items—none of which can be completed reliably in 30 minutes right after a major outage. SRE guidance is to first stabilize and communicate current status, then produce a blameless postmortem on an appropriate timeline. Sending an incomplete or rushed postmortem can create confusion and erode trust.

A personal apology email from the on-call engineer is not an SRE-recommended first action. It can be premature (facts may still be evolving), can imply blame, and does not provide the operational details stakeholders need to coordinate communications. Apologies and customer-facing statements should be coordinated through established comms processes using verified information from the ISD.

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.