PCDOE Applying site reliability engineering practices Practice Test 5 — 15 Questions

Question 1

In Google's incident management process, which role is responsible for communication with stakeholders and users during an incident?

Accepted Answer

Communications Lead.. In Google's incident management process, the Communications Lead is explicitly responsible for managing all external and internal communications, including updates to stakeholders and users. This role ensures that accurate, timely information is disseminated while the Incident Commander focuses on coordinating the response. The Communications Lead does not engage in technical troubleshooting or operational tasks, which are handled by other roles.

Answer

Incident Commander.

Answer

Technical Lead.

Answer

Operations Lead.

Question 2

Which THREE steps are typically part of a formal incident postmortem according to Google SRE best practices?

Accepted Answer

Assign action items with deadlines.. Option B is correct because a formal postmortem must produce concrete, owned action items with deadlines so that follow-up work is tracked and completed rather than left as vague intentions. Option C is correct because reconstructing a precise incident timeline — detection, escalation, mitigation, and resolution times — is a foundational step that lets the team reason about what happened and where response gaps existed. Option E is correct because Google SRE postmortems focus on identifying contributing factors and root causes in a blameless manner, examining the technical and organizational conditions that allowed the failure. Option A does not belong because postmortems are explicitly blameless and do not seek to name or blame an individual. Option D does not belong because immediate remediation is part of incident response and mitigation, not the postmortem, which occurs after the incident is resolved to analyze and learn from it.

Answer

Identify the person responsible for the incident.

Answer

Implement a solution immediately.

Question 3

Refer to the exhibit. If the error rate spikes to 2% for only 2 minutes, why does the alert not fire?

Accepted Answer

The duration of 300s requires the condition to be met for 5 minutes.. The alert condition requires the error rate to exceed 1% for a duration of 300 seconds (5 minutes). A spike lasting only 2 minutes does not meet the minimum duration requirement, so the alert remains in a 'pending' state and never fires. In Google Cloud Monitoring, the duration parameter defines how long the condition must be continuously true before the alert transitions from pending to firing.

Answer

The notification rate limit prevents the alert from firing.

Answer

The threshold value of 1% is too high.

Answer

The alignment period of 60s is too short.

Question 4

You are the DevOps engineer for a social media platform. After a recent code rollout, you receive multiple user complaints about failed logins. The service logs show a sharp increase in 5xx errors from the authentication service. However, the existing alerting policy for the authentication service did not fire. The policy is configured to trigger if the error rate exceeds 5% for 5 minutes. Upon checking Cloud Monitoring, you see that the error rate spiked to 15% for 3 minutes, then dropped back to normal. What is the most likely reason the alert did not fire?

Accepted Answer

The duration condition of 5 minutes was not satisfied.. The alert did not fire because the policy requires the error rate to exceed 5% for a continuous duration of 5 minutes. The spike only lasted 3 minutes, which is shorter than the configured duration condition, so the alerting policy's condition was never fully met. In Google Cloud Monitoring, alerting policies evaluate both the threshold and the duration window before transitioning to a firing state.

Answer

The error rate threshold of 5% was too low, causing the alert to be suppressed.

Answer

The alignment period for the metric was set to 5 minutes, hiding the spike.

Answer

The notification channel was incorrectly configured.

Question 5

You are the SRE for a video streaming service running on Google Kubernetes Engine (GKE). The service's SLO is 99.9% availability over a 30-day window, and the error budget is currently 50% consumed. A new feature is ready for deployment, but it carries a risk of increasing the error rate. According to Google SRE practices, what should you do?

Accepted Answer

Proceed with a canary deployment and monitor the error budget impact.. The error budget provides a quantitative measure of acceptable unreliability. With 50% remaining, the team can still take risks, but they should do so cautiously. A canary deployment limits the impact of potential errors, allowing the team to monitor and react. This balances the need to innovate with the need to maintain reliability, a core SRE practice.

Answer

Deploy the feature immediately because the error budget is not exhausted.

Answer

Halt all deployments until the error budget is fully replenished.

Answer

Roll back the previous deployment to free up error budget.

Question 6

You are an SRE for a payment processing service on Google Cloud. The service's SLO for latency is that 99% of requests must complete within 200ms. You are setting up an alerting policy in Cloud Monitoring to detect when the service is at risk of violating this SLO. Which metric should you use as the basis for the alert?

Accepted Answer

The 99th percentile latency over a 5-minute window.. The SLO is defined as 99% of requests under 200ms, which corresponds to the 99th percentile latency. Alerting on this percentile over a short window provides a direct signal of SLO violation risk. Other metrics like average, median, or maximum do not accurately capture the tail behavior that the SLO targets, and may lead to missed violations or false alerts.

Answer

The maximum latency observed in the last 5 minutes.

Answer

The average latency over a 1-hour window.

Answer

The 50th percentile latency over a 5-minute window.

Question 7

Your team runs a critical service on Google Cloud. You have defined an SLO of 99.9% availability over a 30-day rolling window. The error budget is currently 50% consumed. A new feature is ready to deploy, but the team is unsure if they should proceed. According to Google SRE principles, what should they do?

Accepted Answer

Proceed with the deployment because the error budget is not exhausted.. Google SRE uses error budgets to balance reliability and innovation. When budget remains, teams can proceed with releases, as the budget explicitly permits risk. The correct action is to deploy while monitoring the budget, and halt if it is exhausted. Freezing at 50% or demanding zero risk contradicts the purpose of error budgets.

Answer

Increase the SLO to 99.99% to provide more buffer before deploying.

Answer

Freeze all deployments until the error budget is fully replenished.

Answer

Deploy only if the new feature has zero risk of causing errors.

Question 8

You are the SRE for a critical API service on Google Cloud. The service has an SLO of 99.95% availability. During a recent incident, the service was unavailable for 10 minutes. After the incident, you need to calculate the error budget consumed. Assuming a 30-day month, how much of the error budget was consumed?

Accepted Answer

About 46.3%. The error budget is the allowed downtime derived from the SLO. For 99.95% availability over 30 days, the budget is 21.6 minutes. The incident consumed 10 minutes, which is 10/21.6 ≈ 46.3% of the budget. This calculation is essential for tracking error budget consumption and making decisions about releases and reliability work.

Answer

About 23.1%

Answer

About 100%

Answer

About 2.8%

Question 9

You are implementing a canary deployment for a new version of a microservice on Google Kubernetes Engine (GKE). You want to automatically roll back if the canary's error rate exceeds the baseline by 2% for 5 minutes. Which approach best achieves this?

Accepted Answer

Use Cloud Monitoring to create an alert on the canary's error rate, and configure the alert to trigger a Cloud Function that rolls back the deployment.. Automated canary analysis requires monitoring error rates and triggering rollback when thresholds are breached. Cloud Monitoring can compare canary and baseline metrics, and with alerting to a Cloud Function, you can automate rollback. Kubernetes probes and Istio alone don't provide this logic. Manual rollback is not automatic.

Answer

Use Istio to route traffic to the canary, and rely on its built-in automatic rollback feature when errors exceed a threshold.

Answer

Use kubectl rollout undo to manually revert if errors are observed.

Answer

Configure a Kubernetes readiness probe that fails when errors occur, causing the canary pods to be restarted.

Question 10

Your team runs a service on GKE and wants to implement SLO-based alerting. The SLO is 99.9% availability measured over a 30-day rolling window via a request-based SLI. You configure a burn-rate alert with a 1-hour window and a burn rate threshold of 14.4. During a partial outage where the service is unavailable for 5 minutes in every hour, the alert does not fire. What is the most likely reason?

Accepted Answer

The SLI is computed as a ratio of good requests to total requests, and the 5-minute outages may not produce enough bad requests to exceed the burn rate threshold in the 1-hour window.. The alert does not fire because the burn rate over the 1-hour window remains below 14.4. With a request-based SLI, short outages that affect a small percentage of requests may not consume error budget fast enough to exceed the threshold. The threshold itself is appropriate for fast-burn detection; the issue is the mismatch between the outage pattern and the alert condition. To catch such patterns, consider a multi-window alert or a lower threshold for slower burns.

Answer

The burn rate threshold of 14.4 is too high; it should be set to 1.0 to detect any outage.

Answer

The alerting policy is misconfigured because it lacks a notification channel; without a notification channel, the alert never fires.

Answer

The rolling window is 30 days, but the burn rate alert should use a 30-day window to match the SLO; using 1 hour causes the alert to miss short outages.

Question 11

You are an SRE for a microservices-based application on Google Kubernetes Engine (GKE). You want to implement a monitoring strategy that reduces alert fatigue and focuses on user-impacting issues. Which approach aligns with Google SRE best practices?

Accepted Answer

Create alerts based on SLO burn rates and high-level service health metrics.. SRE best practices emphasize alerting on symptoms that directly affect users, such as SLO violations. Burn rate alerts measure how quickly the error budget is being consumed, providing a clear signal of user impact. This approach reduces alert fatigue by filtering out non-critical events and focusing on what matters most: keeping the service reliable from the user's perspective.

Answer

Set up alerts for each deployment event to track changes.

Answer

Alert on CPU and memory utilization thresholds for each microservice.

Answer

Alert on every error log entry to ensure no issue is missed.

Question 12

Your team manages a high-traffic e-commerce API on Google Cloud. The SRE team wants to proactively detect performance regressions before they impact users. They decide to implement a canary deployment strategy. Which of the following best describes how to use Cloud Monitoring to automatically halt the canary rollout if the error rate exceeds a threshold?

Accepted Answer

Use Cloud Deploy with a canary deployment strategy and configure a deployment verification job that queries a Cloud Monitoring metric for error rate and fails the rollout if the threshold is exceeded.. Cloud Deploy provides native canary deployment support with verification jobs that can query Cloud Monitoring metrics. When the verification job detects that the error rate exceeds the defined threshold, it fails, which automatically stops the rollout and prevents further exposure. This integrates directly with the deployment pipeline, enabling safe, automated canary analysis without custom scripting or indirect triggers.

Answer

Define an SLO with a rolling window and use Cloud Monitoring alerting policies to trigger a Cloud Build pipeline that rolls back the canary when the error rate exceeds the threshold.

Answer

Create a log-based metric for HTTP 5xx errors and configure a log sink to Pub/Sub that triggers a Cloud Function to roll back the deployment.

Answer

Configure a Kubernetes Horizontal Pod Autoscaler to scale down the canary deployment if the error rate increases, effectively removing the canary from service.

Question 13

An SRE team is defining a Service Level Objective (SLO) for a new public API. The product owner wants to ensure the SLO reflects user happiness while allowing for planned maintenance. Which approach should the SRE team take?

Accepted Answer

Define the SLO as the percentage of successful HTTP responses (status codes < 500) over a 28-day rolling window, and exclude maintenance windows from the calculation.. The correct approach is to define an SLO based on user-perceived success, such as successful HTTP responses, over a rolling window. Excluding maintenance windows prevents planned downtime from eroding the error budget, which is a common SRE practice. The other options either use unrealistic targets, measure the wrong signal, or focus on internal operational metrics rather than user experience.

Answer

Define the SLO as the number of incidents per month, with a target of zero incidents, and measure it using the incident tracking system.

Answer

Define the SLO as the average latency of all requests over a 7-day window, and exclude requests that return errors from the latency calculation.

Answer

Define the SLO as 100% uptime for all requests, measured over a calendar month, and include all maintenance windows in the calculation.

Question 14

You are an SRE for a large-scale service on Google Cloud. You are implementing a postmortem process after a major incident. According to Google SRE best practices, which two of the following are essential components of a blameless postmortem? (Choose two.)

Accepted Answer

Analyzing the timeline of events and the contributing factors that led to the incident.. Blameless postmortems focus on learning from incidents without punishing individuals. Essential components include a thorough timeline and analysis of contributing factors, and the creation of action items to prevent recurrence. Blame, secrecy, and disciplinary actions undermine the process by discouraging honesty and limiting organizational learning.

Answer

Keeping the postmortem document private to avoid reputational damage.

Answer

Assigning blame to the team that deployed the faulty change to prevent recurrence.

Answer

Identifying the individual responsible for the outage and documenting disciplinary actions.

Question 15

You are an SRE for a service running on Google Cloud. You want to define an SLO for a gRPC API that uses Cloud Endpoints. The service must respond to 99% of requests within 300 ms over a 28-day window. Which SLI definition should you use to measure latency?

Accepted Answer

The proportion of requests with a response time less than or equal to 300 ms, measured at the load balancer.. The correct SLI is the proportion of requests with latency less than or equal to 300 ms, measured at the load balancer. This directly matches the SLO statement of 99% of requests within 300 ms. It is a request-based SLI that captures the user experience and can be computed from access logs or monitoring metrics. Other options either use averages, percentiles, or counts, which do not directly measure the proportion of good requests as required by the SLO.

Answer

The average response time of all requests over the 28-day window, compared to 300 ms.

Answer

The 99th percentile of response time over the 28-day window, compared to 300 ms.

Answer

The number of requests that exceed 300 ms in the 28-day window.