Ask most AWS Certified Security - Specialty (SCS-C02) candidates which service tells you that an S3 bucket or a KMS key has quietly been shared with an outside account, and you will hear GuardDuty, Macie, or AWS Config — all wrong. The answer is IAM Access Analyzer, and it shows up across the exam far more than its modest place on the blueprint suggests: in the Identity and Access Management questions about least privilege, in the Data Protection scenarios about resources exposed outside your organization, and in the Security Logging and Monitoring questions about routing findings to a central account.
IAM Access Analyzer is really four capabilities under one name, and the exam tests each one differently. This guide takes them one at a time — external access findings, unused access findings, policy validation, and custom policy checks — plus policy generation, and finishes with the decision table and signal words that let you pick it out of a lineup under time pressure. If you want the broader identity picture first, the SCS-C02 IAM deep dive sets the stage; here we focus entirely on Access Analyzer.
What IAM Access Analyzer Actually Is
The thing that makes Access Analyzer special — and worth an exam question — is how it reaches its conclusions. It does not sample traffic or watch logs. It uses automated reasoning, a branch of mathematical logic (AWS calls this “provable security”), to analyze the resource and identity policies in your account and prove statements about who can access what. Because the analysis is over policy logic rather than observed behavior, it can find an exposure that has never actually been exploited, and it produces no false “someone accessed this” noise.
Keep that distinction sharp for the exam:
- Access Analyzer reasons about policies — “could this be accessed from outside?”
- GuardDuty reasons about behavior in logs — “did something anomalous happen?”
- Macie reasons about data content — “does this S3 object contain sensitive data / PII?”
- AWS Config reasons about configuration state over time — “is this resource compliant with my rules?”
Any question that says “identify resources shared with an external entity” or “validate a policy before deployment” is an Access Analyzer question, full stop.
External Access Findings and the Zone of Trust
The original and most heavily tested feature is the external access analyzer. When you create one, you define a zone of trust — either a single account or an entire AWS Organization. Access Analyzer then continuously monitors the resource-based policies in that zone and raises a finding whenever a resource grants access to a principal outside the zone of trust.
Supported resource types are exactly the ones that carry resource policies and matter for a data perimeter, including:
| Category | Resources analyzed for external access |
|---|---|
| Storage | S3 buckets (and access points), EBS snapshots, RDS DB snapshots, EFS file systems |
| Identity | IAM roles (their trust policies) |
| Data protection | KMS keys, Secrets Manager secrets |
| Messaging | SNS topics, SQS queues |
| Compute / registry | Lambda functions and layers, ECR repositories |
| Databases | DynamoDB tables and streams |
Each finding names the resource, the external principal, the condition (if any), and the access level granted. This is the exam’s favorite Data Protection scenario: “Security wants to know every S3 bucket and KMS key in the organization that is accessible from outside the organization.” The correct move is an organization-level external access analyzer, not a hand-written script over bucket policies.
Archive rules cut the noise
Not every external grant is a mistake. If you deliberately share a bucket with a known partner account, you do not want that finding nagging you forever. Archive rules automatically archive new findings that match criteria you define (for example, a specific trusted account ID), so the active-findings list stays focused on the unexpected exposures. Expect a distractor that suggests “delete the finding” — you archive, not delete, and an archive rule automates it.
Organization scope and the delegated administrator
At organization scale you create the analyzer from the management account or, better, from a delegated administrator account so a dedicated security account owns Access Analyzer without needing management-account access. Findings across all member accounts land centrally, and they can be forwarded to AWS Security Hub and Amazon EventBridge for aggregation and automated response. This ties Access Analyzer to the multi-account patterns in the multi-account governance guide.
Unused Access Findings: Pruning Over-Permissioned Identities
The newer analyzer type flips the question from “what is exposed?” to “what is granted but never used?” An unused access analyzer continuously reviews your IAM roles and users and reports:
- Unused roles — roles that have not been assumed within your chosen tracking period.
- Unused access keys and passwords — long-lived credentials that are not being used.
- Unused permissions — services and actions a role or user is granted but has not exercised.
It builds on IAM last-accessed information but presents it as continuous, centralized findings with a dashboard, which is exactly what a least privilege program needs. On the exam, the signal is “identify IAM roles and permissions that are not being used so we can remove them” → unused access analyzer.
Two facts worth remembering: the external access analyzer is free, while the unused access analyzer is a paid feature billed per analyzed IAM role or user per month. And unused access is about identities (roles, users, permissions), whereas external access is about resources — mixing those two up is a classic trap.
Policy Validation: Catching Bad Policies Before They Ship
Every time you author a policy in the IAM console, Access Analyzer is already working: policy validation checks your policy against IAM grammar and more than 100 policy checks and best practices, returning findings grouped by severity:
- Errors — the policy will not work as written (syntax or logic that AWS will reject or ignore).
- Security warnings — the policy is valid but risky (for example, a statement that allows a broad, sensitive action).
- Warnings — non-security issues such as a deprecated global condition key.
- Suggestions — cosmetic or best-practice nudges (an empty
Sid, redundant elements).
The point the exam cares about is that this is programmable. You call it from a pipeline:
aws accessanalyzer validate-policy \
--policy-document file://s3-read-policy.json \
--policy-type IDENTITY_POLICYWiring validate-policy into CI/CD so a merge request fails when it introduces a security warning is the AWS-blessed way to enforce policy quality at scale — a much better answer than “have a human review every policy.”
Custom Policy Checks: Proving a Change Grants No New Access
Policy validation tells you if a policy is well-formed and reasonable. Custom policy checks answer a sharper, automated-reasoning question: does this policy change cross a line I care about? There are three, and the exam expects you to match each to its scenario:
| Check | Question it answers | Typical use |
|---|---|---|
CheckNoNewAccess | Does the new policy grant any access the reference policy did not? | Block a PR that widens permissions beyond an approved baseline |
CheckAccessNotGranted | Does the policy grant a specific action or resource you have forbidden? | Guarantee iam:PassRole or s3:DeleteBucket is never granted |
CheckNoPublicAccess | Does the resource policy make the resource publicly accessible? | Fail a build if an S3 bucket or SQS queue policy would go public |
Example — fail a pipeline if a proposed policy grants any new access relative to the current one:
aws accessanalyzer check-no-new-access \
--new-policy-document file://new.json \
--existing-policy-document file://existing.json \
--policy-type IDENTITY_POLICY
# Returns PASS or FAIL with reasonsThese checks use the same provable-security engine as external access findings, they return a deterministic PASS/FAIL, and they are paid per check. When a scenario says “prove, before deployment, that a policy change does not grant new permissions” or “ensure a specific dangerous action is never allowed,” that is a custom policy check — not policy validation, and not a manual review gate.
Policy Generation: Least Privilege From Real Activity
The last capability closes the least-privilege loop. Policy generation reads CloudTrail activity for a role or user over a date range and generates an IAM policy containing only the actions that identity actually used. Instead of guessing at a policy and iterating on AccessDenied errors, you let a role run with broad permissions in a non-production window, then generate a tight policy from what it did.
The exam signal is unmistakable: “generate a least-privilege policy based on the actions a role has actually performed” → Access Analyzer policy generation from CloudTrail logs. It depends on CloudTrail being enabled for the account and Region in question, which links neatly to the logging foundations every SCS-C02 candidate should already have from the SCS-C02 domains overview.
The Decision Table: Picking Access Analyzer Out of a Lineup
| Scenario wording | Right answer |
|---|---|
| ”Which S3 buckets / KMS keys are shared outside the organization?” | External access analyzer (organization zone of trust) |
| “Suppress findings for a known, trusted partner account” | Archive rule |
| ”Find IAM roles and permissions that are never used” | Unused access analyzer |
| ”Check a policy against best practices in the pipeline” | Policy validation (validate-policy) |
| “Prove a policy change grants no new access” | CheckNoNewAccess custom policy check |
| ”Guarantee a specific action is never granted” | CheckAccessNotGranted custom policy check |
| ”Fail a build if a resource policy would be public” | CheckNoPublicAccess custom policy check |
| ”Generate a least-privilege policy from real usage” | Policy generation from CloudTrail |
| ”Central visibility of external access across accounts” | Delegated admin + org analyzer → Security Hub / EventBridge |
And the “not this service” reflexes that save you on the hard questions: sensitive-data discovery is Macie, anomaly detection from logs is GuardDuty, configuration compliance over time is AWS Config, and encryption-key management is KMS (see the KMS and data protection guide). Access Analyzer is the one that reasons about policy — external exposure, unused permissions, and policy correctness.
Practice Under Real Exam Conditions
Access Analyzer questions reward candidates who can separate its five jobs quickly, because the wrong answers are all real AWS services doing plausible-sounding things. The only way to make those distinctions automatic is repetition against exam-style scenarios that phrase the problem the way the real test does.
Sailor.sh’s AWS Security Specialty (SCS-C02) Certification-Ready Mock Exam Bundle is built for exactly that — scenario-driven questions across all five domains, with explanations that reinforce why Access Analyzer beats GuardDuty or Config in a given wording. Work the mocks alongside the full SCS-C02 exam guide for 2026, and treat every Access Analyzer question you miss as a chance to sharpen one of the five distinctions above.
Frequently Asked Questions
What is the difference between external access and unused access analyzers?
External access analyzers examine resource policies and report resources shared outside your zone of trust (an account or organization). Unused access analyzers examine IAM identities and report roles, credentials, and permissions that are granted but not used. External access is free; unused access is a paid feature.
Is IAM Access Analyzer free?
The external access analyzer and policy validation are free. The unused access analyzer (billed per analyzed role/user per month) and custom policy checks (billed per check) are paid features.
How is Access Analyzer different from GuardDuty and Macie?
Access Analyzer uses automated reasoning over policies to find exposure and validate permissions. GuardDuty detects threats and anomalies from logs (VPC Flow Logs, DNS, CloudTrail). Macie discovers sensitive data inside S3 objects. They answer different questions and often appear together as distractors.
What are custom policy checks used for?
They provide deterministic PASS/FAIL guardrails in CI/CD: CheckNoNewAccess (a change grants no access beyond a reference), CheckAccessNotGranted (a forbidden action is never allowed), and CheckNoPublicAccess (a resource policy is not public). They rely on the same provable-security engine as external access findings.
How does policy generation work?
Access Analyzer reads CloudTrail activity for a chosen role or user over a date range and generates an IAM policy containing only the actions that identity actually used — a fast path to least privilege that needs CloudTrail enabled for the relevant account and Region.
How do I set up Access Analyzer for an entire organization?
Create the analyzer with the organization as the zone of trust, ideally from a delegated administrator account so a security account owns it without management-account access. Route findings to Security Hub and EventBridge for central visibility and automated response.
Conclusion
IAM Access Analyzer earns its exam weight by wearing five hats: external access findings that expose resources shared outside your zone of trust, unused access findings that prune over-permissioned identities, policy validation that catches bad policies before they ship, custom policy checks that prove a change stays within bounds, and policy generation that builds least-privilege policies from real CloudTrail activity. Learn to map each scenario wording to the right capability — and to reject Macie, GuardDuty, and Config when the question is really about policy — and Access Analyzer turns from a service people forget into a cluster of reliable points across the Identity, Data Protection, and Monitoring domains of the SCS-C02.