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.

Practice

1. What is the main purpose of an API stage in AWS API Gateway?

easy

A. To monitor network traffic outside AWS

B. To store API keys for users

C. To create backend Lambda functions

D. To manage different versions or environments of the API

Solution

1. Step 1: Understand API stages concept

   API stages in AWS API Gateway represent different versions or environments like development, testing, or production.

2. Step 2: Identify the role of stages

   Stages allow you to deploy and manage separate API versions independently.

3. Final Answer:

   To manage different versions or environments of the API -> Option D

4. Quick Check:

   API stages = version/environment management [OK]

Hint: Stages separate API versions or environments [OK]

Common Mistakes:

• Confusing stages with API keys
• Thinking stages create backend functions
• Assuming stages monitor external traffic

2. Which AWS CLI command is used to create a new deployment for an API Gateway REST API?

easy

A. aws apigateway create-deployment

B. aws apigateway create-stage

C. aws apigateway deploy-api

D. aws apigateway new-deployment

Solution

1. Step 1: Identify the correct AWS CLI command for deployment

   The command to create a deployment in API Gateway is create-deployment.

2. Step 2: Differentiate from other commands

   create-stage creates a stage, not a deployment. Other options are invalid commands.

3. Final Answer:

   aws apigateway create-deployment -> Option A

4. Quick Check:

   Deployment command = create-deployment [OK]

Hint: Deploy with 'create-deployment' command [OK]

Common Mistakes:

• Using create-stage instead of create-deployment
• Assuming deploy-api is a valid command
• Confusing deployment with stage creation

3. Given the following AWS CLI command:
aws apigateway create-stage --rest-api-id abc123 --stage-name prod --deployment-id dep456
What does this command do?

medium

A. Creates a new deployment named 'prod' for API 'abc123'

B. Creates a new stage 'prod' linked to deployment 'dep456' for API 'abc123'

C. Deletes the stage 'prod' from API 'abc123'

D. Updates the deployment 'dep456' with stage 'prod'

Solution

1. Step 1: Analyze the command parameters

   The command is create-stage with parameters for API ID, stage name, and deployment ID.

2. Step 2: Understand the effect of create-stage

   This creates a new stage named 'prod' that points to the deployment 'dep456' for the API 'abc123'.

3. Final Answer:

   Creates a new stage 'prod' linked to deployment 'dep456' for API 'abc123' -> Option B

4. Quick Check:

   create-stage + deployment-id = new stage linked to deployment [OK]

Hint: create-stage links stage to deployment by deployment-id [OK]

Common Mistakes:

• Confusing stage creation with deployment creation
• Thinking it deletes or updates instead
• Mixing up stage name and deployment ID

4. You ran this command to deploy your API stage:
aws apigateway create-stage --rest-api-id abc123 --stage-name test --deployment-id dep789
But you get an error saying the deployment ID does not exist. What is the likely cause?

medium

A. The deployment ID 'dep789' was not created before creating the stage

B. The stage name 'test' is invalid

C. The rest-api-id 'abc123' is incorrect format

D. You must create the stage before creating the deployment

Solution

1. Step 1: Understand the dependency between deployment and stage

   A stage must point to an existing deployment. If deployment ID does not exist, stage creation fails.

2. Step 2: Identify the error cause

   The error indicates deployment 'dep789' was not created or is invalid before stage creation.

3. Final Answer:

   The deployment ID 'dep789' was not created before creating the stage -> Option A

4. Quick Check:

   Stage needs existing deployment ID [OK]

Hint: Create deployment before stage with deployment ID [OK]

Common Mistakes:

• Assuming stage name format causes error
• Thinking API ID format is the issue
• Believing stage must be created before deployment

5. You want to deploy a new version of your API to a 'prod' stage without affecting the current live API. Which sequence of AWS CLI commands should you use?

hard

A. aws apigateway create-deployment -> aws apigateway create-stage with 'prod'

B. aws apigateway create-stage with 'prod' -> aws apigateway create-deployment

C. aws apigateway create-deployment -> aws apigateway update-stage with 'prod'

D. aws apigateway update-stage with 'prod' -> aws apigateway create-deployment

Solution

1. Step 1: Deploy new API version

   First, create a new deployment to capture the latest API changes.

2. Step 2: Update existing 'prod' stage to point to new deployment

   Use update-stage to switch the 'prod' stage to the new deployment without creating a new stage.

3. Final Answer:

   aws apigateway create-deployment -> aws apigateway update-stage with 'prod' -> Option C

4. Quick Check:

   Deploy then update stage to switch versions [OK]

Hint: Create deployment then update existing stage [OK]

Common Mistakes:

• Creating a new stage instead of updating existing
• Updating stage before deployment exists
• Assuming create-stage can update existing stage