Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
In Site Reliability Engineering (SRE), specific metrics are used to measure and manage service quality. A Service Level Indicator (SLI) is a direct measurement of performance, like the percentage of successful requests. A Service Level Objective (SLO) is a target value for an SLI over a set period, such as aiming for 99.9% availability per month. A Service Level Agreement (SLA) is a formal, binding contract with customers that promises a minimum level of service, often with consequences if it's not met. Tracking these metrics allows teams to make data-driven decisions about when to scale infrastructure or perform maintenance to keep the service reliable.
Balancing new feature development with system stability is managed using an Error Budget. This budget is the calculated amount of allowable downtime or errors before violating the SLO. When the error budget is high, teams can take more risks by releasing new features rapidly. If the budget is nearly empty or exhausted, the focus must shift entirely to improving stability and reliability, pausing risky changes. This creates a clear, objective rule for when to innovate and when to fix.
Google Cloud provides tools to collect and visualize these critical metrics. OpenTelemetry is an open-source standard for capturing traces, logs, and metrics from applications. For storing and querying metrics at scale, the Managed Service for Prometheus offers a managed backend. Engineers use these tools alongside Cloud Monitoring to build dashboards and create Alerting Policies that notify them when SLOs are at risk, enabling proactive management.
Continuous Integration (CI) and Continuous Deployment (CD) are automated processes essential for maintaining code quality. Using tools like Cloud Build, teams can automate building container images and running tests every time code is updated. This integration of quality control early in the development lifecycle helps find defects long before they reach production, ensuring only reliable code progresses.
Automated testing happens at multiple levels to ensure application integrity. Unit tests check individual components, while integration tests verify that different parts of the system work together. Cloud Build can also run Container Structure Tests to validate the contents and configuration of a container image itself. For security, services like Artifact Analysis automatically scan container images against Google's vulnerability databases to find known security flaws before deployment.
To guarantee that only verified software runs in production, Google Cloud offers Binary Authorization. This service enforces policies that require digital signatures called attestations. An attestation proves that an image has passed all required security scans and tests. By setting these strict rules, Binary Authorization prevents unauthorized or vulnerable containers from being deployed, creating a secure and trusted software supply chain.
After a build passes all tests, Cloud Deploy can manage the automated rollout to different environments like staging and production. Tools like Skaffold help verify the functionality of running containers after each deployment stage. The overall build process is assessed using insights like the SLSA Build Level (which measures build process maturity), a Software Bill of Materials (SBOM) (listing all components), and VEX Status (detailing the exploitability of any found vulnerabilities).
To minimize risk during updates, teams use strategies like canary releases. In a canary release, a new version is deployed to a small subset of users first. This allows teams to monitor for issues and gauge performance impact with minimal exposure. If problems are detected, an automated rollback mechanism can quickly revert the system to the previous stable version, protecting overall system availability.
Maintaining separate, isolated environments for development, staging, and production is a fundamental practice. This isolation allows for rigorous testing of changes, including automated tests and vulnerability scans, without any risk to live users. Ensuring code passes all quality checks in staging before it touches production is a key control measure for reliability.
Effective release management depends on continuous monitoring. Teams track Service Level Indicators (SLIs), such as latency or error rates, to measure real performance against their Service Level Objectives (SLOs). Tools like Cloud Monitoring and Cloud Logging provide the data and alerts needed to know instantly if a new release is causing performance to drop below acceptable targets.
Disaster Recovery (DR) plans prepare for catastrophic failures. Strategies like maintaining an active/passive setup or having reliable backup/restore procedures help mitigate risk. These plans are guided by two key metrics: the Recovery Time Objective (RTO), which is the target duration to restore service, and the Recovery Point Objective (RPO), which defines the maximum tolerable amount of data loss. Redundancy across geographic regions helps avoid single points of failure.
During a severe incident, normal access controls might hinder recovery. Breakglass procedures provide a controlled method for granting emergency access outside standard protocols. These actions must be strictly logged and audited to maintain security and compliance even during high-pressure recovery operations, ensuring accountability while restoring service.
Prepare and test your skills
Prepare and test your skills
A Service Level Indicator (SLI) is a direct measurement of performance, such as the percentage of successful requests. A Service Level Objective (SLO) is a target value for an SLI over a set period, like aiming for 99.9% availability per month. A Service Level Agreement (SLA) is a formal, binding contract with customers that promises a minimum level of service, often with consequences if it is not met.
An Error Budget is the calculated amount of allowable downtime or errors before violating the SLO. When the error budget is high, teams can take more risks by releasing new features rapidly. If the budget is nearly empty or exhausted, the focus must shift entirely to improving stability and reliability, pausing risky changes.
Binary Authorization enforces policies that require digital signatures called attestations, which prove that an image has passed all required security scans and tests. By setting these strict rules, Binary Authorization prevents unauthorized or vulnerable containers from being deployed, creating a secure and trusted software supply chain.
Recovery Time Objective (RTO) is the target duration to restore service after a failure. Recovery Point Objective (RPO) defines the maximum tolerable amount of data loss. These metrics guide disaster recovery strategies like maintaining active/passive setups or backup/restore procedures.
Lower the SLO target from 99.9% to 95.0% for the remainder of the compliance window to prevent alerting policies from triggering during deployments
Ignore the rolling error budget and evaluate infrastructure health exclusively using raw virtual machine CPU and memory utilization thresholds
Halt non-critical feature releases and redirect engineering effort toward infrastructure reliability, performance tuning, and automated scaling fixes until the error budget stabilizes
Switch the SLI calculation from request-based availability to a short 1-minute windowed SLI and reset the 30-day compliance period to zero
An enterprise runs a business-critical order processing microservice on Google Cloud. The Site Reliability Engineering (SRE) team has established a 30-day rolling Service Level Objective (SLO) target of 99.9% availability based on a Service Level Indicator (SLI) measuring successful requests.
During an aggressive deployment cycle, custom Cloud Monitoring dashboards indicate that 90% of the 30-day error budget was consumed in just 4 days due to transient server errors and latency spikes.
According to SRE best practices, how should the team use these SLI/SLO metrics to guide their upcoming operational and development decisions?
StudyCerts
StudyCerts