Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in correctly restricting a service role’s trust relationship to only the intended Step Functions state machine. In production, this is about knowing exactly how conditions in the trust policy control which AWS resource can assume the role — preventing privilege escalation or misuse. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
Nimbus Technology is developing an orchestration workflow using AWS Step Functions. They have created a service role that the state machine assumes to execute its tasks. Security policy mandates that only the specific “OrderProcessingStateMachine” can assume this service role.
The Requirement: #
Ensure the trust policy of the service role restricts role assumption such that only the designated state machine named “OrderProcessingStateMachine” in the us-east-1 region under account 123456789012 can assume it.
The Options #
- A)
"Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:states:us-east-1:123456789012:stateMachine:OrderProcessingStateMachine" } } - B)
"Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:states:us-east-1::stateMachine:" } } - C)
"Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" } } - D)
"Condition": { "StringNotEquals": { "aws:SourceArn": "arn:aws:states:us-east-1:123456789012:stateMachine:OrderProcessingStateMachine" } }
Google adsense #
leave a comment:
Correct Answer #
A
Quick Insight: The DVA-C02 Lead Developer Imperative #
When limiting trust policy scope for Step Functions service roles, using a precise ArnLike condition with aws:SourceArn ensures the role can only be assumed by the intended state machine resource.
The other conditions do not correctly scope to the specific state machine, or negate trust, which violates least privilege principles.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option A
The Winning Logic #
This option uses the ArnLike condition on aws:SourceArn, explicitly referencing the full ARN of the state machine allowed to assume the role. This is the recommended best practice to limit role assumption to a single Step Functions state machine. The ARN includes region, account ID, and resource name, ensuring tight scoping.
- The trust relationship’s
"Condition"element filters the principal by the source ARN of the Step Functions invocation. - This ensures only the
OrderProcessingStateMachineresource from the exact account and region can assume the role. - This approach aligns with AWS’s principle of least privilege and prevents privilege escalation.
The Trap (Distractor Analysis): #
-
Why not Option B?
This condition lacks the account number and state machine name in the ARN pattern and is overly broad (arn:aws:states:us-east-1::stateMachine:). It allows any state machine, from any account (empty account field), to assume the role, which violates least privilege. -
Why not Option C?
Restricting byaws:SourceAccountonly limits by account but does not limit by specific state machine. Any state machine in that AWS account could assume the role, which does not meet the “only this state machine” requirement. -
Why not Option D?
UsingStringNotEqualsnegates the specified ARN. This would deny role assumption only if the source ARN matches the state machine, which is the opposite of the requirement (it would explicitly deny the correct machine).
The Technical Blueprint #
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "states.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:states:us-east-1:123456789012:stateMachine:OrderProcessingStateMachine"
}
}
}
]
}
The Comparative Analysis #
| Option | API Complexity | Security Precision | Use Case |
|---|---|---|---|
| A | Moderate (ArnLike cond) | High - tightly scoped to one state machine | Enforce single SM assumption |
| B | Low | Low - overly broad, no account | Broad state machine assumption |
| C | Low | Medium - restricts account, not resource | Allows all SMs in account |
| D | Medium | Incorrect logic - negation negates correct SM | Denies the intended SM |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick an ArnLike on aws:SourceArn condition when restricting a service role trust relationship to a specific Step Functions state machine.
Real World #
In real projects, developers often forget to include or correctly format the aws:SourceArn condition, leading to overly permissive roles with potential for misuse or accidental privilege escalation. Testing trust policies in a dev environment helps prevent these risks.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the DVA-C02 exam.