AWSAWS Certified Generative AI Developer - Professional2026-103.2 Implement data security and privacy controls
Review grants with the right evidence
Completed by the knowledge check
Learning objective
Identify overly broad IAM grants and unintended external access using IAM Access Analyzer.
Core idea
An access review needs several kinds of evidence. Resource-policy analysis asks who could access a resource. Unused-access analysis asks which granted permissions or credentials have not been used over a configured period. Policy validation asks whether a policy contains errors or security concerns. These questions overlap, but none answers all the others.
Choose IAM Access Analyzer’s analysis mode from the question, then review its findings against intended access. A finding is evidence for a decision, not an automatic declaration of compromise. Conversely, no external-access finding does not prove least privilege: a broadly authorized role inside the analyzer’s trust boundary can still have excessive permissions.
How it works
Define external exposure from the trust boundary
An external access analyzer uses an AWS account or organization as its zone of trust. Access granted to principals outside that boundary produces findings for supported resources. Principals inside the zone are considered trusted for this analysis. Define the boundary before interpreting results: the same cross-account grant can be external to an account analyzer and internal to an organization analyzer.
CreateAnalyzer selects the mode through type. ACCOUNT and ORGANIZATION select external access analysis. ACCOUNT_UNUSED_ACCESS and ORGANIZATION_UNUSED_ACCESS select unused access analysis. The API also distinguishes internal access with ACCOUNT_INTERNAL_ACCESS and ORGANIZATION_INTERNAL_ACCESS; internal analysis targets selected supported business-critical resources. Do not treat a single analyzer type as a combined answer to every access question.
External analysis covers supported resource policies, including S3 buckets, IAM role trust policies, KMS keys, Lambda functions, and Secrets Manager secrets. It identifies the resource, external principal, and granted permissions. Review those details to decide whether the grant is an approved integration, an accidental account-wide delegation, or public exposure that conflicts with your policy.
External access analyzers operate in the Region where they are enabled. Create them in each Region containing supported resources you need to monitor. Unused access findings do not vary by Region, so duplicating an unused analyzer in every resource Region is unnecessary. An inventory of Regions is therefore part of external-exposure coverage, not a cosmetic configuration detail.
The analysis detects possible access from policy configuration. It does not require evidence that the external principal used the permission. Keep actual-use investigation separate from possible-access review. For an agent’s document bucket, an external finding can demand action even if the application has not yet served a single conversation.
Find permissions broader than observed need
Unused access analysis monitors IAM users and roles. Findings identify unused roles, user access keys, user passwords, and unused service or action permissions for active identities. Use the findings to identify candidate removals and ask the workload owner whether the absent activity reflects unnecessary authority or an infrequent legitimate operation.
The UnusedAccessConfiguration.unusedAccessAge setting defines the access age in days, from 1 to 365. A 90-day value, for example, generates findings for access unused for at least that period since the analyzer’s last scan. This is an observation window, not an AWS guarantee that permission unused for 90 days is safe to remove.
Select the window to include representative deployment, recovery, and business cycles. An agent might use document reads daily but perform a quarterly export or a rarely exercised recovery operation. Review those capabilities deliberately rather than keeping every broad policy “in case,” or deleting every unused action without checking the recovery contract.
Policy generation supplies another form of evidence. StartPolicyGeneration analyzes a specified CloudTrail trail over a period of up to 90 days; GetGeneratedPolicy retrieves the generated template. Review and customize that template’s actions, resource scope, and conditions before attaching it.
Generated policies have documented limits. They do not identify action-level activity for data events such as S3 object data events, and iam:PassRole is not tracked by CloudTrail or included. Generation also reviews denied actions. A generated policy is therefore neither a complete entitlement inventory nor proof that every listed action should be allowed. For a retrieval workload, separately verify required object-read permissions rather than deleting them because the template omits them.
Validate policy documents before deployment
ValidatePolicy accepts the policy document and policyType, including IDENTITY_POLICY and RESOURCE_POLICY. For a supported resource-policy target, validatePolicyResourceType enables the appropriate checks; AWS::S3::Bucket identifies a bucket policy. Do not set that parameter for an identity policy.
Validation returns findings with details, issue codes, and locations in the document. AWS describes errors, security warnings, general warnings, and suggestions. Incorporate a review of these findings into policy changes. Fix a malformed or risky grant before it reaches production; explain any accepted warning against the workload’s requirements.
Custom policy checks test your security standard beyond ValidatePolicy’s grammar and best-practice checks. CheckNoNewAccess compares an updated policy with the existing policy; CheckAccessNotGranted checks that specified critical access, such as s3:DeleteObject, is not allowed by the policy. CheckNoPublicAccess tests whether a resource policy can grant public access to a specified resource type. Use these checks as pre-deployment gates for unintended expansion of grants.
Validation is not a substitute for external exposure analysis or application authorization. A syntactically valid policy can intentionally grant broad access. A narrowly scoped AWS grant can still let a shared application role read the wrong customer’s record if the application omits entitlement checks; see 3.2.2.
Close findings with a policy decision
For unintended external access, modify the resource policy or role trust policy that creates the grant. After a rescan confirms that access is removed, Access Analyzer changes the finding to resolved. StartResourceScan lets you request another scan of a reported resource rather than assuming the analysis updates synchronously with your edit.
Archive rules supplied through CreateAnalyzer.archiveRules automatically archive findings matching specified criteria. Use them for reviewed intentional access, with a documented owner and rationale. Archiving a finding does not revoke the grant; changing the granting policy does. Avoid a broad archive rule that hides all findings for a partner account when only one constrained integration is approved.
Key distinctions and trade-offs
External versus unused: External analysis finds principals outside the trust boundary who could access resources. Unused analysis finds granted authority without observed use over a configured period.
Validation versus generation: Validation examines a document’s grammar and security characteristics. Generation proposes permissions from activity and needs refinement before use.
Archive versus resolve: Archive records an accepted finding disposition. Resolve follows removal of the access that caused the finding.
Possible access versus actual use: Policy analysis can reveal exposure without an access event. Audit logs establish what requests occurred, subject to their logging coverage.
Architecture / decision scenario
A document assistant has an S3 bucket policy granting a partner account access and an application role carrying broad development permissions. The team wants to identify both unintended external access and excessive workload grants.
An account-level external analyzer finds the partner grant. Review shows the intended integration needs one prefix, so the owner narrows the bucket statement and requests StartResourceScan. A reviewed, constrained integration may be archived; the superseded broad grant must be removed.
An unused analyzer identifies unrelated service permissions on the application role. The team compares those findings with a representative CloudTrail-generated policy, adds verified S3 object-read requirements omitted from action-level generation, and narrows resources. ValidatePolicy checks the proposed identity policy and bucket policy separately. Negative access checks then confirm that unrelated services and unapproved partner reads fail.
Common exam traps
- Treating the organization’s trusted principals as automatically least privileged.
- Expecting an external analyzer in one Region to cover every Region.
- Deleting every unused permission without considering recovery or seasonal work.
- Treating a generated policy as complete or automatically safe.
- Confusing archive rules with revocation of resource permissions.
- Reading a policy exposure finding as proof of actual data access.
What to remember
- Select the analyzer mode and trust boundary explicitly.
- Review unused access against a representative period.
- Validate proposed policies and refine generated templates.
- Remove unintended grants and confirm the resulting findings.
- Use multiple evidence types to justify least privilege.
Knowledge check
An organization-level external access analyzer reports no findings for a document assistant’s application role, which still carries broad development permissions. The team needs evidence of which of those permissions the role never uses. Which analysis provides it?
ValidatePolicy run against the role’s identity policyValidatePolicy checks a document’s grammar and best practices, not whether its grants are exercised.A team runs an external access analyzer in us-east-1. A partner account has been granted access to the assistant’s document bucket in eu-west-1, but no finding appears. What explains the gap?
A policy generated from 90 days of CloudTrail activity lists no S3 object reads, yet the retrieval workload reads documents from S3 every day. What should the engineer do before attaching the generated policy?
iam:PassRole . A missing read is a known gap, not evidence that the read is unneeded, so required paths are verified separately and the template is reviewed before use. A longer period cannot close a data-event gap, and generation already reviews denied actions.An external finding shows a partner account can read the whole document bucket, while the approved integration needs one prefix. Which action closes the finding?
StartResourceScan confirms it, and the original finding becomes resolved.Every pull request that changes the assistant’s bucket policy must fail if the new policy allows s3:DeleteObject. Which check enforces that rule?
ValidatePolicy with validatePolicyResourceType set to AWS::S3::BucketCheckNoNewAccess comparing the new policy with the deployed oneCheckAccessNotGranted with s3:DeleteObject as the specified accessCheckAccessNotGranted tests a policy for specific critical access, which is the rule here. ValidatePolicy reports grammar and best-practice findings and does not know the team’s standard, CheckNoNewAccess passes a policy that already allowed deletion, and an analyzer scan runs after deployment.