Troubleshooting AccessDenied: IAM Policy StringNotEquals with Wildcard in SageMaker
Exhibit
Refer to the exhibit.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sagemaker:CreateTrainingJob",
"Resource": "*",
"Condition": {
"StringEquals": {
"sagemaker:TrainingJobName": "*production*"
}
}
},
{
"Effect": "Deny",
"Action": "sagemaker:CreateTrainingJob",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"sagemaker:TrainingJobName": "*production*"
}
}
}
]
}A data scientist is trying to create a training job named 'test-model' using an IAM role with the attached policy. The creation fails with an AccessDenied error. What is the most likely cause?
Quick Answer
IAM condition operators are string-literal matches unless the operator explicitly says otherwise, and StringNotEquals is one of the operators that does not support wildcard characters like an asterisk. A Deny statement built around StringNotEquals with a wildcard value is a policy-authoring mistake because IAM won't interpret that asterisk as a pattern the way it would in a Resource ARN or in operators like StringLike, instead the comparison simply never behaves as the author intended, since the wildcard is treated as a literal character rather than a matching pattern. When a Deny condition doesn't evaluate the way its author expected, the policy engine can end up denying access in situations the author never intended to block, which is exactly the kind of unexpected AccessDenied error described here. The core lesson is that IAM condition operators fall into two families, those that support wildcards, such as StringLike and ArnLike, and those that require exact matches, such as StringEquals and StringNotEquals, and mixing a wildcard into an exact-match operator produces silent, hard-to-diagnose failures rather than a syntax error you'd catch at policy-creation time. Whenever a scenario shows an unexpected AccessDenied error and a policy that looks reasonable at a glance, check whether any condition operator that requires exact string matching has been given a wildcard value, since that mismatch is a common and easy-to-miss root cause on the exam.
⚠ Common exam trap
Test-takers frequently assume 'StringNotEquals' supports wildcards like 'StringNotLike' does, or they may focus on the Resource wildcard (Option A) as the obvious cause, missing the subtle condition operator mismatch.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The Deny statement uses a wildcard '*' in the condition value, which is not supported for StringNotEquals.
The Deny statement uses 'StringNotEquals' with a wildcard '*' in the condition value, which is not supported for the 'StringNotEquals' condition operator in IAM policies. The 'StringNotEquals' operator requires exact string matching and does not support wildcards; using '*' will cause the condition to never match, effectively making the Deny statement non-functional or causing unexpected behavior. This mismatch leads to an AccessDenied error because the policy evaluation fails to properly deny or allow the action.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The Resource is set to '*' and should be specific.
Why it's wrong here
'*' is allowed.
- ✗
The Deny statement uses 'StringNotEquals' which should be 'StringEquals'.
Why it's wrong here
Even with StringEquals, the logic would still deny non-matching names.
- ✗
The IAM role does not have permission to assume the SageMaker execution role.
Why it's wrong here
Not indicated in the policy.
- ✓
The Deny statement uses a wildcard '*' in the condition value, which is not supported for StringNotEquals.
Why this is correct
Wildcards are not supported in StringNotEquals conditions, causing unexpected denial.
Go deeper
Related to this question
About these practice questions
This MLS-C01 question is part of Courseiva's 1,672-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on MLS-C01
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A data scientist is trying to create a SageMaker training job using an execution role with the attached IAM policy. The training job fails with an access denied error when trying to read training data from the S3 bucket 'my-bucket'. What is the most likely cause?
easy- ✓ A.The S3 bucket policy explicitly denies access to the role.
- B.The IAM policy does not include s3:ListBucket permission.
- C.The S3 bucket is in a different AWS account.
- D.The sagemaker:CreateTrainingJob action is not allowed.
Why A: The most likely cause is that the S3 bucket policy explicitly denies access to the SageMaker execution role. Even if the IAM policy grants the necessary permissions, an explicit deny in the bucket policy overrides any allow, resulting in an access denied error when the training job attempts to read training data from the S3 bucket.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This MLS-C01 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the MLS-C01 exam.