Prepare and test your skills
Prepare and test your skills
Implementing and validating remediation actions is the closed-loop process of applying an Active Assist (opens in a new tab) recommendation and then confirming the result with performance and cost data. Active Assist is the portfolio of tools that uses data and machine learning to generate recommendations and insights, while Recommender is the engine that analyzes utilization data to produce those recommendations. The loop depends on Cloud Monitoring (opens in a new tab) for real-time utilization signals, Recommender for the suggested change, and billing and observability tools to prove the change improved efficiency without harming performance.
The Active Assist review workflow is the ordered console process for finding, evaluating, and acting on a recommendation for a project, folder, or organization. The workflow moves data from resource telemetry to a filterable recommendation list, then to a detail view with affected resources and estimated impact, and finally to an apply or dismiss decision by an authorized operator. Visibility follows ownership boundaries, so recommendations at the organization or folder level are visible only with permissions for that level, regardless of permissions for child projects.
Remediation in Active Assist means changing resource allocation to match actual demand through resizing, deletion of idle resources, or configuration changes such as autoscaling policies. Right-sizing addresses a direct tradeoff where over-provisioning creates unnecessary cost and under-provisioning creates performance bottlenecks that affect application performance and user experience. Recommender analyzes historical utilization data to identify candidates such as idle virtual machines (VMs) and oversized VMs, while Cloud Monitoring provides real-time visibility into usage patterns that confirm the inefficiency before action.
Custom metrics extend this remediation model from manual action to automated response for application-specific workloads. An operator defines a metric relevant to the workload, configures an alert threshold on that metric, and routes the alert to administrators who adjust allocation when the threshold is met. This dependency ensures that scaling happens in a timely manner because the workflow depends on the custom signal to trigger the right-sizing action, which helps optimize cost and prevent performance issues that generic CPU-only signals might miss.
Autoscaling remediation replaces a fixed size with a policy that dynamically adjusts capacity based on workload fluctuations, so resources are present when needed without permanent over-provisioning. Each Google Cloud compute platform implements autoscaling with its own scaled unit and decision signal, and the operator chooses the platform that owns the workload. A managed instance group policy explicitly sets a minimum and maximum number of VMs plus the conditions that trigger scaling, such as adding VMs when CPU utilization reaches an upper threshold and removing them when it drops below a lower threshold.
The following comparison shows how the scaled unit and trigger differ by platform:
| Platform | Scaled unit | Scaling trigger |
|---|---|---|
| Compute Engine managed instance groups (MIGs) | Group of VMs managed and scaled as a single entity | Autoscaling policy with minimum and maximum VM counts and conditions such as CPU utilization thresholds |
| Google Kubernetes Engine (GKE) | Nodes, Pod replicas, Pod requests and limits, and node pools | Pod resource demands, CPU, memory, or custom metrics, and observed usage patterns |
| Cloud Run | Serverless instances with no managed infrastructure | Incoming traffic volume, scaling up as traffic rises and down as traffic falls |
GKE autoscaling combines four tools that work together to optimize utilization and performance. Cluster Autoscaler adds or removes nodes based on Pod demands, Horizontal Pod Autoscaler changes Pod replica counts, Vertical Pod Autoscaler fine-tunes Pod requests and limits, and Node Auto-Provisioning creates optimized node pools. For sudden demand spikes, first scale up manually and pre-warm VMs, pre-load caches, and warm serverless components to prevent cold starts, then let autoscaling sustain the level, because autoscaling alone might not catch up with the velocity of event traffic.
Exam tip: Manually pre-warm VMs, caches, and serverless instances before a peak event, but Google Cloud Load Balancing does not require pre-warming.
Validation of a remediation action is the comparison of performance and cost metrics before and after the change to confirm that utilization improved without degrading user experience. Google Cloud Observability provides metrics, logs, and traces that flow from the remediated resource to dashboards and alerts, where the operator checks system health and business-specific behavior. To avoid alert fatigue, focus alerts on critical metrics, set appropriate thresholds, and ensure timely response to significant anomalies so workload reliability is maintained proactively.
The key signals to compare before and after remediation are:
Cost validation depends on Cloud Billing (opens in a new tab) and Cost Management tools that flow spending data from the remediated resources to reports, budgets, and alerts. Tagging and labeling by project, department, or other dimensions lets the operator categorize spend, monitor patterns for specific resources, and identify high-usage areas or savings after deletion or downsizing. Correlate resource utilization with application performance to decide whether a further downgrade to a less expensive option is safe, and use budgets with alerts plus custom dashboards and reports to track key performance indicators (KPIs) and confirm that forecast savings actually appear.
Recommendation workflows in Google Cloud turn Active Assist findings into controlled operational action. Active Assist is the portfolio of optimization guidance built on the Recommender API (opens in a new tab) (recommender.googleapis.com), which provides recommendations for improving resource usage and optimizing costs, and on insights, which are findings that highlight notable patterns in resource usage. A complete workflow first enables access, then filters findings, then reviews and approves them at scale, then applies them, and finally connects them to dashboards, incident handling, and automation.
Recommendation access depends on APIs and Identity and Access Management (IAM) roles that separate viewing from changing resources. The Recommender API must be enabled to retrieve cost, performance, security, and IAM guidance, and a caller needs the Recommender Viewer IAM role to list insights and recommendations. Gemini Cloud Assist (opens in a new tab) chat uses the same dependency when it answers prompts such as Give me recommendations to reduce my resource costs, Which of my VMs are idle, or What BigQuery datasets should I partition or cluster. Because viewing requires only the viewer role while applying a change requires resource-specific permission such as editing a Cloud SQL instance, teams can enforce an approval boundary where analysts review findings but only approvers apply them.
Filtering narrows the insight stream to one recommender family and one pattern so review queues stay actionable. Insights flow from the Recommender service to the console, to the gcloud command-line tool, and to the REST API, and each interface supports the same filter concept. The table below shows how each interface retrieves the same filtered result.
| Interface | How to retrieve filtered insights | Result |
|---|---|---|
| Google Cloud console | List recommendations, then click a recommendation to open its panel | Panel shows insights and detailed recommendations for that item |
| gcloud | Run gcloud recommender insights list with --project, --location, --insight-type, and --filter | Returns only insights that match the filter for that project and location |
| REST API | Call insights.list with GET https://recommender.googleapis.com/v1beta1/projects/PROJECT_ID/locations/LOCATION/insightTypes/.../insights?filter=... | Returns matching insights as structured data for automation |
For example, Cloud SQL security work uses --insight-type=google.cloudsql.instance.SecurityInsight with --filter=insightSubtype=DATABASE_AUDITING_NOT_ENABLED in gcloud, or the equivalent ?filter=insightSubtype=DATABASE_AUDITING_NOT_ENABLED in the API, to surface only instances without database auditing in a region such as us-central1. IAM rightsizing uses the same idea with a different dimension: recommender = "google.iam.policy.Recommender" and recommender_subtype = "REMOVE_ROLE" selects only least-privilege removals and excludes other IAM finding types.
Exam tip: Filter insights by insightSubtype, such as DATABASE_AUDITING_NOT_ENABLED, and filter exported IAM recommendations by recommender_subtype, such as REMOVE_ROLE; the two fields apply to different Recommender surfaces.
Enterprise review moves recommendations from the console into BigQuery for centralized triage, visualization, and approval tracking. The BigQuery Data Transfer Service pulls data from the IAM recommender, which is part of Policy Intelligence and uses machine learning (ML) to recommend removal of unused roles and discovery of abandoned service accounts. Data then flows from the BigQuery dataset to analysts, to visualization tools such as Looker and Data Studio, and to Sheets for sharing approval lists. The transfer depends on the BigQuery API being enabled and on the export being configured before queries can run.
An enterprise rightsizing review follows an ordered sequence:
SELECT recommendation_details FROM PROJECT_ID.DATASET.TABLE_NAME WHERE recommender = "google.iam.policy.Recommender" AND recommender_subtype = "REMOVE_ROLE" to isolate removal candidates.This sequence preserves least privilege because recommendations are evaluated against actual permission usage before any binding is removed, and join, move, and leave changes are handled through group and binding updates rather than one-off edits.
Applying a recommendation changes the target resource only after approval, and the method depends on the resource type. In the console, the operator opens the recommendation panel and clicks Edit Instance to enable database auditing on a Cloud SQL instance. With gcloud and the API, the operator applies the same outcome by enabling database auditing directly on the instance. The lifecycle therefore moves in order from detected to reviewed to approved to applied, and only the final transition mutates infrastructure. Choose console application when a human approver needs insight context alongside the action, and choose gcloud or API application when the approved change must be scripted, logged, or repeated across many projects.
Monitoring integration places recommendation findings alongside health, performance, and deployment signals so cost and reliability tradeoffs are visible in one place. Cloud Monitoring creates custom dashboards to visualize key metrics and trends, defines custom metrics for business needs, and configures alerts that send notifications to incident management tools like PagerDuty or Slack. Cloud Deploy status for canary releases and rollbacks flows into Cloud Monitoring, while infrastructure health from Compute Engine instances, Google Kubernetes Engine (GKE) clusters, TPUs, and GPUs flows into the same dashboards that surface Active Assist optimization guidance. When quota pressure is part of the performance story, quota usage metrics flow from Google Cloud services to Cloud Monitoring alerts that notify teams before usage approaches quota limits.
Supporting telemetry completes the incident context around a recommendation:
Together these signals let an incident workflow start from an alert, pivot to logs, traces, and errors, and then link to the relevant Active Assist recommendation for remediation.
Automation handles recurring recommendation patterns without re-triaging the same finding manually. A scheduled BigQuery transfer plus a saved filtered query continuously surfaces repeat patterns such as REMOVE_ROLE for over-granted IAM bindings or DATABASE_AUDITING_NOT_ENABLED for noncompliant databases. Downstream automation then routes new rows to dashboards, ticketing, or remediation scripts, while standardization ensures the same approved fix is applied the same way across teams and projects. Use this pattern when volume is high and the remediation is well understood, and retain human approval when the change affects access, compliance scope, or production capacity.
Active Assist recommendations are machine learning-generated actions delivered by the Recommender API (recommender.googleapis.com) to improve resource usage, optimize costs, and strengthen security posture. The system produces two related objects: insights, which are findings that highlight notable patterns in resource usage, and recommendations, which are specific remediation actions with projected impact. Data flows from the Recommender API to the Google Cloud console, to Gemini Cloud Assist chat, and to BigQuery for enterprise-scale analysis, so the same finding can be reviewed interactively or prioritized centrally.
Access to cost and usage recommendations depends on the Recommender API and the Recommender Viewer IAM role, while topology context depends on the App Topology API (apptopology.googleapis.com). Gemini Cloud Assist uses these signals to answer natural-language prompts about savings and reliability, and the App Topology API lets Gemini Cloud Assist understand the topology of applications and resources. Because recommendations span cost, performance, quota, and security, prioritization must weigh projected savings against risk reduction and operational impact before any change is applied.
Cost and performance recommendations identify waste, missed efficiency, and reliability risk across compute, data, and quota resources. Gemini Cloud Assist surfaces these recommendations in response to prompts about reducing resource costs, identifying idle virtual machines (VMs), identifying BigQuery datasets that should be partitioned or clustered, and listing quotas that are almost hitting the limit. An idle VM recommendation points to compute capacity that can be stopped or rightsized, a BigQuery partitioning and clustering recommendation points to scan and cost improvements, and a near-limit quota finding points to future availability failures rather than current waste.
Database performance recommendations add a validation path through Database Center, which assesses and tests the performance impact before changes reach production. The assessment clones the database instance, runs benchmarking simulation tests on the clone, and compares baseline performance against performance after the recommended configuration change. This order matters because only after the clone is isolated can load be replayed safely, and only after baseline and recommended runs complete can throughput and latency be compared without risking the production fleet.
The supported assessment types for Cloud SQL for PostgreSQL split by the scaling question being answered:
| Recommendation type | Change evaluated | Performance question answered |
|---|---|---|
| Compute resource expansion | Resize to machine types with more vCPUs or memory | Whether added CPU and memory improve throughput and latency |
| Edition upgrade | Migrate from Cloud SQL Enterprise edition to Cloud SQL Enterprise Plus edition | Whether the edition change improves performance for the workload |
| Data cache activation | Enable the data cache | How cache activation changes latency and throughput |
Security posture recommendations reduce excess privilege by finding accounts and permissions that are no longer used. Unused orphaned user accounts and abandoned service accounts pose a security risk when employees leave, change roles, or finish temporary tasks, so best practice is to remove them rather than leave broad access in place. The Identity and Access Management (IAM) recommender (opens in a new tab) (google.iam.policy.Recommender), part of Policy Intelligence, uses machine learning to recommend removal or rightsizing of role bindings and helps maintain the principle of least privilege across members in an organization.
At enterprise scale, IAM findings flow from the IAM recommender through the BigQuery Data Transfer Service to a BigQuery dataset, where they can be queried and visualized with tools such as Looker. A prioritization query selects recommendation_details from the export table where recommender = "google.iam.policy.Recommender" and recommender_subtype = "REMOVE_ROLE" to isolate unused-role findings. The query result identifies unused roles and supports rightsizing of IAM role bindings, so access removal can be ordered by blast radius instead of project by project.
Policy Analyzer (opens in a new tab) for IAM policies answers the complementary question of which principals have what access to which Google Cloud resources. Policy Analyzer can show who can access an IAM service account, who can read a BigQuery dataset containing personally identifiable information (PII), what roles the dev-testers group holds, which Compute Engine VM instances a principal can delete, and who can access a Cloud Storage bucket during Berlin working hours. Use the IAM recommender when deciding what access to remove, and use Policy Analyzer when verifying who currently has sensitive access before that removal.
Prioritization of Active Assist recommendations balances three decision criteria that often point in different directions. Each criterion measures a different kind of value or cost, so a high score on one does not guarantee a high rank overall. The operator must compare all three before approving a change for production.
High savings with low operational impact, such as deleting clearly idle resources, ranks first, while high-risk access removals rank high even when savings are zero because they reduce privilege-escalation paths. Changes with uncertain performance effects depend on Database Center assessment results, and quota findings depend on growth forecasts, since a quota that is almost exhausted will block scaling even though fixing it saves no money today.
Exam tip: Database Center assessments support only Cloud SQL for PostgreSQL, not all database engines, so compute expansion, edition upgrade, and data cache activation must be validated there before production rollout.
REMOVE_ROLE findings can be isolated at scale by exporting IAM recommender data with BigQuery Data Transfer Service and querying for recommender = "google.iam.policy.Recommender".Active Assist is the portfolio of tools that uses data and machine learning to generate recommendations and insights, while Recommender is the engine that analyzes utilization data to produce those recommendations. Recommendations are specific remediation actions with projected impact and insights are findings that highlight notable patterns in resource usage.
The workflow is to open Active Assist in the Google Cloud console, select the project, folder, or organization scope, list all recommendations for filtering and sorting, click a recommendation to inspect supporting data with affected resources and estimated impact, and then click Apply or Dismiss if permitted or follow the console instructions for manual application. Recommendations at the organization or folder level are visible only with permissions for that level, regardless of permissions for child projects.
Compute Engine managed instance groups (MIGs) scale a group of virtual machines managed as a single entity using an autoscaling policy with minimum and maximum virtual machine counts and conditions such as central processing unit utilization thresholds. Google Kubernetes Engine (GKE) scales nodes, Pod replicas, Pod requests and limits, and node pools based on Pod resource demands, central processing unit, memory, or custom metrics and observed usage patterns, while Cloud Run scales serverless instances with no managed infrastructure up as incoming traffic rises and down as traffic falls.
Your team manages critical Compute Engine workloads where unexpected storage and memory exhaustion can cause application downtime. You need to implement a proactive incident management workflow in Cloud Monitoring that satisfies the following requirements:
Which configuration should you implement in Cloud Monitoring?
Last updated