Google Cloud Professional Cloud Architect: Analyze and optimize technical and business processes Practice Questions

The error budget is 1 − 0.9995 = 0.0005 of requests. Over 10,000,000 requests that is 5,000 failed requests, and the question mentions no failures already consumed, so all 5,000 remain. 500 would correspond to a 99.995% SLO, 50 to 99.9995%, and 4,500 assumes 500 failures already happened.

3-year resource-based CUDs on Compute Engine offer up to ~70% discount compared to on-demand pricing and are the highest available discount for a predictable, stable, long-running VM fleet. Option C (1-year CUDs) provides only ~37% discount — less optimal when the team is confident about a 3-year commitment. Option D (SUDs) are automatic and provide up to ~30% off but are strictly lower than CUD discounts and cannot be combined with resource-based CUDs on the same resources. Option B (spend-based CUDs) are typically used for Cloud SQL or other services; for Compute Engine VMs, resource-based CUDs yield higher discounts and are the preferred approach.

Current availability = (2,400,000 − 12,000) / 2,400,000 = 99.5%, which exactly hits the SLO target. The total error budget for a 99.5% SLO over 2,400,000 requests = 0.5% × 2,400,000 = 12,000 allowable errors. The team has consumed all 12,000 allowed errors, meaning 100% of the error budget is consumed. While the SLO is not technically violated yet, there is zero remaining error budget. — (C) is wrong because while the SLO line is not crossed, 100% of the budget is consumed — not 0%. — (A) is wrong because 50% consumption would mean only 6,000 errors; the actual 12,000 errors represent the full budget. — (B) is wrong because a request-based SLI is calculated purely from total requests and total bad requests (e.g., 5xx errors), both of which are given.

When the error budget is nearly exhausted, the standard SRE practice is to (1) halt risky changes that could further burn the budget and (2) investigate and fix root causes. Freezing non-critical feature releases (A) directly reduces the risk of further SLO violations caused by new deployments. Performing a blameless post-mortem (C) is how the team identifies why violations occurred and prevents recurrence. Option D is incorrect because raising the SLO target makes the error budget even smaller and harder to maintain — it punishes the team further rather than helping them recover. Option B is incorrect because arbitrarily shortening the SLO window to 'reset' the budget is gaming the metric; it does not fix the underlying reliability problem and undermines the purpose of SLOs. Option E is incorrect because continuing to release non-critical features while the error budget is exhausted directly violates the SRE error budget policy and risks further degradation of user experience.

Istio's fault injection feature allows SREs to inject delays (and HTTP errors) into specific traffic routes using a VirtualService CRD without any application code changes or redeployment. The rule can be scoped to traffic from a specific source (Service A) to a destination (Service B), leaving all other traffic unaffected. This is exactly the no-code, targeted approach required. Option A is incorrect: Cloud Armor is a WAF/DDoS protection layer that operates on external HTTP(S) traffic at the load balancer — it does not inject latency into internal east-west service-to-service traffic on GKE. Option C introduces a custom sidecar which requires modifying the pod spec (a redeployment) and is more complex than using Istio's built-in capability. Option D (Linux tc on nodes) is a low-level OS approach that would affect all pods on those nodes, not just Service B, and is operationally dangerous and difficult to control precisely in a production cluster.