Google Professional Cloud DevOps Engineer

Cloud Trace is designed for distributed tracing: it shows end-to-end request latency and where time is spent across services. It can help diagnose slow requests and identify bottlenecks, but it does not provide authoritative container CPU and memory utilization metrics per Cloud Run revision. Trace data is request-sampled and is not the right source for capacity/right-sizing decisions across all revisions.

Cloud Profiler provides code-level profiling (CPU time, heap, allocations) and is useful to optimize application performance. However, it is not the primary tool for container resource utilization metrics (CPU/memory usage vs limits) across Cloud Run revisions. Also, Cloud Run fully managed does not rely on installing an Ops Agent in the runtime the way VM-based workloads do, making this option mismatched to the requirement.

Logs-based metrics can count occurrences of log patterns and extract numeric fields from logs, but they are not a reliable way to measure actual container CPU and memory utilization. They also depend on the application emitting the right log data, which the question forbids changing. Even with existing logs, inferring utilization is indirect and error-prone compared to Cloud Monitoring’s native Cloud Run metrics.

Updating app-blue to the new version defeats the purpose of blue/green rollback. If the new release is causing failures, promoting it to blue will likely increase blast radius by making both environments run the bad version. It also removes the last known-good deployment, making recovery harder and increasing time to restore service availability.

Rolling back app-green to the previous stable version could restore service, but it is not the fastest and it reduces developers’ ability to debug the failing release because you overwrite the problematic Pods. Blue/green is designed to keep the failing version deployed (green) while shifting traffic back to stable (blue) for immediate mitigation.

Changing the Service selector to only app: my-app would select Pods from both blue and green Deployments (assuming both share app: my-app). This effectively becomes an uncontrolled canary/split traffic scenario, which can continue to cause user-facing errors and create inconsistent behavior. It also complicates debugging and violates the goal of quickly restoring availability.

A pull request trigger can be useful for running tests on proposed changes, but it does not meet the requirement that production-grade images be built only from release/v1. PR builds often run on the PR’s source branch or a temporary merge ref and may produce artifacts from code that never gets merged. This is good for validation, not for controlled production image creation.

Included files filters limit when a trigger runs based on changed file paths, not on governance approvals or branch merge policy. Adding CODEOWNERS to an included files filter is also conceptually incorrect: CODEOWNERS is interpreted by the VCS for review rules, not by Cloud Build for authorization. This would not ensure two governance approvals nor restrict builds to release/v1.

Cloud Build trigger approvals add a manual gate before a build executes, but they do not enforce that merges into release/v1 have two governance approvals. Approval in Cloud Build is typically used for promoting deployments or sensitive steps, not for satisfying VCS merge-approval policies. It also reduces automation and can be bypassed if builds are triggered elsewhere.

Enabling Flow Logs only on the production subnets is correctly scoped and avoids staging noise, but a sample volume scale of 0.5 can miss short, intermittent beacons that last under 10 seconds. For forensic investigations, missing even a few flows can prevent attribution or timeline reconstruction. This option optimizes cost/volume too early at the expense of evidence completeness.

Rolling out to staging first delays data collection in production, which conflicts with “without delaying the investigation.” Also, enabling Flow Logs on staging doesn’t help capture evidence for a production-originating beacon and increases log volume and analysis noise. Finally, 0.5 sampling still risks missing short-lived flows, undermining the forensic goal.

Although sample volume scale 1.0 is appropriate for capturing short beacons, enabling staging as well as production adds cost and noise without improving production forensics. More importantly, a staging-first rollout delays production capture, which is explicitly disallowed by the requirement to avoid delaying the investigation.

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.

An HTTP health check can reduce cold starts by generating traffic, but it does not directly solve the root cause: lack of CPU cycles when the instance is idle. Even if the instance stays up, Cloud Run can still withhold CPU between requests when configured for request-only CPU, preventing the BatchSpanProcessor’s periodic export timer from running reliably. It also adds artificial traffic and cost without guaranteeing trace flushing.

Increasing CPU from 2 vCPU to 4 vCPU improves throughput during active request processing, but it does not address spans missing under light traffic. The issue occurs when there are no requests and CPU is not allocated at all, so the exporter’s scheduled flush cannot execute. More vCPU during requests won’t help if the exporter needs CPU time during idle periods to send buffered spans.

Cloud Trace ingestion may retry transient network failures, but here the spans often never leave the process because the batch exporter doesn’t get CPU time to run its periodic flush. If the instance is suspended or terminated with spans still buffered in memory, there is nothing to retry. Relying on retries is not a reliability strategy for telemetry that is never exported from the application runtime.

Cloud Build running Terraform can provision infrastructure from Git, but it is not Kubernetes-namespace-native. Engineers would not declare resources “from within their Kubernetes namespaces” as Kubernetes objects; they’d submit Terraform changes and rely on pipeline execution. Drift correction within 10 minutes is not automatic unless you add scheduled runs or external drift detection, and least-privilege per namespace is harder because Terraform typically uses shared credentials and state.

A long-running Pod executing Terraform is an anti-pattern for production GitOps and Autopilot operations. It lacks robust state management, secure credential handling, and governance. It also doesn’t provide Kubernetes-native CRDs for engineers to declare resources within namespaces, and continuous reconciliation/drift correction would require custom logic. Autopilot also constrains node-level operations; running ad-hoc infra tooling in Pods increases operational risk.

A Kubernetes Job running Terraform is better than a Pod for one-off execution, but it still doesn’t meet the requirement for continuous reconciliation within 10 minutes unless you add a CronJob or external scheduler. It also doesn’t provide namespace-scoped, Kubernetes-native resource declarations with RBAC boundaries the way Config Connector does. Terraform state, locking, and credentials remain complex in a multi-team, multi-cluster setup.

Incorrect. Cluster Autoscaler is not a guarantee of unlimited scaling: it is constrained by node pool max size, regional quotas (vCPU, IP addresses, etc.), and can be slowed by provisioning time. Also, without properly set pod requests/limits and HPA, the system may not scale pods appropriately, leading to pending pods or poor binpacking. It also doesn’t validate N+1 capacity for a zonal outage.

Incorrect. 28% steady-state utilization doesn’t ensure six months of safety because 10% month-over-month growth compounds to ~77% over six months. More importantly, resilience to losing one zone means the remaining zones must absorb load; per-zone capacity and scheduling constraints can cause hotspots even when overall utilization looks low. This option ignores quota ceilings and provides no validation through load/failure testing.

Incorrect. Pre-provisioning 60% additional node capacity now is not the best approach because six months of 10% month-over-month growth compounds to about 77%, so 60% is not even a precise match for the forecasted increase. More importantly, buying capacity up front increases cost immediately and still does not verify that autoscaling limits, quotas, pod requests, and scheduling behavior will work correctly during a real surge or a single-zone failure. The better practice is to validate node pool maximums and quotas, configure HPA and resource requests properly, and run representative load and failure tests so capacity can scale elastically instead of being statically overprovisioned.

Self-managed Jenkins on Compute Engine is not a managed, GCP-native approach and introduces significant operational overhead (patching, scaling, availability, security hardening). Scheduling every 6 hours fails the requirement to run on every pull request update and to block merges until tests pass. It also wastes resources by running regardless of whether relevant files changed and does not inherently integrate with GitHub required status checks without extra setup.

Manual local execution by reviewers is unreliable and not automatable. It cannot guarantee consistent environments, repeatability, or auditability, and it does not meet the requirement to automatically run tests on every PR update. It also cannot reliably block merges based on an enforced status check, because logs attached to a PR are not a verifiable CI signal and are prone to human error or omission.

Running tests only on pushes to main means tests execute after the pull request is merged, which violates the requirement to block merges until tests pass. This approach increases risk because broken changes can land in main and potentially trigger downstream deployments. It also doesn’t satisfy the requirement to run on every PR update, and it provides slower feedback to developers compared to PR-triggered CI.

Log-based metrics can quantify specific error patterns found in logs (for example, BigQuery API errors returned to your service). However, they reflect what your workloads logged, not whether Google Cloud had an underlying incident. They can also miss issues if logging is incomplete or sampling occurs. This helps symptom tracking, but it does not reliably attribute spikes to Google-managed service degradation.

A logs widget is useful for quickly viewing recent errors and stack traces during troubleshooting. But raw logs are noisy, require manual filtering, and still only show what your application or services emitted. They do not provide authoritative, curated incident context about Google Cloud service health. This approach is slower for correlation and does not directly answer whether Google Cloud dependencies were degraded.

Alerting policies notify you when a metric crosses a threshold, which is valuable for detection and SLO-based paging. But the question is about building a dashboard to determine causality (your service vs Google Cloud dependency outages). Alerting alone doesn’t provide attribution, and “system error metrics” are not a direct mechanism to correlate with Google Cloud service incidents affecting your project.

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.

Updating Slack every 30 minutes with a next-update time is good practice for internal comms, but withholding customer updates until a fix is found is not. In a SEV-1 with major transaction impact, customers need immediate acknowledgement, impact scope, and ongoing updates even without an ETA. Delaying external comms increases ticket volume and damages trust.

Delegating internal updates can help, but replying to customer tickets one-by-one with ad hoc notes does not scale (120 tickets in 10 minutes) and risks inconsistent or inaccurate messaging. The Communications Lead should drive broadcast updates through a status page and standardized templates, then reference those updates in ticket responses as needed.

Forwarding all internal inquiries to the Incident Commander is counterproductive. The IC must focus on coordination and decision-making, not handling repetitive questions. This option increases IC load and slows mitigation. The Communications Lead’s purpose is to shield responders from interruptions by consolidating questions and publishing regular, authoritative updates.

A canary rollout on Cloud Run can limit impact by shifting a small percentage of traffic to a new revision. However, it still deploys the broken revision and does not satisfy the requirement to prevent rollouts when required environment variables are missing. It also may not fail the CI/CD pipeline within 2 minutes because detection depends on runtime behavior and traffic patterns rather than a deterministic pre-deploy check.

Static code analysis (linting, style checks, dependency scanning) is valuable in CI, but it does not validate runtime configuration injection (environment variables and secrets). The error is a missing env var at startup, which typically comes from deployment configuration, Secret Manager bindings, or build substitutions. Therefore, static analysis won’t reliably catch the issue or enforce the “absent or empty” checks required.

Cloud Audit Logs can help determine whether IAM or configuration changes affected deployments, which is useful for troubleshooting. But it is reactive, not preventive, and does not add a CI/CD control to block releases when env vars are missing. It also doesn’t guarantee a fast pipeline failure; it would require manual review or additional automation not described in this option.

This is more stringent than current observed performance (70 ms p90 vs 85 ms, 180 ms p95 vs 210 ms). If published, the service would immediately violate the SLO under normal conditions, rapidly consuming error budget and triggering unnecessary escalations or release freezes. Tightening SLOs is appropriate only when users are dissatisfied or you have already improved performance and can sustain it.

This loosens the SLO above current performance (110 ms p90, 240 ms p95). While it would be easier to meet, it reduces sensitivity to regressions and weakens the reliability promise to stakeholders. Since users are already satisfied at better performance, relaxing the SLO provides no benefit and can permit gradual degradation without triggering action.

This is significantly looser than current performance and would likely mask meaningful latency regressions, especially during global spike events where tail latency impacts checkout completion. Such a permissive SLO undermines the purpose of SLOs as an operational control mechanism and makes error budgets too large to drive prioritization between feature work and reliability work.

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.