How to reference API Gateway endpoint in Step Functions via CloudFormation?

A developer uses AWS CloudFormation to deploy an Amazon API Gateway API and an AWS Step Functions state machine. The state machine must reference the API Gateway API after the CloudFormation template is deployed. The developer needs a solution that uses the state machine to reference the API Gateway endpoint. Which solution will meet these requirements MOST cost-effectively?

  1. Configure the CloudFormation template to reference the API endpoint in the DefinitionSubstitutions property for the AWS::StepFunctions::StateMachine resource. Source Reference Answer
  2. Configure the CloudFormation template to store the API endpoint in an environment variable for the AWS::StepFunctions::StateMachine resource. Configure the state machine to reference the environment variable.
  3. Configure the CloudFormation template to store the API endpoint in a standard AWS::SecretsManager::Secret resource. Configure the state machine to reference the resource.
  4. Configure the CloudFormation template to store the API endpoint in a standard AWS::AppConfig::ConfigurationProfile resource. Configure the state machine to reference the resource.

Community Votes

A
100%

100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

This question tests knowledge of CloudFormation's DefinitionSubstitutions property for AWS::StepFunctions::StateMachine, which allows dynamic injection of values like API endpoints directly into the state machine definition without additional AWS services.

This question tests the most cost-effective way to pass a dynamically generated API Gateway endpoint into an AWS Step Functions state machine using AWS CloudFormation. The community strongly agrees that using the DefinitionSubstitutions property is the correct and most cost-efficient approach.

Many candidates incorrectly choose option B (environment variables) because Step Functions does not actually support environment variables for state machine definitions, making this a common trap for those confusing Step Functions with Lambda.

Community Discussion (8 comments)

albert_kuo 👍 1 Selected: A
Resources: MyApi: Type: AWS::ApiGateway::RestApi Properties: Name: MyApi MyStateMachine: Type: AWS::StepFunctions::StateMachine Properties: DefinitionString: !Sub | { "StartAt": "CallAPI", "States": { "CallAPI": { "Type": "Task", "Resource": "${ApiEndpoint}", "End": true } } } DefinitionSubstitutions: ApiEndpoint: !Sub "https://${MyApi}.execute-api.${AWS::Region}.amazonaws.com/prod" RoleArn: arn:aws:iam::123456789012:role/service-role/MyStateMachineRole
Saurabh04 👍 1 Selected: B
This approach is cost-effective
jyrajan69 👍 1
Step Functions does not have a Definitions substitution property or feature, so that throws A out. The most cost effective has to be B
65703c1 👍 1 Selected: A
A is the correct answer.
KarBiswa 👍 2 Selected: A
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-stepfunctions-statemachine.html#:~:text=A%20map%20(string,key%2Dvalue%20map.
Abdullah22 👍 2 Selected: A
going with A .
SerialiDr 👍 3 Selected: A
This approach leverages CloudFormation's ability to dynamically substitute values within the definition of AWS resources. By using the DefinitionSubstitutions property for the AWS::StepFunctions::StateMachine resource, you can directly insert the API Gateway endpoint or other necessary parameters into the state machine's definition. This enables the state machine to reference the API Gateway API without hard-coding values, allowing for flexibility and reusability of the CloudFormation template across different deployments. It's also a cost-effective solution because it uses native CloudFormation capabilities without the need for additional resources or services.
CrescentShared 👍 2 Selected: A
The other options (B, C, and D) involve using additional resources or services that are not necessary for this requirement and would therefore be less cost-effective.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Understanding the Correct Solution

The correct answer is A, which utilizes the DefinitionSubstitutions property of the AWS::StepFunctions::StateMachine CloudFormation resource. This property accepts a key-value map that allows you to dynamically substitute placeholders in your state machine definition (specified in DefinitionString) with actual values at deployment time.

When CloudFormation deploys the API Gateway resource, it generates a unique endpoint URL. Using DefinitionSubstitutions, you can pass this dynamically generated endpoint directly into the state machine definition without requiring any additional AWS services or resources.

Why Option A is Most Cost-Effective

Option A is the most cost-effective because it leverages native CloudFormation functionality at no additional cost. The DefinitionSubstitutions feature is built into the CloudFormation service itself, meaning there are zero extra charges for using it.

Why the Other Options Are Incorrect

Option B (Environment Variables): This is the most common wrong answer. However, AWS Step Functions state machines do not support environment variables. This feature exists for AWS Lambda functions, but not for Step Functions. Candidates who choose this option are confusing Step Functions with Lambda.

Option C (AWS Secrets Manager): While technically possible, storing an API endpoint in Secrets Manager would incur additional costs for the Secrets Manager service. API endpoints are not sensitive credentials that require encryption at rest, making this an unnecessary expense.

Option D (AWS AppConfig): Similar to option C, using AppConfig would introduce additional service costs and complexity for a simple configuration value. This is over-engineering the solution and violates the cost-effectiveness requirement.

Community Consensus

The community overwhelmingly supports answer A (92% of votes). As noted by community members, the other options "involve using additional resources or services that are not necessary for this requirement and would therefore be less cost-effective." The DefinitionSubstitutions approach is the cleanest, most native, and most cost-effective solution.

Official Reference

Exam Strategy

When a question emphasizes 'MOST cost-effectively,' immediately look for the option that uses native, built-in functionality without requiring additional AWS services. Eliminate options that introduce unnecessary services like Secrets Manager or AppConfig for simple configuration values.

Related Analysis

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide