Ensuring solution and operations excellence practice questions

Answer: A) Error Reporting with notifications sent to a Cloud Monitoring channel

Error Reporting automatically groups application errors by stack trace and shows counts and samples for each group. It can notify Cloud Monitoring channels when new error groups appear, with no custom logic needed.

• AError Reporting groups error events by stack trace and shows occurrence counts and sample stack traces for each group. It can notify Cloud Monitoring channels when a new error group appears or a resolved one recurs.
• BLog-based metrics can count matching log entries and trigger alerts, but you have to define the filters yourself. They don't automatically cluster exceptions by stack trace or detect new failure types.
• CCloud Trace shows request latency and the path a request takes through services. It doesn't group exceptions or display their stack traces.
• DCloud Profiler shows where code spends CPU time and memory. It doesn't capture, group, or alert on application exceptions.

Answer: A) Error Reporting notifications, which are sent when an error can't be grouped with any existing error group

Error Reporting groups exceptions and sends notifications for new error groups (and for resolved groups that recur), so teams hear about new exception types without being alerted on every repeat.

• ACorrect. Error Reporting groups similar errors together. It sends a notification when an error event can't be grouped with previous errors (a new error group) or when a resolved group recurs, not for every repeat of an open group.
• BIncorrect. A log-based alert fires on any matching entry, subject only to rate limiting. It can't tell a new exception type from a repeat of a known one.
• CIncorrect. A threshold alert reacts to error volume, not to the first appearance of a new exception type. A new exception can occur without moving the 5xx rate.
• DIncorrect. Uptime checks test availability from outside the service. They don't look at application exceptions or tell different error types apart.

Answer: A) Two burn-rate policies: a short lookback with a high threshold that pages, and a long lookback with a low threshold that tickets

Burn-rate alerting matches urgency to how fast the error budget is being used: a short-window, high-threshold policy pages on fast burns, and a long-window, low-threshold policy flags slow burns at lower urgency.

• ACloud Monitoring recommends a fast-burn alert with a short lookback (for example, 10x over 1–2 hours) to catch sudden budget use quickly. A slow-burn alert with a longer lookback (for example, 2x over 24 hours) catches gradual use without paging on short spikes.
• BRaw error counts ignore traffic volume and the SLO's error budget. The alert is noisy at high traffic and misses problems at low traffic.
• CThis fires only after the budget is already used up. It's too late to respond to a fast burn and gives no early warning of a slow one.
• DOne long window is slow to detect sudden fast burns. Paging at 1x also pages for minor slow burns, so the policy fails both goals.

Answer: A) Define a request-success SLI, set an SLO with a 99.9% goal over the period, and create burn-rate alerting policies on the resulting error budget

The target is an SLO measured by an SLI. The allowed shortfall is the error budget, and alerting on how fast that budget is consumed is burn-rate alerting, which Cloud Monitoring supports directly on SLOs.

• AThe SLI measures good requests compared with total requests, and the SLO sets the 99.9% goal. The error budget is (1 − goal) × eligible events. A burn-rate alert fires when the budget is consumed faster than a threshold, for example a fast-burn and a slow-burn policy.
• BAn SLA is an external contract with penalties, not the internal mechanism for tracking budget use. Alerting on any single failed probe ignores the allowed failure budget and creates noisy alerts.
• CCPU utilization is a resource metric, not a user-facing success ratio. It does not measure progress against a 99.9% request-success target or how fast the allowed failures are being used up.
• DA fixed error-count threshold does not account for traffic volume or the 30-day target. It cannot tell how much of the allowed failure budget remains or how fast it is being consumed.

Answer: A) The error ratio broken down by region, zone, and API endpoint to find which slice of traffic is failing

Averages can hide outliers and localized failures. Breaking error SLIs down by region, zone or endpoint shows which part of the traffic is failing.

• ACorrect. A service-wide average can hide a failure that affects only one region, zone or endpoint. Breaking the SLI down by these dimensions shows which slice of traffic is affected.
• BIncorrect. A longer averaging window spreads short, localized failures out even more, so they become harder to see.
• CIncorrect. Comparing two aggregate numbers doesn't show which users or requests are failing. A localized problem can leave both values within target.
• DIncorrect. Mean latency is another aggregate that can hide outliers, and it doesn't isolate where the errors happen.

Answer: A) Submit a quota increase request now, and add a Cloud Monitoring alert on quota usage at a warning threshold such as 80%

Treat quotas as a capacity resource you monitor. Request increases well before you need them, because requests can require review, and alert on quota usage before it reaches the limit.

• AQuota increase requests can require review. This generally takes about two business days, and large requests can take longer. Requesting now leaves time for review, and a warning-level alert gives lead time the next time usage approaches the quota.
• BCommitted use discounts are a billing discount and don't change quota values. The managed instance group would still hit the vCPU quota.
• CThe quota adjuster needs enough usage history. It submits adjustment requests as usage approaches the quota, not instantly at 100%, and those requests can still require review. Relying on it alone gives no guaranteed lead time.
• DThis waits until capacity is already blocked, so scale-outs fail when demand is highest. The fix then still has to wait for review.

Answer: A) Keep each dashboard's JSON definition in Git and apply it from a pipeline with Terraform or gcloud

Cloud Monitoring dashboards can be defined as JSON and deployed with the API, gcloud or Terraform. Storing that JSON in version control gives reviewed, versioned and reproducible dashboards across environments.

• ACorrect. Dashboards can be defined in the Dashboards JSON format and created with the Monitoring API, with gcloud monitoring dashboards create --config-from-file, or with the Terraform google_monitoring_dashboard resource. Keeping that JSON in Git gives review, history and repeatable deployment to each project.
• BIncorrect. Building and copying dashboards by hand in the console gives no peer review or change history, and the copies drift apart over time.
• CIncorrect. Predefined dashboards are maintained by Google. The team can't put its own custom dashboards through review or version control this way.
• DIncorrect. A metrics scope lets one project view metrics from several projects, but it doesn't add review, change history or reproducible deployment of dashboards.

Answer: A) Label the alerting policies by severity and send low-severity alerts to a ticketing channel, keeping the paging channel for critical alerts

Match the notification channel to urgency. Use severity labels so critical, user-impacting alerts page immediately and low-severity alerts become tickets for business hours.

• ACorrect. Google Cloud recommends matching the notification channel to urgency: page only for issues that need an immediate response, and create tickets for non-critical issues so they can be handled without an interruption. Severity labels on alerting policies make this routing possible.
• BIncorrect. Higher thresholds remove useful early warnings, and any alert that still fires will page at night. The real problem is that every alert uses the same urgent channel.
• CIncorrect. Using one channel no matter how urgent the alert is the problem Google Cloud warns about. User-facing outages would wait hours for a response, which breaks the requirement to page immediately.
• DIncorrect. This only spreads the noise across two people. Non-urgent alerts still page at night, so alert fatigue continues and staffing costs go up.

Answer: A) Two aggregated sinks at the organization level: one to a Cloud Storage bucket with a locked 7-year retention policy, and one to a Pub/Sub topic that the SIEM subscribes to

Use organization-level sinks to send the same audit logs to two destinations: a Cloud Storage bucket with a locked retention policy for low-cost 7-year retention, and Pub/Sub for near-real-time streaming to the SIEM. The _Required bucket's retention is fixed at 400 days.

• ASinks route matching log entries to each destination independently. A Cloud Storage bucket with a locked retention policy (Bucket Lock) gives cheap, tamper-resistant 7-year storage, and a Pub/Sub sink streams entries to an external SIEM as they arrive.
• BThe _Required bucket retention is fixed at 400 days and cannot be changed. Read access through Log Analytics also does not push logs to an external SIEM in near real time.
• CAdmin Activity audit logs go to the _Required bucket, not _Default. Long retention in log buckets costs more than archival object storage, and polling once a day is not near real time.
• DThis meets the archival requirement. However, sinks to Cloud Storage write log entries in hourly batches, so the SIEM would not receive logs in near real time. A separate Pub/Sub sink is needed for streaming.

Answer: A) Instrument request paths with distributed tracing, and link each alert policy's documentation to a runbook for that failure mode

When detection is already fast, you reduce MTTR by speeding up diagnosis and repair. Distributed tracing finds the faulty service in the request path, and runbooks linked to alerts give engineers proven remediation steps.

• ACorrect. Distributed tracing, such as Cloud Trace, shows how a request moves across services and which downstream dependency causes errors or delays. That shortens diagnosis. Runbooks linked from the alert give tested remediation steps, which shortens the repair decision.
• BIncorrect. Longer retention helps with historical and post-incident analysis. During a live incident, recent logs are already available, so this doesn't help engineers find the faulty service in the request path or choose a fix.
• CIncorrect. Detection is already fast. More cause-based alerts add noise and alert fatigue but don't show which service is at fault or how to remediate it.
• DIncorrect. Rolling back every service churns healthy ones and does nothing for faults that weren't caused by a deployment. It replaces diagnosis instead of speeding it up, which can make incidents longer and harder to understand.