Skip to main content

AWS DVA-C02 Drill: Step Functions Service Role Trust Policies - Securing Assumptions

Jeff Taakey
Author
Jeff Taakey
21+ Year Enterprise Architect | AWS SAA/SAP & Multi-Cloud Expert.

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 OrderProcessingStateMachine resource 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 by aws:SourceAccount only 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?
    Using StringNotEquals negates 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.

The DevPro Network: Mission and Founder

A 21-Year Tech Leadership Journey

Jeff Taakey has driven complex systems for over two decades, serving in pivotal roles as an Architect, Technical Director, and startup Co-founder/CTO.

He holds both an MBA degree and a Computer Science Master's degree from an English-speaking university in Hong Kong. His expertise is further backed by multiple international certifications including TOGAF, PMP, ITIL, and AWS SAA.

His experience spans diverse sectors and includes leading large, multidisciplinary teams (up to 86 people). He has also served as a Development Team Lead while cooperating with global teams spanning North America, Europe, and Asia-Pacific. He has spearheaded the design of an industry cloud platform. This work was often conducted within global Fortune 500 environments like IBM, Citi and Panasonic.

Following a recent Master’s degree from an English-speaking university in Hong Kong, he launched this platform to share advanced, practical technical knowledge with the global developer community.


About This Site: AWS.CertDevPro.com


AWS.CertDevPro.com focuses exclusively on mastering the Amazon Web Services ecosystem. We transform raw practice questions into strategic Decision Matrices. Led by Jeff Taakey (MBA & 21-year veteran of IBM/Citi), we provide the exclusive SAA and SAP Master Packs designed to move your cloud expertise from certification-ready to project-ready.