Question 1

MetroLedger Ltd. runs a Cloud Run service that currently writes plain text to stdout and the security team needs those logs to appear as JSON structured entries in Cloud Logging so that fields can be filtered and exported to BigQuery on a daily schedule. What is the most straightforward way to ensure the application produces structured logs?

Question 2

Which approach best optimizes cost and elasticity for Compute Engine workloads with a predictable baseline and traffic spikes?

Question 3

You are the DevOps engineer for mcnz.com and you need to introduce Binary Authorization for Google Kubernetes Engine so that only images signed by your release process are allowed to run and the setup must be compliant for audits. What configuration should you implement?

Question 4

How should you improve availability for a stateless Compute Engine API that times out during traffic spikes on a single VM?

Question 5

At Nimbus Labs, your payments microservice runs on Compute Engine virtual machines and occasionally sees memory utilization spike above 80% but it typically falls back under 65% within a few minutes. You configured an alert that fires whenever memory exceeds 80% and it generates too many noisy notifications. You need the alert to notify only if memory remains above 80% for at least 9 minutes. What should you configure in Cloud Monitoring?

Question 6

How should you safely validate and roll out Google Cloud organization policy changes without risking production?

Question 7

You are the DevOps Engineer for a fast growing SaaS company that runs its critical workloads on Google Cloud. The team follows SRE principles and wants to standardize how engineers respond to production incidents so that the process reflects recommended practices. Which actions should be included in your incident response approach? (Choose 2)

Question 8

Which Cloud Run deployment approach validates a new revision with partial traffic and enables fast rollback with minimal disruption?

Question 9

Your GCP project hosts a microservices application on GKE that uses Anthos Service Mesh for traffic control and visibility, and customers are reporting slower responses. You suspect that mesh policies like retries, timeouts and circuit breaking are contributing to the slowdown. Which actions would help you tune performance and use mesh telemetry to pinpoint the bottleneck? (Choose 2)

Question 10

How should you deploy a stateless GKE service to provide low latency for users worldwide and maintain availability if a region fails?

Question 11

At Orchard Journeys, HTTPS traffic reaches a public Cloud Run service available at https://res-engine-q1w2e3.a.run.app. How can you enable developers to validate the newest revision without exposing it to end users?

Question 12

Which Google Cloud tool provides detailed CPU and memory profiling under realistic load across staging and production to compare algorithm variants?

Question 13

Your team has just finished moving a retail checkout platform to Google Cloud, and a 45 day holiday promotion is approaching. To align with Google recommended practices, what is the first action you should take to get ready for the expected traffic surge?

Question 14

How should you capture per request HTTP latency in Cloud Monitoring and view percentiles and a latency distribution in Metrics Explorer?

Question 15

You are the DevOps engineer for a retail analytics startup named NovaRetail that uses Cloud Build to build and push Docker images to GitHub Container Registry. The source code and the cloudbuild.yaml are stored in a Git repository. After you updated the configuration in a merge request earlier today, the pipeline has not produced any new images for 3 hours. Following Site Reliability Engineering practices that emphasize quick diagnosis and safe remediation, what should you do to resolve this failure?

Question 16

You updated a public API and will keep the legacy version for 60 days with best effort support, so what is the correct sequence to introduce the new version and retire the legacy version?

Question 17

You are the platform engineer at Kinetix Books and you run about 180 pods across four namespaces on a regional Google Kubernetes Engine cluster with three node pools. You must monitor CPU and memory usage at the cluster and workload levels so that you can rightsize resources and reduce cost. Which approach should you use to get clear visibility into resource utilization in Google Cloud?

Question 18

Which pipeline approach on Google Cloud enables independent build, test, and deploy for separate frontend and backend repositories while keeping configurations isolated?

Question 19

A mobile commerce team at ArtisanCo runs a latency critical API that reads product and session data from Cloud Spanner. During busy periods the service handles about 12,000 read requests per second and product pages must respond under 30 milliseconds at the 95th percentile. You need to reduce read latency without changing the database schema. What should you do?

Question 20

What update strategy should you use on Compute Engine to patch a critical vulnerability while maintaining service continuity and minimizing risk?

Question 1

The correct option is Use the Cloud Logging client library in the application so that it emits structured entries that populate jsonPayload.

This approach lets your code send structured log entries that appear under jsonPayload in Cloud Logging. Cloud Run automatically captures logs from your container and forwards them to Cloud Logging. Entries created this way retain structured fields such as severity, labels and trace context. This makes it simple to filter on individual fields and to export with a Log Router sink to BigQuery on a schedule.

Add a Fluent Bit sidecar to the Cloud Run service and configure a JSON parser to forward structured entries to Cloud Logging is incorrect because Cloud Run already captures stdout and integrates natively with Cloud Logging. Adding a sidecar introduces unnecessary operational complexity without improving how Cloud Run produces structured logs.

Bundle the Ops Agent in the container image and configure it to convert stdout lines to JSON before sending to Cloud Logging is incorrect because the Ops Agent is intended for Compute Engine and GKE hosts and is not supported in Cloud Run. Bundling it would add complexity and still would not provide native structured entries in Cloud Logging.

Create a Log Router sink to Pub Sub and run a Dataflow pipeline to transform text logs into JSON and route them to another destination is incorrect because it adds multiple components and only transforms logs after they leave Cloud Logging. You can export directly to BigQuery from Cloud Logging and transforming in Dataflow is unnecessary when the application can emit structured logs at the source.

Question 2

The correct approach is Purchase resource based CUDs for baseline vCPU and RAM and use autoscaling with custom metrics for spikes.

This option aligns committed discounts with the predictable baseline so you lock in lower prices for steady vCPU and memory usage across machine types in the same region. It preserves elasticity because the managed instance group can scale out for bursts by reacting to custom metrics such as request rate or queue depth rather than only CPU. You avoid paying for idle capacity while still meeting performance during traffic spikes.

Move all workloads to Spot VMs is not suitable for a steady baseline because Spot instances can be preempted at any time and may be unavailable during capacity constraints. This undermines reliability and does not guarantee the baseline is always met.

Maximize CUDs for all capacity and disable autoscaling removes elasticity and leads to overprovisioning. You would pay for peak capacity even when demand is low and you risk underperforming if traffic exceeds the fixed capacity.

Use specific CUDs for all machine types and keep fixed instance counts is less flexible than resource based commitments because it ties discounts to exact machine shapes and it also removes elasticity. Specific machine type commitments are largely legacy and are less likely to be recommended for new purchases compared to resource based commitments that apply across machine types.

Question 3

The correct option is Enable Binary Authorization on the GKE cluster, create an attestor, and bind it to the appropriate Cloud KMS signing key and an enforcement policy.

This configuration enforces that only images signed by your release process can be admitted to the cluster. Enabling Binary Authorization activates admission control that checks image signatures at deploy time. Creating an attestor that references a Cloud KMS key establishes a cryptographic trust root that can verify signatures produced by your pipeline. Defining and enforcing a Binary Authorization policy ties it together by requiring valid attestations from that attestor before pods are allowed to run, which also provides strong auditability through Cloud Audit Logs and KMS key usage records.

Use only an Organization Policy constraint to limit images to Artifact Registry and do not create attestors or KMS keys is incorrect because restricting the image source does not validate signatures. It prevents images from unapproved registries but it does not provide cryptographic verification or detailed attestation evidence for audits.

Enable Binary Authorization on the GKE cluster and keep the default policy without configuring any attestors is incorrect because the default policy does not enforce signature verification and typically allows all images. Without an attestor and a policy that requires its attestations, unsigned or unverified images can still run.

Enable Binary Authorization on the GKE cluster, create an attestor, and configure it with a Google service account and a policy is incorrect because an attestor must be backed by a public key such as one in Cloud KMS or a PGP key. A service account alone is not the cryptographic trust anchor that Binary Authorization uses to verify signatures.

Question 4

The correct option is Regional managed instance group across zones with an external HTTP(S) Load Balancer.

A regional MIG places instances in multiple zones within a region so the service remains available if a zone has problems. The workload is stateless which fits horizontal scaling and lets autoscaling add more instances during spikes. The external HTTP(S) Load Balancer distributes requests to healthy backends across zones and uses health checks and connection management to reduce timeouts and prevent a single instance from becoming a bottleneck.

The Larger machine type option only scales a single VM vertically and does not add redundancy. It keeps a single point of failure and can still time out during large spikes and it does not protect against zonal issues.

The Zonal managed instance group with autoscaling option can add instances during spikes yet all instances stay in one zone which limits availability. A zonal MIG is vulnerable to a zone outage or resource exhaustion and without a cross zone zonal MIG plus a load balancer there is no distribution across zones to improve resilience.

Question 5

The correct option is Create a metric threshold condition that evaluates the mean over a 9 minute window and triggers when memory stays above 80%.

This configuration evaluates memory utilization over a rolling nine minute window and smooths brief spikes so the alert fires only when utilization truly remains above the threshold for the desired period. It reduces noise by requiring sustained elevation and aligns with how Cloud Monitoring aggregates data across a window before comparing it to the threshold.

Configure an alert policy with a 9 minute rolling window that uses a metric absence condition is incorrect because metric absence is used to detect when data stops arriving rather than when a metric exceeds a threshold. It does not address high memory utilization and would not solve the problem.

Use a log-based metric for memory usage with an 85% threshold and a 6 minute window is incorrect because memory utilization is already available as a metric from the agent and does not require logs. The threshold and window also do not match the requirement and would still allow noisy alerts.

Set the policy to alert only when three consecutive data points exceed 80% within 9 minutes is incorrect because counting a fixed number of points does not ensure the metric stayed above the threshold for the full period. Cloud Monitoring evaluates sustained breaches through windowed aggregation and condition duration rather than a simple consecutive point count.

Question 6

The correct option is Separate organizations for test and production.

Organization policies are evaluated at the organization node and inherited by all child folders, projects, and resources. Isolating non production work in its own organization lets you model and validate policy changes without any possibility of affecting production resources. You can then promote only the approved configuration into the production organization once validation is complete.

Staging folder within one organization is not safe because policies from the root still influence everything below and any change at the top can propagate beyond the test area. This does not provide the strict isolation required to protect production.

Separate billing accounts for test and production does not help because billing accounts govern payment relationships and quotas rather than the scope of organization policy. Policy enforcement remains tied to the resource hierarchy and not to billing boundaries.

Incremental rollout down the hierarchy is risky because inheritance means an organization level change can immediately impact all descendants. Adjusting settings gradually at lower levels cannot fully validate the behavior of an organization level policy and can still lead to unintended impact.

Question 7

The correct options are Publish actionable runbooks for common failure modes and keep them under version control and Adopt blameless postmortems that focus on learning and system improvement rather than individual fault.

Runbooks make response consistent and fast because responders can follow clear steps to triage, mitigate, and recover. Keeping runbooks in version control enables peer review, history, and easy rollbacks so engineers can improve them as new failure modes are discovered and ensure everyone uses the latest guidance.

Blameless postmortems drive learning and durable fixes. They emphasize what happened, why it was reasonable at the time, and how to prevent recurrence. This approach encourages honest reporting, better signal about risks, and actionable follow ups that improve reliability without discouraging engineers from escalating or experimenting safely.

Use one monitoring and alerting platform for every service to keep tooling consistent is not required by SRE practices. Consistency in signals, SLO driven alerts, and response processes matters more than a single tool. Different services may justifiably use different tools when they provide better coverage or integration as long as alerts are actionable and routed reliably.

Skip post-incident reviews for lower severity alerts to reduce meeting time undermines learning. SRE recommends postmortems for any incident that breaches or risks SLOs and lightweight reviews or aggregated analyses for smaller issues. Even minor incidents can reveal systemic gaps that benefit from short reviews and targeted improvements.

Depend entirely on Cloud Functions to automatically remediate all production incidents without human oversight is unsafe. Automation is encouraged to reduce toil and speed well understood remediations, yet humans must review ambiguous situations, own decisions, and improve automation incrementally with guardrails and rollbacks.

Question 8

The correct option is Blue green on Cloud Run with revisions and traffic split.

This approach uses Cloud Run revisions to deploy a new version alongside the current one and splits a small percentage of traffic to the new revision. You can observe performance and errors while most users remain on the stable version. If problems arise you can instantly shift traffic back to the previous revision which provides a fast rollback with minimal disruption.

Migrate to Managed Instance Groups is not appropriate because it relies on Compute Engine virtual machines rather than Cloud Run. It does not use Cloud Run revisions or native traffic splitting so validating a new revision with partial traffic and instant rollback is not straightforward.

Enable automatic rollback in Cloud Run is incorrect because Cloud Run does not provide a simple automatic rollback switch. Rollbacks are performed by adjusting traffic between revisions which is a deliberate action rather than an automatic feature.

Use Cloud Deploy with manual approvals alone does not guarantee partial traffic validation or fast rollback. While Cloud Deploy can orchestrate Cloud Run releases you still need to configure traffic splitting between revisions in Cloud Run to achieve partial validation and quick rollback, and the option does not state that.

Question 9

The correct options are Use Cloud Operations to review Anthos Service Mesh and Istio telemetry with built-in dashboards and Enable Cloud Trace with a suitable sampling rate to capture cross service traces and analyze latency.

Use Cloud Operations to review Anthos Service Mesh and Istio telemetry with built-in dashboards is right because Anthos Service Mesh exports rich metrics from Envoy and Istiod into Cloud Monitoring. You can use the built in dashboards to visualize request volume, error rate, and latency per service and workload. You can also inspect retry counts, timeouts, and outlier detection effects to see whether mesh policies are adding latency or causing cascading retries. This helps you correlate symptoms with specific services and policies and quickly narrow the performance bottleneck.

Enable Cloud Trace with a suitable sampling rate to capture cross service traces and analyze latency is right because distributed traces let you follow a request across hops and measure the time spent in each span. When tracing is enabled for the mesh you can see where retries are issued, which service or call is slow, and whether a timeout or circuit break is triggered. Adjusting the sampling rate gives you enough visibility without excessive overhead and you can temporarily increase sampling during investigations to capture more end to end traces.

Scale each Deployment by increasing the number of replicas for every microservice is not appropriate as a first step because it does not identify whether mesh policies are the root cause and it may amplify retry storms and increase cost without improving latency. You should use telemetry and traces to isolate the cause before changing capacity.

Enable Cloud CDN in front of your internal service to cache API responses is not suitable for internal microservice traffic. Cloud CDN is designed for content served through external HTTP load balancers and many internal APIs are dynamic and unsafe to cache. This will not help diagnose or fix mesh policy induced latency.

Raise the memory limits for all containers that participate in the mesh is not targeted at the suspected problem. Increasing memory does not address delays caused by retries, timeouts, or circuit breaking and may reduce cluster efficiency and increase costs if memory is not the bottleneck.

Question 10

The correct option is Multi region GKE with global HTTP(S) load balancing.

This design deploys your stateless service in more than one region and uses the global HTTP(S) load balancer to present a single anycast IP to users around the world. The load balancer directs requests to the closest healthy backend which minimizes latency and it automatically shifts traffic to another region if one region fails. In GKE you can implement this with Multi Cluster Ingress or the Gateway API so the global load balancer can target backends in multiple regions. Because the service is stateless you can run identical replicas in each region and avoid session affinity concerns.

Single region GKE with global HTTP(S) load balancer keeps all backends in a single region which cannot deliver consistently low latency for users on other continents and it does not meet the availability requirement if that one region experiences an outage.

Cloud DNS geo routing to one regional GKE backend still concentrates traffic in a single region and relies on DNS decisions that are affected by TTL caching which delays failover. It lacks fast health checked routing at the application layer and does not provide cross region resilience.

Question 11

The correct option is Run gcloud run deploy res-engine –no-traffic –tag qa and test using https://qa—​res-engine-q1w2e3.a.run.app. This keeps the newest revision isolated from production while giving developers a dedicated tagged URL for validation.

Deploying with no traffic creates the revision without changing the existing traffic split. Applying a tag produces a stable URL that targets that specific revision so developers can test it directly. End users continue to use the main service URL which still routes to the current stable revision until you intentionally shift traffic.

Use gcloud run services update-traffic res-engine –to-revisions LATEST=100 and verify at https://res-engine-q1w2e3.a.run.app is wrong because it moves all traffic to the newest revision and exposes it to end users.

Send requests with an identity token in the Authorization header to https://res-engine-q1w2e3.a.run.app is incorrect because authentication does not select a specific revision. It would still hit the default traffic target and the service is already public so this does not provide an isolated validation path.

Set up a canary with Cloud Deploy that sends 2 percent of traffic to the newest revision while developers test is not appropriate because a canary intentionally sends some production traffic to the new revision which exposes it to users and fails the requirement.

Question 12

The correct option is Cloud Profiler with agents in staging and production.

Cloud Profiler continuously samples CPU and memory usage with very low overhead which makes it safe to run in both staging and production. It lets you capture realistic performance data under actual load and then compare profiles across services, versions, and environments to evaluate different algorithm variants.

Because Cloud Profiler records CPU time and heap allocations down to specific functions and lines, you can precisely identify hot spots and memory growth. Running the agent in both environments allows side by side comparisons so you can validate that an optimization in staging translates to measurable gains in production.

Cloud Debugger snapshots and logpoints targets live debugging by capturing variable state and inserting dynamic logs without redeploying. It does not provide continuous CPU or memory profiling under load or comparative analysis of algorithm variants. In addition, Cloud Debugger snapshots and logpoints has been retired which makes it less likely to appear on newer exams.

Cloud Logging log-based metrics creates metrics from log entries and is useful for counting events and alerting. It does not produce detailed CPU or heap profiles and cannot show code level hot spots to compare algorithmic choices.

Cloud Trace with OpenTelemetry offers distributed request latency analysis and span timelines. While excellent for understanding end to end latency and service dependencies, it does not perform CPU or memory profiling needed to compare algorithm variants at the code level.

Question 13

The correct option is Run a structured load test to benchmark performance and discover scaling limits.

This is the first action that aligns with recommended practices because you need empirical data to set expectations and to reveal bottlenecks before the surge. It validates throughput, latency, autoscaling behavior, and upstream and downstream quotas under realistic traffic profiles. The results inform right sizing, quota and reservation requests, and any configuration or architectural changes that you make next, which reduces risk during the promotion period.

Configure autoscaling policies on the existing Managed Instance Groups or GKE workloads before traffic increases is not the best first step because tuning policies without data can lead to thresholds and limits that do not match real workload characteristics. You should confirm target utilization, instance size, and warm up needs with evidence from tests, then adjust policies confidently.

Replatform the application to Cloud Run and rely on its automatic scaling is risky as an immediate first move before a seasonal spike because a migration adds complexity and time. Even with automatic scaling you still need to understand latency profiles, cold start behavior, and concurrency or quota constraints for your workload, which you establish through testing.

Pre provision additional compute capacity that matches the last peak and includes a growth buffer can increase cost and still fall short if the spike exceeds prior peaks or if bottlenecks are outside compute. Data from tests guides how much to reserve and where to optimize across the stack.

Question 14

The correct option is GAUGE distribution metric with Heatmap.

A GAUGE distribution custom metric lets you record latency samples and have Cloud Monitoring aggregate them into histograms. In Metrics Explorer you can choose the Heatmap chart for distribution metrics and then overlay percentile lines to see p50 p95 and p99. This is the intended way to visualize both percentiles and the latency distribution for per request HTTP timings.

DELTA DOUBLE metric with stacked bar is incorrect because a DELTA DOUBLE stores scalar values rather than a histogram and a stacked bar chart does not provide percentile overlays or a latency distribution.

Cloud Trace is incorrect because it focuses on distributed tracing views rather than Metrics Explorer distribution charts and it does not provide a Monitoring distribution metric with a heatmap for percentiles.

Cloud Monitoring up