Prepare and test your skills
Prepare and test your skills
Formulate Effective Prompts for Metric Analysis and Root Cause Investigation is the practice of writing precise natural language queries that direct Gemini Cloud Assist (opens in a new tab) to correlate metrics, surface anomalies, and propose causes for degradation. An effective prompt names the resource scope, the symptom or metric, and the time or location window. That precision lets the assistant pull data from Cloud Monitoring, Cloud SQL (opens in a new tab) insights, and Personalized Service Health instead of returning a generic answer. Prompting from the Cloud Assist panel in the Google Cloud console passes the current page context directly into the analysis and, when warranted, into a formal investigation.
Precise metric prompts specify what to measure, where to measure it, and how to rank or slice the result. A prompt such as Which of my VMs have the highest utilization? tells Gemini Cloud Assist to rank Compute Engine utilization across the project, while Total VM network bytes sent per second for each instance? requests a per-instance time series breakdown. A prompt such as What are the top 5 dataflow jobs with the highest estimated backlog processing time? adds both a ranking limit and a specific performance signal. Because the resource, metric, and grouping are explicit, Gemini Cloud Assist can correlate disparate series and highlight which resource deviates from its peers.
Context-aware prompting improves precision when the prompt is issued from a specific console page. Prompts sent while viewing a Cloud Storage page can reference buckets and objects in that location, prompts sent from a BigQuery (opens in a new tab) page can reference datasets and jobs, and prompts sent from a Cloud SQL instance page can reference that instance's CPU, latency, and error logs. The flow moves from the console page context to the Cloud Assist panel to the underlying telemetry, so the same short question returns a scoped answer instead of a project-wide summary. For advanced analysis, always include project, region or zone, and time window when the page context does not already provide them.
Prompts for correlating performance and utilization signals ask Gemini Cloud Assist to compare utilization, throughput, and saturation metrics across resources to form a hypothesis. These direct metric queries become building blocks for correlation, and focused prompts should be issued first and then compared across the same time range:
Which of my VMs have the highest utilization? to rank compute saturation across instances.Total VM network bytes sent per second for each instance? to compare network throughput time series per instance.What are the top 5 dataflow jobs with the highest estimated backlog processing time? to isolate pipeline backlog from compute load.What's the QPS on my SQL databases? to correlate database query rate with VM or application latency.What are all the quotas for my project that are almost hitting the limit? to test whether throttling explains degradation.Which of my VMs are idle? and Give me recommendations to reduce my resource costs to separate waste from genuine contention.These prompts depend on underlying APIs and roles, so a prompt fails if its data source is not enabled. Cost and utilization recommendations require the Recommender API with the Recommender Viewer role, BigQuery prompts require the BigQuery API with BigQuery Data Viewer and BigQuery Job User roles, and Storage Intelligence prompts require a Storage Intelligence subscription with the Storage Insights Viewer role.
Prompts for database root cause investigation direct Gemini Cloud Assist to link query-level telemetry with instance-level load in Cloud SQL. Query-focused prompts identify the outlier workload, while system prompts test whether that workload explains high CPU, latency, or error volume. Effective database prompts name the instance, the signal, and the comparison dimension rather than asking broadly why the database is slow.
Common patterns supported in the Cloud Assist panel include:
What is the current CPU utilization of this database? to establish instance load at the time of the incident.Which of my queries have high latency for this database instance? to rank slow queries within one instance.What is the slowest query for this database in this instance? to isolate a single candidate for plan or index analysis.How many error log entries are there for this database instance? to correlate errors with latency spikes.What issues are affecting my databases? to aggregate health, performance, and compliance signals.Where are my databases located?, Show me all databases running on Postgres., and How many databases do I have in the US? to scope the blast radius by location and engine.Exam tip: Ask for the slowest or highest-latency queries first to identify the workload, then ask for CPU and error-log counts over the same period to test whether that workload explains the instance load.
Prompts for service disruption hypotheses ask Gemini Cloud Assist to check whether a Google Cloud incident explains project symptoms and to summarize impact and workarounds. The prompt flow moves from the project symptom to Personalized Service Health data to an incident summary, so the assistant can distinguish a platform event from an application regression. This assistance requires enablement of the Service Health API and the Service Health Viewer role.
Supported incident prompts include:
Is there something going on with Google Cloud? I'm seeing issues with my project. to trigger a project-scoped incident check.What's the latest update on the Compute Engine outage in us-central1? to tie a product and region to a time series anomaly.How is my project impacted by the Cloud Storage incident? to correlate storage errors or latency with a known event.Is there a workaround for the BigQuery incident? to generate an actionable next step while the incident is open.In the Cloud Hub Health and troubleshooting page, these prompts complement visual correlation of open alerts, Google Cloud incidents, and health charts for the selected project or application and time range. Charts display Cloud Monitoring alert events, Service Health events, and product-specific events, and the Annotations selector controls which events overlay the metric lines. A precise follow-up prompt should reference the product, service, or workload selected in that view and the time range where the metric deviated.
Gemini Cloud Assist investigations is the root-cause analysis tool that turns a troubleshooting chat into a structured, runnable investigation of infrastructure and application issues. An investigation depends on the chat context, the target resources, and explicit permissions, and it preserves prior investigation results even after access rules change. As of April 10, 2026, creating, running, and editing investigations requires a Premium Support contract or access granted through the account team.
A prompt becomes an investigation through an ordered workflow:
The investigation depends on identity and platform prerequisites on both sides of the trust boundary. The caller must hold the Gemini Cloud Assist Investigation Creator or Investigation Owner role and the Database insights viewer role for Cloud SQL analysis, with permissions to detect and investigate performance issues. The target must be a supported configuration: Cloud SQL Enterprise Plus edition using the new network architecture with query insights enabled, excluding Enterprise edition instances, old network architecture, VPC Service Controls perimeters, Access Transparency, and read replicas. Query anomaly detection is available only for Enterprise Plus edition, so prompts about anomalous query patterns require that tier.
Evaluate and Synthesize AI-Generated Insights from Operational Metrics is the discipline of treating AI summaries as hypotheses and validating them against independent telemetry. Gemini Cloud Assist (opens in a new tab) interprets operational metrics into contextual summaries, trend descriptions, and anomaly explanations for Google Cloud resources. Metric data flows from Cloud Monitoring, Personalized Service Health, logs, and telemetry views into the Cloud Assist panel and Gemini Cloud Assist investigations, which then produce natural-language findings and recommended next steps. The operator remains responsible for validating those findings against historical baselines, alert thresholds, and service-level objectives (SLOs) before acting.
Gemini Cloud Assist metric insights translate raw time-series and event data into human-readable context for a selected project, product, service, or workload. A summary typically combines a metric trend such as CPU utilization, query latency, VM network bytes sent per second, BigQuery slot usage, or Dataflow backlog processing time with related events over the same time range. Anomaly explanations highlight what changed, when the change began, and which resources appear involved, plus prompts for deeper checks such as What is the current CPU utilization of this database? or Which of my queries have high latency for this database instance?. Because Gemini Cloud Assist is an early-stage technology, its output can seem plausible but be factually incorrect, so every summary must be treated as a hypothesis until confirmed in the underlying telemetry.
Validation means comparing the AI description of a trend to independent sources that show what normal looks like. Cloud Hub Health and troubleshooting (opens in a new tab) charts show health metrics for the selected time period, by default the last hour, with annotations for recommended events that the operator can expand with the Annotations selector. The same view surfaces Open alerts, which are Cloud Monitoring incidents from metric-based alert policies, and Google Cloud incidents from Personalized Service Health, alongside per-product or per-service workload charts. An operator synthesizes a reliable conclusion only after the AI-reported trend aligns with chart shape, sustained threshold crossings, and historical comparison, not from the narrative alone.
Exam tip: Gemini Cloud Assist can describe a spike as an anomaly, but only Cloud Monitoring charts, alert incidents, and quota or SLO thresholds confirm whether the spike violates an operational baseline.
An anomaly explanation from Gemini Cloud Assist often lists events that occurred at the same time, which establishes correlation rather than causation. Correlated signals include three event types that can appear together on one chart:
Causation requires an additional dependency or mechanism, such as a query that consumed slot-milliseconds and spilled bytes and then increased queue time, a reservation limit that throttled capacity, or a caller identity in Cloud Audit Logs that changed configuration before latency rose. BigQuery INFORMATION_SCHEMA (opens in a new tab) views provide that mechanism check through JOBS and JOBS_TIMELINE for slot consumption and error codes, RESERVATIONS and CAPACITY_COMMITMENTS for capacity limits, STREAMING_TIMELINE for ingestion latency, and TABLE_STORAGE for storage skew. If the AI links two metrics without such a shared resource, ordering, or configuration change, the operator must keep them as coincident until further evidence connects them.
Gemini Cloud Assist investigations are the root-cause analysis tool that turns an initial chat finding into a structured, reviewable investigation. Creating and running investigations depends on both commercial and identity controls: as of April 10, 2026, creation, running, and editing require a Premium Support contract or access granted through the account team, plus the Investigation Creator or Investigation Owner Identity and Access Management (IAM) role. The ordered workflow from chat is first, ask Gemini Cloud Assist to investigate a resource issue; then, when the model determines an investigation is useful, select Create investigation; then, review and edit the pre-populated fields carried over from chat context; and only after selecting Create, review results on the Investigation details page. In Cloud Hub, recent investigations appear under Recent Cloud Assist Investigations, and a new investigation is started with Investigate, so the path from metric anomaly to documented cause stays traceable.
AI-generated metric insight is only as complete as the telemetry and permissions available to the assistant. Cloud SQL AI-assisted troubleshooting illustrates these boundaries: query anomaly detection is available only for Cloud SQL Enterprise Plus edition instances, and AI troubleshooting is not supported for Cloud SQL Enterprise edition instances, instances on the old network architecture, instances inside a VPC Service Controls perimeter, instances with Access Transparency enabled, or read replica instances. Effective use also depends on prerequisites that must propagate before analysis, including Gemini Cloud Assist setup, use of the new network architecture, enabled query insights, and IAM grants such as roles/databaseinsights.viewer and roles/geminicloudassist.investigationOwner, which carry databaseinsights.performanceIssues.detect and databaseinsights.performanceIssues.investigate. When any boundary applies, Gemini Cloud Assist may omit the true driver, so the operator must expand validation to Cloud Monitoring metrics such as slot usage, execution duration, and uploaded bytes, configured alert policies for thresholds and quotas, and audit logs for who initiated each operation.
Translate Interpreted Metrics into Actionable Operational Recommendations is the process of converting Gemini Cloud Assist analysis of anomalies into specific fixes that restore reliability. Gemini Cloud Assist Investigations (opens in a new tab) compares baseline aggregated performance data against current metrics, surfaces hidden patterns, and produces ranked observations with recommended next steps. The operator then validates the output, selects scaling, configuration, or alerting changes, and prioritizes work by severity and business impact.
Gemini Cloud Assist Investigations is the automated, in-depth analysis engine that turns metric deviations into remediation guidance. When an investigation starts from Logs Explorer, a resource page, or chat, the service analyzes logs, configurations, and metrics together, then traces probable root causes across multi-tier topologies. For Bigtable, the investigation compares baseline aggregated data for a selected cluster and time range against current behavior to detect significant change.
The Bigtable analysis evaluates five core signals:
When a significant change is detected, the Investigation Overview pane organizes results into three parts that flow from description to action. The Issue describes what is being investigated, including start and stop time; Findings list observations, such as client misconfiguration like an incorrect channel pool size; and Hypotheses list AI-recommended actions to address the anomalies. In some cases the analysis completes with no recommendation, which itself signals that no significant deviation was confirmed.
A metrics-driven investigation workflow moves data from the monitored resource to a ranked remediation plan in a fixed order. First, the operator opens the resource context, such as a Bigtable instance, and navigates to System insights and Explore Investigations. Then, the operator selects the target cluster in the Cluster field and selects a time range or custom date and time that covers the spike in CPU utilization or latency. Only after scope and time are set does the operator click Investigate.
The service then analyzes performance data for that period and, after a few minutes, returns the Issue, Findings, and Hypotheses views for review. Interactive Cloud Assist chat complements this flow: the operator opens the Cloud Assist panel from the Google Cloud console toolbar, provides resource context by viewing the affected page, and prompts with the symptom and metric, such as high latency for the api-gateway service in the prod cluster. Gemini Cloud Assist responds with key metrics to check first, potential causes like resource constraints or network congestion, and tools for deeper investigation.
Scaling and configuration remediations are the direct fixes derived from interpreted metric trends and error context. A scaling adjustment increases capacity or concurrency when demand exceeds limits, while a configuration change corrects client, workload, or platform settings that create the bottleneck. Gemini Cloud Assist links the observed signal to the likely constraint, so the operator can act on the specific resource rather than scaling blindly.
| Remediation type | Choose when | Documented example |
|---|---|---|
| Scaling adjustment | Request count or CPU utilization rises and serving capacity is exhausted | Cloud Run (opens in a new tab) HTTP 429 ... no available instance points to maximum container instance limit reached from traffic surge, long startup time, or long request processing time |
| Configuration change | Findings point to client or workload settings rather than pure load | Bigtable finding of incorrect channel pool size, or GKE (opens in a new tab) CrashLoopBackOff with nil pointer dereference, or NotReady node needing auto-repair checks and kubectl follow-up |
| Alert and reliability tuning | Metrics show recurring saturation, quota pressure, or cost-reliability tradeoff | Quotas almost hitting the limit, idle VMs, or BigQuery datasets that should be partitioned or clustered |
Configuration changes also extend to deployment and access paths that investigations surface from logs and configs. For services deployed from source code, investigations can provide code fix suggestions in the Cloud Run console Source tab for build and deployment failures. For platform issues, prompts about RootSync versus RepoSync, KNV2009 resource-not-found errors, or ingress=internal behavior translate into RBAC, path, object-size, or ingress corrections that remove the recurring error source.
Prioritization orders Hypotheses by interpreted severity first and business impact second. Severity reflects the magnitude and persistence of deviation from baseline, such as combined growth in server latencies and CPU utilization versus a brief client-latency blip, and whether errors block serving. Business impact reflects what depends on the affected resource, such as a prod api-gateway serving user traffic versus a development cluster, or a quota that will block launches if exhausted.
Alert rule refinements convert validated anomalies into durable detection so the same pattern pages correctly next time. The operator tightens thresholds around the confirmed baseline, separates client latencies from server latencies to avoid misattribution, and adds quota-proximity or error-log signals when investigations repeatedly cite limits or misconfiguration. Because Gemini for Google Cloud output can seem plausible but be factually incorrect, every recommendation must be validated against dashboards, logs, and configuration before changing production, and investigation results can be transferred to a Google Cloud support case when a support package is held.
Exam tip: Findings are observations about what changed, while Hypotheses are the recommended actions to take; only Hypotheses contain the remediation to implement.
An effective prompt names the resource scope, the symptom or metric, and the time or location window so Gemini Cloud Assist can correlate data from Cloud Monitoring, Cloud SQL insights, and Personalized Service Health instead of returning a generic answer. Prompting from the Cloud Assist panel in the Google Cloud console passes the current page context into the analysis, and you should include project, region or zone, and time window when the page context does not already provide them.
Creating, running, and editing Gemini Cloud Assist investigations requires a Premium Support contract or access granted through the account team plus the Investigation Creator or Investigation Owner role as of April 10, 2026. Cloud SQL query anomaly detection and AI troubleshooting additionally require Enterprise Plus edition using the new network architecture with query insights enabled and exclude Enterprise edition instances, old network architecture, VPC Service Controls perimeters, Access Transparency, and read replica instances.
Findings are observations about what changed, while Hypotheses are the recommended actions to take. For Bigtable, the investigation compares baseline aggregated data against current behavior across client latencies, server latencies, CPU utilization, disk utilization, and request count and organizes results into an Issue describing start and stop time, Findings such as client misconfiguration, and Hypotheses ordered by severity and business impact.
Your DevOps team manages a multi-tier production service running on Google Cloud that is experiencing intermittent latency spikes and service degradation. Cloud Monitoring dashboards show correlated anomalies across CPU utilization, database connection pool exhaustion, and elevated HTTP 5xx error rates.
You need to leverage AI-assisted observability to quickly interpret these correlated metric trends, identify the probable root cause, and obtain prioritized, actionable remediation steps that can also be escalated to Cloud Customer Care if necessary. What should you do?
Use the Gemini diff editor inside Cloud SQL Studio to review line-by-line query changes and run automated DDL schema migrations.
Query Storage Insights datasets using BigQuery to analyze object metadata trends and infer system-level resource bottlenecks.
Initiate a Gemini Cloud Assist Investigation from the affected resource or Logs Explorer to analyze telemetry data and generate ranked root-cause hypotheses with recommended actions.
Enable Gemini auto-conversion within Database Migration Service to automatically rewrite database configurations and connection pooling rules.
Last updated