Introduction

Yes, IAM policy values can contain multiple wildcard characters, but that does not mean wildcards are valid everywhere. In practice, multiple * or ? characters are allowed in many ARN and action patterns, as long as the part of the policy you are matching supports wildcards at all and you are not placing them in a forbidden ARN segment.

A Simple Example

A resource ARN can use more than one wildcard:

1{
2  "Effect": "Allow",
3  "Action": "s3:GetObject",
4  "Resource": "arn:aws:s3:::my-bucket/*/reports/*"
5}

This uses two * wildcards in one value. IAM accepts patterns like this in supported resource strings.

You can also see multiple wildcards in action patterns:

1{
2  "Effect": "Allow",
3  "Action": [
4    "ec2:Describe*",
5    "ec2:Get*"
6  ],
7  "Resource": "*"
8}

The key is not the number of wildcards. The key is whether that field supports pattern matching.

Where Multiple Wildcards Commonly Work

Wildcards are commonly used in:

• 'Action'
• 'NotAction'
• 'Resource'
• 'NotResource'

For example, a resource pattern with several wildcard segments:

1{
2  "Effect": "Allow",
3  "Action": "ssm:GetParameter",
4  "Resource": "arn:aws:ssm:*:123456789012:parameter/apps/*/prod/*"
5}

That pattern uses multiple * characters across different ARN segments and is a normal IAM pattern.

IAM also supports ? as a single-character wildcard in appropriate contexts.

The Important Limitation

Not every position inside an ARN can be wildcarded freely. A major rule is that you cannot put a wildcard into the service segment itself.

For example, this is not valid:

arn:aws:lam*:us-east-1:123456789012:function:my-function

Likewise, wildcard support depends on the policy element and sometimes on the service-specific resource model. A valid wildcard pattern for one AWS service may be meaningless for another if the action does not support resource-level permissions.

So the right mental model is:

• multiple wildcards are fine where wildcard matching is supported
• some ARN segments and policy contexts still have restrictions

Do Not Confuse Pattern Matching With Multiple Resources

There are two different ideas that often get mixed together:

1. one string pattern that contains wildcards
2. an array of explicitly listed resources

Pattern example:

"Resource": "arn:aws:s3:::my-bucket/*/reports/*"

Multiple explicit resources:

1"Resource": [
2  "arn:aws:s3:::my-bucket/team-a/reports/*",
3  "arn:aws:s3:::my-bucket/team-b/reports/*"
4]

Both are valid, but they solve different problems. If you can express intent narrowly with explicit resources, that is often safer than a very broad wildcard pattern.

Security Matters More Than Syntax

The real danger with multiple wildcards is not whether IAM accepts them. The real danger is that they may match more resources than you intended.

For example:

1{
2  "Effect": "Allow",
3  "Action": "iam:*",
4  "Resource": "*"
5}

This is syntactically valid and operationally dangerous. It grants far more than most policies should.

A pattern such as:

"Resource": "arn:aws:s3:::my-bucket/*"

may also be much broader than intended if your bucket stores many unrelated prefixes.

Test the Policy, Not Just the Pattern

When using multiple wildcards, validate the result by asking what real ARNs the pattern can match. This is especially important for:

• IAM users, roles, and policies
• S3 prefixes
• Systems Manager parameter hierarchies
• EC2 or Lambda resource patterns

The policy simulator and staged testing in a lower environment are worth using whenever the wildcard pattern is nontrivial.

Common Pitfalls

The biggest pitfall is thinking the rule is “multiple wildcards are either allowed everywhere or forbidden everywhere.” The real rule is more specific: they are allowed in many supported pattern fields, but not in every ARN segment or policy context.

Another common mistake is using wildcards when an explicit resource list would be safer and clearer.

People also often assume that because a resource ARN pattern is syntactically valid, the action must support resource-level permissions. Some AWS actions still require "Resource": "*" regardless of how precise you want to be.

Finally, broad wildcard use in IAM is often a security smell. The policy may work while still violating least-privilege principles badly.

Summary

• Yes, IAM values can contain multiple * or ? wildcards in supported pattern fields.
• Multiple wildcards are common in Action and Resource patterns.
• Wildcards are not valid in every ARN segment, so placement still matters.
• A syntactically valid wildcard pattern is not automatically a good least-privilege policy.
• Prefer explicit resource lists when they express intent more safely than broad patterns.