DynamoDB resource-based policy: wildcard Principal with Condition keys – precedence uncertainty

Background

\n

In DynamoDB, resource-based policies allow direct table permissions. A common pattern is to set Principal: "*" and then constrain access with a Condition such as aws:PrincipalOrgID. AWS evaluation states that an explicit Denys in any policy overrides an Allow. However, when a resource-based policy uses a wildcard Principal with a Condition that restricts to a specific organization, and an identity-based policy grants broader access, the effective decision is unclear.

\n

Unresolved Behavior

\n

It is not documented whether the Condition on a wildcard Principal is evaluated before the statement is considered part of the policy or whether the statement is treated as a blanket allow that can be overridden by a Deny elsewhere. The interaction between resource-based Deny statements and identity-based Allow statements has been observed to vary across services, and DynamoDB’s current documentation leaves the precedence rules ambiguous.

\n

Specific Questions

\n

\n
• When a resource-based policy contains Principal: "*" with a Condition restricting to aws:PrincipalOrgID, does the Condition effectively limit public access, or is the statement still treated as a global allow?
\n
• Does an explicit Deny in a DynamoDB resource-based policy always override an Allow in an identity-based policy, even when the resource-based statement uses a wildcard Principal?
\n
• What is the recommended pattern to guarantee that a wildcard Principal does not inadvertently expose a table to any AWS account if the Condition key is omitted or misconfigured?
\n