An enterprise organization is architecting a globally distributed e-commerce API backend on Google Cloud. To ensure a resilient, low-latency user experience during high-traffic events, the architecture team must define non-functional requirements for performance and availability. The requirements are as follows: Quantify user-perceived performance by tracking the proportion of requests served in under 200 ms. Establish an objective target to manage release risk and quantify acceptable downtime or degradation over a rolling 30-day period. Determine the maximum sustainable traffic throughput before latency violates the target threshold. Which approach should the cloud architect implement to establish these requirements and thresholds?

Define a request-based Latency Service Level Indicator (SLI) measuring the ratio of requests completed under 200 ms to total requests, establish a Service Level Objective (SLO) percentage goal over a rolling 30-day compliance period to derive an error budget, and perform load testing to determine the request rate threshold where 99th-percentile latency remains within the SLO limit.: ### What this solution is This solution establishes a formal **Site Reliability Engineering (SRE)** framework using **Service Level Indicators (SLIs)**, **Service Level Objectives (SLOs)**, and **error budgets** implemented via **Google Cloud Observability** and structured capacity planning. ### How it meets the requirements - **Quantifying low-latency performance**: Defining a request-based **Latency SLI** as the ratio of valid requests resolved below the 200 ms **Latency Threshold** directly tracks the user experience at the application layer. - **Managing release risk and reliability**: Setting a percentage goal for the SLO over a **rolling 30-day compliance period** provides an active **error budget**, allowing engineering teams to balance feature delivery velocity against system reliability. - **Determining traffic thresholds**: Executing load testing to find the request rate where the **99th-percentile latency** meets the SLO boundary allows the team to pinpoint exact scaling limits and capacity thresholds before production degradation occurs. ### Key advantages and capabilities - **Direct user alignment**: Measures actual customer experience rather than raw underlying infrastructure resource metrics. - **Actionable error budgets**: Provides a mathematical threshold (`100% - SLO Goal`) to govern deployment freezes and architectural remediation. - **Predictable capacity planning**: Correlates load generation throughput directly against latency distributions. - **Native observability integration**: Seamlessly tracks performance goals inside **Cloud Monitoring** and **Cloud Service Mesh**. ### Why this is optimal This approach directly targets the non-functional performance requirements by coupling quantifiable quality attributes (latency and availability) with empirical threshold testing, ensuring global system resilience without over-provisioning infrastructure.

StudyCerts

Define Slo Performance Thresholds Gcp | 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! | StudyCerts

Professional Cloud Architect

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!

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Define Slo Performance Thresholds Gcp

Section: Identifying functional and non-functional requirements

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise organization is architecting a globally distributed e-commerce API backend on Google Cloud. To ensure a resilient, low-latency user experience during high-traffic events, the architecture team must define non-functional requirements for performance and availability.

The requirements are as follows:

Quantify user-perceived performance by tracking the proportion of requests served in under 200 ms.
Establish an objective target to manage release risk and quantify acceptable downtime or degradation over a rolling 30-day period.
Determine the maximum sustainable traffic throughput before latency violates the target threshold.

Which approach should the cloud architect implement to establish these requirements and thresholds?

Configure an infrastructure-level Availability SLI based on internal ICMP ping response times across Compute Engine VMs, configure alerting policies in Cloud Monitoring for peak disk I/O, and set regional quota limits to trigger autoscaling.

Implement a windowed Availability SLI measuring total connection concurrency per backend instance, define an annual SLO compliance period, and size backend resources so that peak utilization matches 100% capacity.

Define a request-based Latency Service Level Indicator (SLI) measuring the ratio of requests completed under 200 ms to total requests, establish a Service Level Objective (SLO) percentage goal over a rolling 30-day compliance period to derive an error budget, and perform load testing to determine the request rate threshold where 99th-percentile latency remains within the SLO limit.

Establish a contractual Service Level Agreement (SLA) target for 100% availability, use Cloud Logging metrics tracking average CPU utilization per instance, and conduct stress testing to identify the exact breakpoint where Compute Engine virtual machines crash.

Professional Cloud Architect

Define Slo Performance Thresholds Gcp

Related questions