How do you audit who holds the AWS AmazonDynamoDBReadOnlyAccess managed policy?

What is actually being audited when you ask who holds the policy?

The first step is to treat the managed policy as an attachment problem, not just a name lookup. You are auditing every identity that can receive that policy, which usually means users, groups and roles, then tracing the effective path from those attachments to the workloads or operators that can act under them. In AWS, the attachment point is where exposure lives.

For IAM policy analysis and role review, use the AWS IAM Policies and Roles Guide to separate direct policy grants from role trust paths, permission boundaries and chained assumptions.

A useful audit also distinguishes direct attachment from inherited access. A user may not hold the policy directly, but still gain the same effective read-only DynamoDB capability through group membership or an assumed role. That is why the audit has to follow IAM relationships end to end, not stop at the policy attachment list.

How do you confirm whether the access is still justified?

Once you know who holds the policy, test whether that access is still needed for each principal. Read-only managed policies are often granted broadly during development or operations and then left in place after the original need disappears. The practical check is whether the principal still has an active business or runtime dependency on DynamoDB read access, and whether that access can be narrowed to specific tables or actions instead of remaining account-wide.

Reviewing who can hold the policy is also an audit trail problem. NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives is a useful reference when the policy is attached to roles that support applications, jobs or other non-human workloads, because the control objective is to prove why the access exists, not just that it exists.

Look for two common overreach patterns: direct attachment where a resource-scoped policy would be enough, and group-based sprawl where one membership change silently expands access for many identities. Both cases make later recertification harder because the policy looks benign even when the blast radius is broad.

What should you check around roles, workloads and stale access?

For roles, the key question is not only who is attached today, but what can assume the role and under what conditions. If a workload assumes the role, verify that the trust policy is still appropriate, that the workload is still owned, and that the role is not being reused across unrelated systems. Reuse and stale ownership are common reasons read-only access becomes a hidden dependency.

Cloud workload identity hygiene matters here because the policy may be harmless in isolation but risky when paired with a long-lived or widely reusable role. The Cloud Workload Identity Guide helps frame that review around role assumption, temporary credentials and workload-specific access paths rather than static grants.

If the role is attached to an application or automation path, confirm that the workload still needs DynamoDB visibility at runtime and that the policy is not compensating for poor application design, such as broad inventory queries or debugging access left behind after go-live. Auditing stale identities is especially important because old roles tend to survive long after the systems they were created for.

Risk and Threat Considerations

Broad read-only access is often underestimated because it does not directly change data. In practice, it can still expose sensitive business records, reveal table structure, and support attacker reconnaissance if the attached identity is compromised. The risk increases when the same principal also carries broader permissions elsewhere, because the managed policy then becomes part of a larger privilege set rather than a bounded read-only exception.

Failure mechanism: The policy is attached to too many identities, or to stale roles that are still assumable by active workloads or users, so effective access remains long after the original justification expired.

Impact: Unauthorized readers can discover sensitive data, map application dependencies, and move from seemingly harmless read access to broader operational or lateral abuse if the identity is also trusted elsewhere.

Practitioner Guidance

What to verify: Build the audit from the policy outward, then validate the reverse path. Confirm every user, group and role attachment, then confirm which workload or human actually uses each principal and whether the role trust path still matches the current system owner.

Decision rule: If the access can be replaced with a table-scoped or action-scoped policy without breaking the workload, treat the managed policy as overbroad and remove it from the principal. If the identity has no current owner or purpose, treat it as a decommissioning candidate before you accept it as an exception.

Practitioner takeaway: The real control is not counting attachments, it is proving that every attachment still maps to a live, bounded need and that read-only access is not hiding inside stale roles, inherited membership or broader privilege sets.

Related resources from NHI Mgmt Group

• How do you audit who holds the AWS AmazonBedrockFullAccess managed policy?
• AWS AmazonDynamoDBReadOnlyAccess Managed Policy
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?