This chapter covers AWS IAM Access Analyzer, a security service that helps you identify resources in your AWS environment that are shared with external entities. For the CLF-C02 exam, this falls under Domain 2: Security and Compliance, Objective 2.2: Identify AWS services for security and compliance. While not a major topic, understanding IAM Access Analyzer is important for questions about finding unintended access. This chapter explains how it works, its use cases, and common exam traps.
Jump to a section
Imagine you own a large office building with many rooms, each containing sensitive documents. You've given keys to employees, contractors, and visitors, but over time, you've lost track of who has keys to which rooms. Some people might have keys they don't need—like a contractor who still has access to the executive suite long after their project ended. This is a security risk. To fix this, you hire a security guard named Analyzer. The guard doesn't block anyone; instead, he patrols the building with a list of 'suspicious behaviors' he's been told to watch for—like someone entering a room they've never entered before, or a key being used after hours when it shouldn't. Whenever he sees such behavior, he writes a report and slides it under your door. You can then decide whether to revoke that person's key or update your records. The guard never takes action himself; he only alerts you. This is exactly how AWS IAM Access Analyzer works: it continuously analyzes your AWS accounts for policies that grant access to resources from outside your organization (like a contractor's key), and generates findings that tell you exactly which policy is causing the risk. You then review and remediate. The mechanism is the same: the analyzer uses a 'zone of trust' (your AWS organization or account) and flags any access that crosses that boundary. It doesn't block anything—it just reports, so you can act.
What is AWS IAM Access Analyzer and What Problem Does It Solve?
AWS IAM Access Analyzer is a security service that continuously analyzes AWS resource policies to identify resources that are shared with an external entity—meaning an AWS account outside your organization, an AWS service, or an IAM role/user from another account. The problem it solves is 'unintended access.' In large AWS environments, it's easy to accidentally create a policy that grants access to a resource (like an S3 bucket or IAM role) to the entire internet or to another AWS account that you didn't intend. This can lead to data breaches. Access Analyzer automates the detection of such policies and alerts you via findings.
How It Works – The Mechanism
Access Analyzer works by defining a 'zone of trust.' The zone of trust is your AWS organization (if you have one) or your AWS account. Any access that originates from outside this zone is considered a potential security risk. The analyzer uses a mathematical analysis called 'policy analysis' to examine all resource-based policies (like S3 bucket policies, KMS key policies, IAM role trust policies, etc.) and determine if any statement grants access to a principal outside the zone of trust. It generates a finding for each such policy, detailing the resource, the external principal, and the action allowed. The findings are stored in the IAM console and can be viewed, archived, or resolved.
Key Configurations and Tiers
IAM Access Analyzer is available in two tiers: Basic and Custom Policy Checks. The Basic tier is free and includes:
Zone of trust: You define an analyzer for your account or your AWS organization.
Findings: Generated for resource policies that grant access to external entities.
Validation: Checks IAM policies for syntax and best practices (e.g., policy validation).
Custom policy checks: A paid feature that allows you to check policies against a custom policy (e.g., to ensure they meet your security standards).
For the CLF-C02 exam, focus on the Basic tier. There is no cost for the Basic analyzer itself; you only pay for findings if you use the custom policy checks (which are not covered in detail).
Comparison to On-Premises or Competing Approaches
On-premises, you might manually review firewall rules or access control lists (ACLs) to find unintended access. This is error-prone and doesn't scale. AWS IAM Access Analyzer automates this for cloud resources. Compared to AWS Trusted Advisor, which provides security checks (like S3 bucket permissions), Access Analyzer is more granular—it analyzes all resource-based policies, not just S3. AWS Config can also track resource configurations, but it doesn't analyze policies for external access; it just records changes. Access Analyzer is unique in its focus on external access.
When to Use It vs Alternatives
Use IAM Access Analyzer when you need to continuously monitor for resources that are accidentally shared with external accounts. It's best used in multi-account environments where cross-account access is common. If you need to audit changes to policies, use AWS Config. If you need a general security score, use AWS Trusted Advisor. For real-time monitoring of API calls that grant access, use AWS CloudTrail with AWS CloudWatch Events. Access Analyzer is a detective control—it doesn't prevent access; it alerts you after the fact.
How to Enable and Use IAM Access Analyzer
To enable, go to the IAM console, select Access Analyzer, and create an analyzer. You choose the zone of trust (your account or organization). The analyzer then starts scanning all supported resource types. Supported resources include:
Amazon S3 buckets
IAM roles (trust policies)
AWS KMS keys
AWS Lambda functions (resource-based policies)
Amazon SQS queues
Amazon SNS topics
AWS Secrets Manager secrets
And more.
Findings appear in the console. You can review each finding, see which policy statement causes the external access, and then decide to either:
Archive the finding if the access is intentional (e.g., a cross-account role for a trusted partner).
Resolve the finding by updating the policy to remove the external access.
Exam Relevance
For CLF-C02, you need to know:
IAM Access Analyzer helps identify resources shared with external entities.
It uses a zone of trust (your AWS account or organization).
It generates findings for resource-based policies that grant access outside the zone.
It does NOT block access; it only alerts.
It is not a firewall or a preventive control.
Common exam scenarios: A company wants to ensure no S3 buckets are publicly accessible. Access Analyzer can find buckets with policies that allow public access. Or, a company wants to know which IAM roles can be assumed by another account. Access Analyzer will find those roles.
CLI and Console Example
To create an analyzer via AWS CLI:
aws accessanalyzer create-analyzer --analyzer-name my-analyzer --type ACCOUNT --region us-east-1To list findings:
aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/my-analyzerIn the console, you navigate to IAM > Access Analyzer > Findings to see the list.
Limits and Defaults
You can have up to 5 analyzers per region per account (by default).
Findings are retained for 90 days after they are last updated.
The analyzer scans resources within the zone of trust; it does not scan resources in accounts outside the zone.
Cross-account access: If you have multiple accounts in an AWS organization, you can create an analyzer for the organization, and it will scan all accounts in the organization.
Summary of Mechanism
Think of Access Analyzer as a lens that looks at every resource policy and asks: "Does this policy allow access to someone outside my trusted zone?" If yes, it creates a finding. The finding includes the resource ARN, the external principal (e.g., the AWS account ID of the external entity), and the action (e.g., s3:GetObject). You then manually review and act. This is a detective control, not a preventive one.
Define Zone of Trust
The first step is to define what is considered 'trusted.' You create an analyzer and specify the zone of trust: either your AWS account or your entire AWS organization. If you choose an organization, the analyzer will scan resources in all accounts that are part of the organization. Behind the scenes, AWS Access Analyzer uses the organization's master account to get a list of member accounts and then scans each account's resources. You can have up to 5 analyzers per region per account. The zone of trust is critical because any principal outside this zone is flagged as external. For example, if your zone is account 111111111111, then a policy granting access to account 222222222222 will generate a finding. If your zone is the entire organization, then access from another account within the same organization is not flagged.
Analyze Resource Policies
Once the analyzer is created, it begins to scan all supported resource-based policies within the zone of trust. Supported resources include S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, SNS topics, and Secrets Manager secrets. The analyzer does not scan identity-based policies (policies attached to IAM users, groups, or roles) because those control access for principals within the account—they don't grant access to external principals directly. The scanning is continuous; whenever a resource is created or its policy is updated, the analyzer re-evaluates it. There is no manual trigger needed. The analysis uses a mathematical model of policy semantics to determine if any statement allows access to an external principal. This includes checking for wildcards (like 'Principal': '*') or specific external account IDs.
Generate Findings
When the analyzer finds a policy that grants access to an external principal, it generates a finding. Each finding includes: the resource ARN, the external principal (e.g., 'AWS: 123456789012' or 'AWS: *' for public access), the action allowed (e.g., 's3:GetObject'), and the condition under which the access is allowed. The finding is stored in the IAM console and is available via the AWS CLI and SDK. Findings are categorized by severity (high, medium, low) but the severity is based on the type of access (e.g., public access is high). The analyzer does not delete or modify any resources; it only reports. Findings are retained for 90 days after the last update. If the policy is updated to remove the external access, the finding is automatically resolved.
Review and Remediate
As an administrator, you review the findings in the IAM console. For each finding, you can see the full policy statement that caused the external access. You then decide whether the access is intentional or accidental. If intentional (e.g., a cross-account role for a trusted partner), you can archive the finding with a reason. Archiving does not change the policy; it just hides the finding from the active list. If the access is accidental, you must update the resource policy to remove the external access. For example, you might change an S3 bucket policy from 'Principal': '*' to 'Principal': 'AWS': 'arn:aws:iam::111111111111:root'. After updating the policy, the analyzer will re-scan and automatically resolve the finding (change its status to 'resolved'). You can also use the 'custom policy checks' feature to test a new policy before applying it, to ensure it doesn't introduce external access.
Monitor Continuously
Access Analyzer runs continuously in the background. There is no need to schedule scans. Whenever a new resource is created or an existing resource's policy is modified, the analyzer re-evaluates that resource within minutes. This ensures that any new unintended access is quickly detected. You can also set up AWS CloudWatch Events to send notifications when new findings are generated. For example, you can create a rule that triggers an SNS notification or a Lambda function to automatically respond to critical findings. This is important for security operations. The analyzer also supports integration with AWS Security Hub, so findings appear in a central dashboard. By default, findings are stored in the region where the analyzer was created. If you have multiple regions, you need an analyzer in each region to cover resources in that region.
Scenario 1: Accidental Public S3 Bucket
A startup uses S3 buckets to store user uploads. A developer creates a new bucket for a project and sets the bucket policy to allow public read access for testing, but forgets to remove it after testing. Weeks later, a security audit using IAM Access Analyzer reveals that the bucket policy grants 's3:GetObject' to 'Principal': '*'. The finding is flagged as high severity. The security team reviews the finding, confirms it's unintended, and updates the policy to remove public access. Without Access Analyzer, the bucket could have been exposed for weeks, leading to data leakage. Cost: Access Analyzer is free; the only cost is the time to review findings. Misconfiguration: If the team ignores the finding, the bucket remains public. The analyzer does not block access; it only alerts.
Scenario 2: Cross-Account Role for a Contractor
A company uses multiple AWS accounts. They create an IAM role in their production account that allows a contractor's AWS account to assume it. The contractor's project ends, but the role policy is not updated. Access Analyzer detects that the role's trust policy allows 'sts:AssumeRole' from the contractor's account (an external principal). The finding is generated. The security team reviews it, realizes the relationship is over, and updates the trust policy to remove the contractor's account. This prevents the contractor from accessing production resources. Cost: Free. What goes wrong: If the team archives the finding without investigation, the contractor retains access.
Scenario 3: Multi-Account Organization Monitoring
A large enterprise has hundreds of AWS accounts in an AWS Organization. They create a single organization-level analyzer that scans all accounts. This analyzer finds several KMS keys that have key policies allowing access from external AWS accounts (outside the organization). The security team uses these findings to identify and remove unnecessary cross-account KMS key access. This ensures that encryption keys are not shared with untrusted accounts. Cost: Free for the basic analyzer. Misconfiguration: If the analyzer is created at the account level instead of the organization level, it will miss cross-account access from other accounts in the same organization (since those are within the zone of trust? No, actually if the zone is a single account, other accounts in the organization are external). So the team must ensure the zone is set correctly. Also, if the organization has many accounts, findings can be numerous; proper filtering and automation are needed.
What CLF-C02 Tests on IAM Access Analyzer
The CLF-C02 exam tests IAM Access Analyzer under Domain 2: Security and Compliance, Objective 2.2: Identify AWS services for security and compliance. The exam expects you to know that IAM Access Analyzer is used to identify resources that are shared with external entities. You do not need to know CLI commands or detailed configuration. Focus on the purpose and basic mechanism.
Common Wrong Answers and Why
Wrong: 'IAM Access Analyzer prevents unauthorized access.' Why chosen: The name 'Access Analyzer' sounds like it controls access. Reality: It only analyzes and reports; it does not block or prevent access. It is a detective control, not a preventive one.
Wrong: 'IAM Access Analyzer analyzes identity-based policies.' Why chosen: Candidates confuse identity-based policies (attached to users/groups/roles) with resource-based policies. Reality: It analyzes resource-based policies (S3 bucket policies, KMS key policies, etc.) because those can grant access to external principals. Identity-based policies control what a user can do, not who can access a resource.
Wrong: 'IAM Access Analyzer replaces AWS Trusted Advisor for security.' Why chosen: Both provide security checks. Reality: Trusted Advisor checks for S3 bucket permissions and other best practices but is broader; Access Analyzer is specifically for external access via resource policies. They complement each other.
Wrong: 'IAM Access Analyzer can be used to enforce the principle of least privilege.' Why chosen: It sounds related. Reality: While it helps identify overly permissive policies, it does not enforce anything. AWS IAM Access Advisor (different service) helps with least privilege by showing last accessed services.
Specific Terms and Values That Appear on the Exam
Zone of trust: The AWS account or organization that is considered trusted.
External principal: An AWS account, IAM role, or service outside the zone of trust.
Findings: The alerts generated when external access is detected.
Resource-based policies: The type of policies analyzed.
Supported resources: S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, SNS topics, Secrets Manager secrets.
Tricky Distinctions
IAM Access Analyzer vs. AWS Config: Config tracks resource configuration changes; Access Analyzer analyzes policies for external access. A question might ask which service finds an S3 bucket with a public policy. Answer: Access Analyzer.
IAM Access Analyzer vs. AWS Trusted Advisor: Trusted Advisor includes S3 bucket permissions check but also many other checks. Access Analyzer is more comprehensive for external access across all resource types.
IAM Access Analyzer vs. IAM Policy Simulator: Policy Simulator tests the effect of a policy; Access Analyzer finds existing policies that grant external access.
Decision Rule for Multiple-Choice Questions
If the question asks about 'identifying resources shared with external accounts' or 'finding unintended access,' the answer is IAM Access Analyzer. If the question mentions 'blocking' or 'preventing,' look for a different service (like S3 Block Public Access or AWS Firewall). If the question mentions 'analyzing permissions for least privilege,' it's likely IAM Access Advisor.
IAM Access Analyzer identifies resources shared with external entities by analyzing resource-based policies.
It uses a zone of trust (your AWS account or organization) to determine what is external.
It generates findings for policies that grant access to principals outside the zone of trust.
It does NOT block or modify access; it is a detective control.
Supported resources include S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, SNS topics, and Secrets Manager secrets.
The basic tier is free; custom policy checks have additional costs.
Findings are retained for 90 days after last update.
You can have up to 5 analyzers per region per account.
It integrates with AWS Security Hub and CloudWatch Events for alerting.
Common exam trap: Confusing it with AWS Config or Trusted Advisor.
These come up on the exam all the time. Here's how to tell them apart.
AWS IAM Access Analyzer
Focuses specifically on resource-based policies that grant external access.
Generates findings for each policy that allows external access.
Supports multiple resource types (S3, IAM roles, KMS, etc.).
Continuously scans within a defined zone of trust.
Free basic tier.
AWS Trusted Advisor
Provides a broad range of best practice checks (cost, performance, security, fault tolerance).
Checks include S3 bucket permissions, security groups, and more.
Security checks are limited to a subset of resources (e.g., S3, security groups).
Checks are periodic and may require refresh.
Free basic checks for all customers; full checks require Business/Enterprise support.
Mistake
IAM Access Analyzer blocks access to resources that are shared externally.
Correct
IAM Access Analyzer does NOT block access. It only analyzes policies and generates findings. It is a detective control, not a preventive one. To block public access, you need services like Amazon S3 Block Public Access or AWS Organizations service control policies.
Mistake
IAM Access Analyzer analyzes all IAM policies, including identity-based policies.
Correct
It only analyzes resource-based policies (e.g., S3 bucket policies, KMS key policies, IAM role trust policies). Identity-based policies (attached to users, groups, roles) are not analyzed because they do not grant access to external principals directly.
Mistake
IAM Access Analyzer can be used to enforce the principle of least privilege.
Correct
While it helps identify overly permissive policies, it does not enforce anything. For least privilege, use IAM Access Advisor (which shows service last accessed) and IAM policy simulator. Access Analyzer focuses on external access, not internal permissions.
Mistake
IAM Access Analyzer only works for S3 buckets.
Correct
It supports many resource types including S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, SNS topics, and Secrets Manager secrets. The exam may ask which resources are supported.
Mistake
IAM Access Analyzer requires additional cost per finding.
Correct
The basic tier of IAM Access Analyzer is free. There is no charge for findings. The custom policy checks feature has costs, but that is not covered in CLF-C02. The exam expects you to know it is free.
IAM Access Analyzer identifies resources shared with external entities by analyzing resource-based policies. IAM Access Advisor shows the last accessed services for IAM users, groups, or roles, helping you refine permissions for least privilege. They are different services. Access Analyzer focuses on external access; Access Advisor focuses on internal usage. For the exam, remember: Access Analyzer = external sharing; Access Advisor = last accessed data.
Yes, but it depends on the zone of trust. If you create an analyzer for the entire AWS organization, then access from another account within the same organization is considered internal and will NOT generate a finding. If you create an analyzer for a single account, then access from any other account (including those in the same organization) is considered external and will generate a finding. This is a common exam nuance.
The basic IAM Access Analyzer is free. There is no charge for creating analyzers or for findings. The custom policy checks feature has a cost per check, but that is not covered in the CLF-C02 exam. So for the exam, assume it is free.
Yes, if an S3 bucket policy grants public access (e.g., 'Principal': '*' or 'Principal': { 'AWS': '*' }), Access Analyzer will generate a finding. It also finds buckets that are public via ACLs? Actually, Access Analyzer analyzes bucket policies, not ACLs. But S3 bucket policies are the primary way to grant public access. For ACLs, you would need to use S3 specific tools. However, the exam may still associate Access Analyzer with public S3 buckets.
Access Analyzer continuously scans. When you update the policy to remove the external access, the analyzer will re-evaluate the resource and automatically change the finding status to 'resolved.' You do not need to manually archive it. The resolved finding is still visible in the console but is no longer active. It is retained for 90 days.
Yes, through the custom policy checks feature (which is paid). You can test a new policy against a custom policy (e.g., a policy that defines allowed external accounts) to see if it would generate a finding. This helps prevent unintended access before deployment. However, this is not a focus of the CLF-C02 exam.
The zone of trust is the boundary within which access is considered trusted. It can be either your AWS account or your entire AWS organization. Any principal outside this zone is considered external. For example, if your zone is your account, then access from any other AWS account is external. If your zone is your organization, then access from accounts within the organization is internal. The zone is defined when you create the analyzer.
You've just covered AWS IAM Access Analyzer — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?