API deployment and stages in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding API Gateway Stage Variables

What is the effect of changing a stage variable in an AWS API Gateway stage?

A It only affects the API Gateway console display, not the actual API behavior.

B It requires redeploying the API for the changes to take effect.

C It immediately updates the deployed API behavior for that stage without redeploying.

D It deletes the current stage and creates a new one with the updated variables.

💡 Hint

Think about how stage variables are designed to allow quick configuration changes.

Stage variables in API Gateway act like environment variables for that stage. Changing them updates the API behavior immediately without needing a redeployment.

❓ Architecture

intermediate

Best Practice for Multiple API Environments

You want to maintain separate development, testing, and production environments for your API using AWS API Gateway. Which approach best supports this?

A Use one API and switch stage variables to simulate different environments.

B Use a single API with multiple stages named dev, test, and prod.

C Create separate APIs for dev, test, and prod environments.

D Deploy the API only once and use query parameters to differentiate environments.

💡 Hint

Consider how API Gateway stages are designed to represent different deployment environments.

Using multiple stages within a single API is the recommended way to manage different environments. It allows easy deployment and management without duplicating APIs.

❓ Configuration

advanced

Deploying API Gateway with CloudFormation

Given the following CloudFormation snippet, what will be the result after deployment?

Resources:
  MyApi:
    Type: AWS::ApiGateway::RestApi
    Properties:
      Name: "MyTestApi"
  MyDeployment:
    Type: AWS::ApiGateway::Deployment
    Properties:
      RestApiId: !Ref MyApi
      StageName: prod
    DependsOn: MyApi

AWS

Resources:
  MyApi:
    Type: AWS::ApiGateway::RestApi
    Properties:
      Name: "MyTestApi"
  MyDeployment:
    Type: AWS::ApiGateway::Deployment
    Properties:
      RestApiId: !Ref MyApi
      StageName: prod
    DependsOn: MyApi

A An API named 'MyTestApi' is created with a deployment to a stage named 'prod'.

B The deployment will fail because StageName is not allowed in AWS::ApiGateway::Deployment.

C The API is created but no deployment or stage is created automatically.

D The deployment creates a stage named 'prod' but the API is not created due to missing properties.

💡 Hint

Check the AWS CloudFormation documentation for AWS::ApiGateway::Deployment properties.

The StageName property in AWS::ApiGateway::Deployment creates a deployment and stage with the given name. The API resource is created first, then the deployment references it.

❓ security

advanced

Securing API Gateway Stages with IAM

You want to restrict access to a specific API Gateway stage so only users with a certain IAM role can invoke it. Which method achieves this?

A Use stage variables to specify allowed IAM roles for the stage.

B Set up a Lambda authorizer that checks the IAM role before allowing access.

C Configure API Gateway method request to require an API key linked to the IAM role.

D Attach a resource policy to the API Gateway stage allowing only the IAM role's ARN.

💡 Hint

Think about how resource policies control access at the API Gateway level.

Resource policies attached to API Gateway stages can restrict access by specifying allowed IAM roles or principals. This is the direct way to limit stage access by IAM role.

✅ Best Practice

expert

Managing API Gateway Deployments for Frequent Updates

Your team deploys API Gateway updates multiple times daily. You want to automate deployments and keep track of versions without overwriting previous deployments. Which approach is best?

A Create a new deployment resource with a unique description or timestamp each time and deploy to a fixed stage.

B Reuse the same deployment resource and update the stage to point to it each time.

C Manually delete old deployments before creating new ones to avoid clutter.

D Deploy only once and use stage variables to toggle features instead of redeploying.

💡 Hint

Consider how AWS API Gateway treats deployments as immutable snapshots.

Each deployment in API Gateway is immutable. Creating a new deployment resource with a unique identifier for each update allows version tracking and safe rollbacks. The stage can then be updated to point to the new deployment.