Ensure solution and operations reliability: free practice questions

Option A is correct because Cloud Profiler is specifically designed for continuous CPU (and heap) profiling of production applications. For Go, it requires importing the profiler agent package and initializing it—no manual instrumentation of individual functions is needed. It uses statistical sampling with very low overhead and presents a flame graph identifying hot functions. Option B is wrong because Cloud Trace measures request latency across distributed services and records span durations; it does not profile CPU usage at the function level within a single service. Option C is wrong because recording custom metrics manually per function requires significant code instrumentation effort, which the question explicitly asks to minimize, and it measures throughput/count rather than CPU profiling data. Option D is wrong because Cloud Debugger (now deprecated as Cloud Debugger, succeeded by snapshot-based debugging) captures program state at specific points; it does not measure CPU time or produce profiling data.

Option A is correct because setting an adequate terminationGracePeriodSeconds ensures Kubernetes waits long enough for the application to finish serving in-flight requests before forcibly killing the container. Option B is correct because a preStop sleep hook introduces a brief delay before SIGTERM is sent, giving the load balancer time to drain the pod from its backend set before the application starts shutting down—this directly prevents new requests from being routed to a terminating pod. Option C is wrong because setting minAvailable to 100% would make rolling updates impossible, as Kubernetes could never evict any pod. Option D is wrong because the HPA adds pods based on load metrics and doesn't coordinate with deployment rollouts to prevent connection draining issues. Option E is wrong because increasing maxUnavailable would make the problem worse by terminating more pods simultaneously. Option F is wrong because a failing readiness probe alone doesn't solve the connection draining issue for requests already in flight; it prevents new traffic routing but doesn't address the grace period problem.

Option A is correct because a cross-region read replica replicates data asynchronously with very low lag (typically seconds to a few minutes), meeting the RPO of less than 5 minutes. The replica can be promoted to a standalone primary instance in under 30 minutes, satisfying the RTO requirement. PITR provides additional granularity for recovery. Option B is wrong because daily backups result in up to 24 hours of data loss (RPO far exceeds 5 minutes), and restoring to a new region from backup typically takes longer than 30 minutes for a production-sized database. Option C is wrong because Cloud Scheduler triggering database exports every 5 minutes is operationally fragile, creates significant I/O overhead on the primary, and restoration from exports is a slow, manual process that would not meet a 30-minute RTO. Option D is wrong because a same-region HA configuration provides failover within the same region only—it does not protect against a full regional failure, which is the failure scenario described.

Option B is correct: the scenario describes a situation where the `/health` endpoint is misleading during warm-up (returns 200 but the service isn't ready). A `startupProbe` on the actual API endpoint gates the pod from being considered 'started' until the API is genuinely available — the `failureThreshold: 30` with `periodSeconds: 1` gives exactly 30 seconds for startup. Once the startupProbe succeeds, the `readinessProbe` on `/api/ready` (a real API check) takes over to control traffic routing throughout the pod's lifetime. Option A is wrong because `initialDelaySeconds: 30` on a readinessProbe simply delays the first probe check by 30 seconds — but the `/health` endpoint returns 200 even during warm-up, so the pod will pass the readiness check immediately after the delay and start receiving traffic before it's actually ready. Option C is wrong: a `livenessProbe` controls whether a pod is restarted, not whether it receives traffic — only `readinessProbe` gates Service traffic routing. Option D is wrong: `terminationGracePeriodSeconds` controls how long Kubernetes waits after sending SIGTERM before forcibly killing a pod on shutdown — it has no effect on when a new pod starts receiving traffic.

Option A is correct: while there is no single 'magic' Cloud Monitoring feature that auto-detects percentage deviations from dynamic baselines across all services without any configuration, the practical recommended approach at scale is to use IaC (Terraform with the Cloud Monitoring provider) to programmatically generate and deploy one alerting policy per service. This is the GCP-recommended operational pattern for managing monitoring at scale and keeps policies maintainable. Option B is partially appealing but misleading: Cloud Trace does support SLO-based alerting, but SLOs require explicit threshold definition, not dynamic 20%-above-baseline detection, and do not automatically establish baselines. Option C is wrong: Metric Absence conditions fire when no data is received for a metric, not when a metric deviates from a historical baseline. Option D is close but fundamentally flawed: a single policy with `groupByFields` can evaluate all services in one policy, but a 'static threshold' does not satisfy the requirement of detecting deviation from each service's individual historical baseline — a single static threshold would not be appropriate across services with very different baseline latencies.