Objective: define good service before adding replicas
Use the operating and cost constraints from earlier lessons to state what reliable service means for a user. “The servers are running” can be true while customers cannot complete an order. Choose a service-level indicator, or SLI, that measures a relevant aspect of performance. A service-level objective, or SLO, sets the desired level for that indicator over a defined period. The measurement and the target are separate: observing a percentage does not show whether it meets the agreed requirement until both are specified.
Measurements, targets, and budgets
Google’s service-monitoring documentation describes availability indicators based on successful responses and latency indicators based on requests meeting a threshold. An SLO adds a goal and compliance period. An error budget represents the allowed departure from the objective; it is not a Cloud Billing spending budget. Define what counts as a good request and which requests enter the measurement. Otherwise, an apparently favorable percentage can reflect a changed denominator rather than an improved customer experience. Infrastructure metrics can help investigate behavior, but they should be connected to the service question.
Map the dependency that can still fail
Zones are deployment areas within regions and useful failure domains to consider. Reliability design examines every critical component, not merely the number of application replicas. Two frontends can still depend on one database or a single regional component. Google’s reliability guidance recommends identifying failure domains, distributing critical services appropriately, configuring failover, and testing failure scenarios. Multiple locations do not automatically guarantee uninterrupted service. Data consistency, health detection, routing, and the remaining dependencies determine whether a particular failure can be handled.
Worked example
Fictional case: an event organizer wants at least 99 percent of registration requests to succeed over a calendar week. First define success as a completed valid registration rather than an HTTP page view. If 9,950 of 10,000 counted requests succeed, the measured availability is 99.5 percent. That meets the stated target for this observation period; it does not prove every future week will comply. Next inspect the architecture: two frontend replicas both depend on one unavailable database during a drill. The replica count did not remove that critical failure point. Recovery design must include the database and the path by which the application resumes useful work.
Exercises turn plans into evidence
A written recovery plan records intended actions. An exercise provides evidence about whether those actions work under the tested conditions. Google’s guidance compares failover testing with a fire drill. Record the failure simulated, the dependencies observed, the actions taken, and whether the business operation recovered. A successful zonal test does not prove a regional-loss scenario has been exercised. Preserve that distinction when reporting resilience. Before relying on a stored copy of data, test the relevant recovery workflow instead of treating the existence of a copy as a complete service-recovery result.
Transfer check
A service has replicas in two zones and reports healthy compute metrics, but users cannot submit forms because its shared database is unavailable. What should the team examine? Check: measure the user operation, identify the shared database failure domain, and test a recovery path that includes it. Do not infer service availability from healthy frontends alone. Retrieve the SLI-versus-SLO distinction with the final card, then revisit the operations guide to combine access, spending, service targets, and evidence into one owned operating decision.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
Geography and regions | Get started | Google Cloud DocumentationConcepts in service monitoring | Google Cloud Observability | Google Cloud DocumentationBuild highly available systems through resource redundancy | Cloud Architecture Center | Google Cloud Documentation