ACEChapter 96 of 101Objective 5.1

Policy Intelligence and IAM Recommender

This chapter covers Policy Intelligence and IAM Recommender, two critical tools for managing identity and access management (IAM) security at scale in Google Cloud. For the ACE exam, understanding how to use these tools to identify and remediate over-permissive or unused IAM roles is essential—expect 1-3 questions directly testing their purpose, behavior, and integration with Cloud Audit Logs. We will cover the underlying mechanisms, default configurations, and common exam traps to ensure you can confidently answer any question on this topic.

25 min read
Intermediate
Updated May 31, 2026

Policy Intelligence as a Security Auditor

Imagine a large corporation with thousands of employees and hundreds of security badges that grant access to different floors, server rooms, and supply closets. Over time, employees change roles, leave, or accumulate badges they no longer need. The company hires a security auditor. This auditor doesn't just walk around; they systematically review every badge's access logs, compare them to actual usage patterns, and identify badges that have never been used in the last 90 days or badges that grant access to rooms the employee never enters. The auditor then produces a report recommending which badges should be revoked or downgraded. Importantly, the auditor never changes anything themselves—they only provide recommendations. The security team can review these recommendations and decide to act. This mirrors Policy Intelligence and IAM Recommender in GCP: they analyze historical usage data (Cloud Audit Logs), detect unused or overly permissive roles, and generate recommendations to refine IAM policies. The recommendations are actionable but require an administrator to apply them. Just as the auditor doesn't lock doors, the Recommender doesn't change policies—it empowers administrators to do so with data-driven insights.

How It Actually Works

What is Policy Intelligence?

Policy Intelligence is a suite of tools within Google Cloud that helps you understand, analyze, and improve your IAM policies. It includes IAM Recommender, Policy Analyzer, and other features. The core purpose is to provide visibility into who has what access and whether that access is actually being used. This is critical because over-permissive IAM roles are a leading cause of security breaches. Policy Intelligence leverages Cloud Audit Logs and machine learning to generate recommendations.

How IAM Recommender Works

IAM Recommender analyzes historical usage data from Cloud Audit Logs over the past 90 days. It evaluates every principal (user, service account, group, or domain) and its assigned roles at a specific resource hierarchy level (organization, folder, project, or resource). The recommender identifies two types of opportunities: - Unused roles: A principal has a role but has not used any of its permissions in the last 90 days. - Over-permissive roles: A principal uses only a subset of a role's permissions. The recommender suggests a more restrictive role that covers the used permissions.

The recommender does not consider deny policies (from VPC Service Controls or Organization Policies) because those are not IAM roles. It also does not consider conditions that are not based on resource type or IP address—conditions using attributes like request time are ignored.

Key Components and Defaults

Observation period: 90 days of historical data from Cloud Audit Logs.

Recommendation types: ROLE (remove an entire role) and ROLE_MIGRATION (replace with a less permissive role).

Recommendation granularity: Per principal, per role, per resource. For example, a recommendation might say: "Remove the roles/storage.admin role from user alice@example.com on project my-project because it has not been used in 90 days."

Confidence level: The recommender assigns a confidence level (HIGH, MEDIUM, LOW) based on how much data is available. HIGH means at least 30 days of logs exist and usage patterns are clear.

Cost: Using Policy Intelligence is free of charge, but you pay for the underlying Cloud Audit Logs data access logs if you enable them.

Configuration and Verification

To use IAM Recommender, you need the following permissions at the organization, folder, or project level: - recommender.iamPolicyInsights.get (to view insights) - recommender.iamPolicyRecommendations.get (to view recommendations) - recommender.iamPolicyRecommendations.update (to apply recommendations)

You can view recommendations via the Google Cloud Console under IAM & Admin > Recommender or via the gcloud CLI:

gcloud recommender recommendations list \
    --project=PROJECT_ID \
    --location=global \
    --recommender=google.iam.policy.Recommender

To apply a recommendation:

gcloud recommender recommendations mark-claimed \
    RECOMMENDATION_ID \
    --project=PROJECT_ID \
    --location=global \
    --recommender=google.iam.policy.Recommender

Then you must manually remove or modify the IAM binding.

Interaction with Related Technologies

Cloud Audit Logs: Essential data source. Admin Activity logs are always enabled; Data Access logs must be enabled to capture permission usage (they are disabled by default due to volume).

IAM Conditions: The recommender can analyze roles with conditions only if the condition is based on resource type or IP address. Other conditions are ignored.

Organization Policies: The recommender does not consider deny policies from Organization Policies or VPC Service Controls.

Policy Analyzer: A separate tool that allows you to query who has access to what, and simulate changes. It does not generate recommendations but is complementary.

Machine Learning Behind the Scenes

IAM Recommender uses a machine learning model trained on Google's internal best practices and aggregated usage patterns. It identifies anomalous patterns, such as a service account that only reads from a bucket but has the roles/storage.admin role (which includes write and delete). The model suggests a role like roles/storage.objectViewer instead. The model is updated periodically and does not require user training.

Limitations and Edge Cases

New principals: If a principal was created less than 30 days ago, the recommender may not have enough data and will not generate recommendations (or will have LOW confidence).

Service accounts used by GCP services: Some service accounts (e.g., Compute Engine default service account) may have roles that are used by the underlying GCP service, not by a human. The recommender still analyzes usage and may recommend removing roles that appear unused, but you must be careful not to break service functionality.

Custom roles: The recommender can suggest migrating from a basic role to a custom role if the custom role covers only the used permissions. However, it does not create custom roles automatically.

Deny policies: As mentioned, deny policies are not considered. This means a recommendation might suggest removing a role that is effectively denied by a policy, but the recommender does not know that. You must check deny policies separately.

Best Practices

Enable Data Access logs for critical projects to improve recommendation accuracy.

Review recommendations at least monthly, especially for projects with many service accounts.

Start with HIGH confidence recommendations and apply them in a test environment first.

Use the gcloud recommender commands for automation in CI/CD pipelines.

Combine IAM Recommender with Policy Analyzer to understand the impact of a change before applying it.

Walk-Through

1

Enable Data Access Logs

IAM Recommender relies on Cloud Audit Logs, specifically Data Access logs, to observe permission usage. Admin Activity logs are always enabled, but Data Access logs are disabled by default to reduce log volume. To enable them, navigate to **Logging > Logs Router** and create a sink that includes `data_access` logs, or enable them per service (e.g., Cloud Storage, BigQuery) via the respective service's settings. Without Data Access logs, the recommender will have no usage data and will not generate recommendations. Expect a 24-hour delay after enabling before data appears.

2

Grant Recommender Permissions

To view insights and recommendations, you need the `recommender.iamPolicyInsights.get` and `recommender.iamPolicyRecommendations.get` permissions. To apply recommendations, you additionally need `recommender.iamPolicyRecommendations.update` and the relevant IAM permissions to modify bindings (e.g., `resourcemanager.projects.setIamPolicy`). These permissions are typically included in the `roles/recommender.iamAdmin` role. Assign this role at the appropriate resource hierarchy level (organization, folder, or project) to administrators who will manage recommendations.

3

View Recommendations in Console

Go to **IAM & Admin > Recommender** in the Google Cloud Console. Select the project, folder, or organization. The dashboard shows a list of recommendations categorized by type (role removal or role migration). Each recommendation includes: the principal, the current role, the suggested action, the confidence level, and the last 90 days of usage summary. You can click on a recommendation to see detailed insights, including which permissions were used and which were not. This is the primary interface for manual review.

4

Analyze Recommendation Using gcloud

For automation, use the gcloud CLI. List recommendations with: `gcloud recommender recommendations list --project=PROJECT_ID --location=global --recommender=google.iam.policy.Recommender`. The output includes recommendation ID, description, primary impact, and associated insights. To get detailed insights, use: `gcloud recommender insights list --project=PROJECT_ID --location=global --insight-type=google.iam.policy.Insight`. This shows the usage data per principal and role. Use these commands in scripts to generate reports.

5

Apply Recommendation

Before applying, verify that the recommendation won't break functionality. For a role removal, ensure the principal has no other roles that provide the needed permissions. For a role migration, confirm the suggested role covers all used permissions. To apply, first mark the recommendation as claimed using: `gcloud recommender recommendations mark-claimed RECOMMENDATION_ID --project=PROJECT_ID --location=global --recommender=google.iam.policy.Recommender`. Then manually modify the IAM policy (e.g., via Console, gcloud, or Terraform). After applying, mark the recommendation as succeeded: `gcloud recommender recommendations mark-succeeded RECOMMENDATION_ID ...`. If you decide not to apply, mark it as dismissed.

What This Looks Like on the Job

Enterprise Scenario 1: Large Organization with Thousands of Service Accounts

A global e-commerce company runs hundreds of microservices on GKE, each with its own service account. Over time, developers assigned broad roles like roles/editor to service accounts for convenience. The security team uses IAM Recommender at the organization level to identify unused and over-permissive roles. They find that 30% of service accounts have roles that are never used. By applying recommendations, they reduce the attack surface significantly. They automate the review process using a weekly Cloud Function that calls the Recommender API and sends a Slack notification to the security team. One challenge: the recommender sometimes suggests removing a role from a service account that is used by a legacy cron job that runs monthly—the 90-day observation period misses it. They mitigate by setting a longer observation period (not configurable, so they manually review low-confidence recommendations).

Enterprise Scenario 2: Compliance Auditing for Financial Services

A bank must comply with PCI-DSS, which requires least-privilege access. They use Policy Intelligence to generate monthly reports of all IAM bindings and usage. IAM Recommender provides evidence that roles are being used appropriately. They also use Policy Analyzer to simulate the impact of removing a role before applying the recommendation. The bank has a strict change management process: recommendations are reviewed by a separate team, applied in a staging environment, and then promoted to production. The recommender's confidence levels help prioritize which recommendations to review first. They discovered that many developers had roles/storage.admin on projects where they only needed roles/storage.objectViewer. After migration, they reduced the number of security incidents related to accidental data deletion.

Common Pitfalls

Ignoring low-confidence recommendations: These may be due to insufficient data. A service account used only once a quarter might be missed. Always investigate before dismissing.

Applying recommendations without testing: Removing a role from a service account that is used by a production application can cause outages. Always test in a non-production environment first.

Not enabling Data Access logs: Without them, the recommender has no data and generates no recommendations. This is a common oversight.

Over-relying on automation: Fully automated application of recommendations can be dangerous. Always have a human-in-the-loop for critical systems.

How ACE Actually Tests This

ACE Exam Objective 5.1: "Manage security and access at scale using Policy Intelligence"

The exam tests your understanding of what Policy Intelligence is, what it does, and how to use it. Expect 1-3 questions. Key points:

1.

IAM Recommender analyzes usage from Cloud Audit Logs (specifically Data Access logs) over the past 90 days. A common wrong answer is "30 days" or "7 days"—the correct value is 90 days.

2.

The recommender does NOT automatically apply changes. It only generates recommendations. A trap answer says "automatically removes unused roles"—that is wrong.

3.

The recommender does NOT consider deny policies from Organization Policies or VPC Service Controls. A question might say "a role is denied by an organization policy, so the recommender will not suggest removing it"—that is false; the recommender ignores deny policies.

4.

Recommendations are available at the organization, folder, and project levels. Not just project level.

5.

Confidence levels: HIGH, MEDIUM, LOW. HIGH requires at least 30 days of data. A question might ask: "When will the recommender generate a HIGH confidence recommendation?" Answer: After at least 30 days of observation.

6.

Only roles with conditions based on resource type or IP address are analyzed. Conditions based on time or other attributes are ignored.

7.

Policy Analyzer vs. IAM Recommender: Policy Analyzer lets you query existing access and simulate changes; it does not generate recommendations. IAM Recommender generates recommendations based on usage. A question might confuse the two.

8.

Permissions needed: recommender.iamPolicyInsights.get and recommender.iamPolicyRecommendations.get to view; recommender.iamPolicyRecommendations.update to apply. The role roles/recommender.iamAdmin includes these.

9.

Cost: Policy Intelligence is free. The cost is for enabling Data Access logs.

10.

Service accounts used by GCP services: The recommender may recommend removing roles from default service accounts (e.g., Compute Engine default service account). Be cautious—the exam might test that you should not blindly apply such recommendations.

Common Wrong Answers

"IAM Recommender automatically removes unused roles." → Wrong, it only recommends.

"IAM Recommender uses Admin Activity logs." → Wrong, it uses Data Access logs.

"Recommendations are only available at the project level." → Wrong, also at folder and organization.

"The observation period is 30 days." → Wrong, it's 90 days.

"Policy Analyzer generates recommendations." → Wrong, it's Policy Analyzer does not; IAM Recommender does.

Key Takeaways

IAM Recommender analyzes 90 days of Data Access logs to identify unused and over-permissive roles.

Recommendations are never applied automatically; they require manual or scripted action.

Confidence levels: HIGH (≥30 days data), MEDIUM, LOW.

Policy Intelligence is free; Data Access logs may incur costs.

Deny policies from Organization Policies and VPC Service Controls are ignored by IAM Recommender.

Only conditions based on resource type or IP address are considered; time-based conditions are ignored.

IAM Recommender works at organization, folder, and project levels.

Use gcloud recommender recommendations list to view recommendations via CLI.

Policy Analyzer complements IAM Recommender by allowing simulation of changes.

Always test recommendations in a non-production environment before applying.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

IAM Recommender

Generates recommendations to remove unused or over-permissive roles.

Uses 90 days of Cloud Audit Logs usage data.

Output: list of recommended changes with confidence levels.

Requires Data Access logs to be enabled.

Permissions: recommender.iamPolicyRecommendations.*

Policy Analyzer

Queries existing IAM policies and allows what-if analysis.

Does not use usage data; uses current policy state.

Output: who has access to what, and impact of hypothetical changes.

Does not require Data Access logs.

Permissions: policyanalyzer.* and resourcemanager.projects.getIamPolicy

Watch Out for These

Mistake

IAM Recommender automatically applies its recommendations to remove unused roles.

Correct

IAM Recommender only generates recommendations. Applying them requires manual action or an automated script using the gcloud CLI or API. The recommender never changes IAM policies on its own.

Mistake

IAM Recommender uses Admin Activity logs to determine role usage.

Correct

It uses Data Access logs, which record each API call that uses a permission. Admin Activity logs record changes to configurations, not usage of permissions. Data Access logs must be enabled separately.

Mistake

The observation period for IAM Recommender is 30 days.

Correct

The observation period is 90 days. A confidence level of HIGH requires at least 30 days of data, but the full analysis window is 90 days.

Mistake

IAM Recommender considers deny policies from Organization Policies.

Correct

No, it does not. It only analyzes IAM allow policies. Deny policies from VPC Service Controls or Organization Policies are ignored, so a recommendation might suggest removing a role that is effectively denied.

Mistake

Policy Analyzer and IAM Recommender are the same thing.

Correct

They are different. Policy Analyzer lets you query existing IAM policies and simulate changes. IAM Recommender generates recommendations based on usage. Policy Analyzer does not generate recommendations.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

How long does IAM Recommender take to generate recommendations after enabling Data Access logs?

IAM Recommender needs at least 30 days of Data Access logs to generate HIGH confidence recommendations. It uses a 90-day observation window. After enabling Data Access logs, you may see LOW confidence recommendations after a few days, but meaningful recommendations typically appear after 30 days. The recommender processes logs daily.

Can IAM Recommender suggest custom roles?

IAM Recommender can suggest migrating to a less permissive predefined role, but it does not create custom roles. If a suitable predefined role does not exist, the recommender may suggest removing the role entirely or keeping it. You would need to create a custom role manually if needed.

Does IAM Recommender work with service accounts used by GCP services?

Yes, it analyzes all principals including service accounts. However, be cautious: some service accounts (e.g., Compute Engine default service account) may have roles that are used indirectly by GCP services. The recommender only sees direct API calls, so it might suggest removing a role that is actually needed for a service to function. Always verify before applying.

What permissions do I need to view and apply IAM Recommender recommendations?

To view: `recommender.iamPolicyInsights.get` and `recommender.iamPolicyRecommendations.get`. To apply: additionally `recommender.iamPolicyRecommendations.update` and the IAM permissions to modify the policy (e.g., `resourcemanager.projects.setIamPolicy`). The role `roles/recommender.iamAdmin` includes all these.

Can I use IAM Recommender at the organization level?

Yes. IAM Recommender can be used at the organization, folder, and project levels. You can view recommendations for all projects under an organization by selecting the organization in the Console or using the gcloud CLI with the --organization flag. This is useful for large-scale audits.

How does IAM Recommender handle roles with conditions?

IAM Recommender only analyzes conditions that are based on resource type or IP address. Conditions based on time, date, or other attributes are ignored, and the recommender may still recommend changes as if the condition did not exist. This can lead to inaccurate recommendations for conditional roles.

What is the difference between an insight and a recommendation in IAM Recommender?

An insight is a detailed analysis of usage for a specific principal and role, showing which permissions were used and which were not. A recommendation is a suggested action (remove role or migrate to another role) based on one or more insights. You can view insights using the `gcloud recommender insights list` command.

Terms Worth Knowing

Ready to put this to the test?

You've just covered Policy Intelligence and IAM Recommender — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.

Done with this chapter?