Question 1

What is Amazon API Gateway?

Accepted Answer

API Gateway is a managed service for creating, publishing, securing and monitoring APIs at any scale. It handles request routing, authorisation, throttling, caching, request and response transformation, and integrates with Lambda, HTTP backends, and AWS services directly. The framing to give is that it moves cross-cutting concerns — authentication, rate limiting, validation, throttling — out of application code into the platform. That is what distinguishes it from putting a load balancer in front of a service.

Question 2

What is the difference between REST, HTTP and WebSocket APIs?

Accepted Answer

REST APIs are the full-featured original with request validation, transformation via mapping templates, caching, usage plans, API keys and WAF. HTTP APIs are newer, significantly cheaper and lower latency, with JWT authorisers and a simpler feature set. WebSocket APIs maintain persistent bidirectional connections for real-time applications. The selection rule is to default to HTTP APIs for cost and latency, and use REST APIs only when you need a specific feature they lack — caching, usage plans with API keys, request validation with models, or direct AWS service integrations with transformation.

Question 3

What authorisation options does API Gateway support?

Accepted Answer

IAM authorisation using SigV4 for AWS principals; Cognito user pool authorisers validating a user pool token; JWT authorisers for any OIDC provider on HTTP APIs; Lambda authorisers running custom logic and returning an IAM policy or a simple allow; API keys with usage plans for metering rather than authentication; and resource policies restricting by source. The point to make explicitly is that API keys are not authentication — they identify a caller for rate limiting and are trivially extractable from a client. Treating them as a security control is a common and serious mistake.

Question 4

What is a Lambda authoriser and how does caching work?

Accepted Answer

A Lambda authoriser is a function invoked before the request reaches the backend, receiving the token or request context and returning an IAM policy allowing or denying the call, plus optional context passed to the integration. Its result is cached per identity source for a configurable TTL to avoid invoking it on every request. The caching TTL is the trade-off between cost and revocation latency: a long TTL means a revoked token keeps working until it expires. The other detail is that returning a policy with a wildcard resource caches an allow for every route, which is a subtle over-authorisation bug.

Question 5

How does throttling work in API Gateway?

Accepted Answer

There are account-level, stage-level, method-level and usage-plan-level throttles, each with a steady-state rate and a burst allowance using a token bucket. Requests exceeding the limit receive a 429. Usage plans tie throttles and quotas to API keys so each consumer has its own limit. The layered model is the substance: a per-consumer usage plan protects other consumers, while a stage-level limit protects the backend overall. Naming that throttling at the gateway protects the downstream database as much as the API is the architectural point.

Question 6

What is API Gateway caching and when would you use it?

Accepted Answer

REST APIs support a dedicated cache per stage, sized from 0.5 GB upwards, keyed on the request path and configurable query parameters and headers, with a TTL. It reduces backend load and latency for repeated identical requests, and is charged hourly by cache size. The cache key design is where correctness lives: including an Authorization header in the key prevents cross-user leakage, and omitting a parameter that changes the response serves wrong data. Cache invalidation can be permitted per client with a header, controlled by IAM.

Question 7

What is the difference between proxy and non-proxy Lambda integration?

Accepted Answer

With proxy integration, API Gateway passes the entire request to Lambda as a standard event and expects a specific response shape with statusCode, headers and body. With non-proxy integration you write mapping templates in VTL to transform the request and response, giving control at the cost of maintaining template logic. Proxy integration is the default recommendation because VTL mapping templates are hard to test, debug and review. Non-proxy remains useful for direct AWS service integrations where you want the gateway to call DynamoDB or SQS without a Lambda in between.

Question 8

How do you call an AWS service directly from API Gateway without Lambda?

Accepted Answer

Use an AWS service integration: API Gateway signs and forwards the request to the service — putting a message on SQS, writing an item to DynamoDB, starting a Step Functions execution — with a mapping template shaping the payload and an IAM role granting the permission. The benefit is removing a Lambda that does nothing but forward, which cuts cost, latency and a failure point. The cost is VTL mapping logic that is harder to test, so it suits simple, stable transformations rather than business logic.

Question 9

What are API Gateway stages and how do you use them?

Accepted Answer

A stage is a named deployment of an API — dev, staging, prod — with its own URL, throttling, caching, logging, variables and WAF association. Stage variables can parameterise the integration so the same API definition points at different Lambda aliases or backend URLs per stage. Pointing a stage variable at a Lambda alias is the pattern that lets one API definition serve multiple environments and supports canary releases. API Gateway canary deployments split a percentage of stage traffic to a new deployment, which is worth naming.

Question 10

How do you version an API?

Accepted Answer

Either by path prefix such as /v1 and /v2 with separate routes, by a custom domain with base path mappings pointing at different stages, or by a header or media type. Whichever you choose, publish a deprecation policy and give consumers a migration window, because breaking changes to a public API are the real cost. The governance half is what interviewers value: the technical mechanism is easy, and the hard part is knowing who uses v1 and getting them to move. Usage plans and per-key metrics are what give you that visibility.

Question 11

What is a custom domain name in API Gateway?

Accepted Answer

A custom domain maps your own hostname to one or more APIs via base path mappings, with an ACM certificate. Regional endpoints terminate in the region; edge-optimised endpoints front the API with CloudFront. Route 53 alias records point the domain at the endpoint. The certificate region requirement is the detail that trips people: an edge-optimised custom domain requires the certificate in us-east-1 because CloudFront is global, while a regional domain needs it in the API's own region.

Question 12

How do you protect an API from abuse?

Accepted Answer

WAF at the gateway or a fronting CloudFront distribution with managed rule groups and rate-based rules; usage plans with per-key throttles and quotas; stage throttling to protect the backend; request validation to reject malformed payloads before invoking the integration; and authorisation so unauthenticated traffic never reaches compute. The ordering matters: drop abusive traffic at the edge where it is cheapest, meter per consumer at the API layer, and validate before invoking. Rate limiting only inside application code means the attack still consumes your compute, which is the point of the question.

Question 13

What is request validation in API Gateway?

Accepted Answer

REST APIs can validate required parameters, headers and a JSON body against a JSON Schema model, rejecting invalid requests with a 400 before invoking the backend. It removes boilerplate validation from the function and avoids paying to invoke it for a bad request. The cost argument is real at scale: rejecting malformed requests at the gateway costs a fraction of invoking a Lambda that immediately returns 400. HTTP APIs do not support body validation, which is one of the concrete reasons to choose REST APIs.

Question 14

What is AWS Step Functions?

Accepted Answer

Step Functions is a serverless orchestrator that coordinates services as a state machine defined in Amazon States Language, with states for task, choice, parallel, map, wait, pass, succeed and fail. It handles retries, error catching, timeouts and full execution history without you writing coordination code. The value over chaining Lambdas is visibility and reliability: a failed execution shows exactly which state failed with what input, and retry and catch behaviour is declarative rather than buried in code. That observability is usually the deciding argument.

Question 15

What is the difference between Standard and Express workflows?

Accepted Answer

Standard workflows run up to a year, are billed per state transition, guarantee exactly-once execution and retain full execution history — suited to long-running business processes. Express workflows run up to five minutes, are billed by duration and memory, give at-least-once semantics and much higher throughput, and log to CloudWatch rather than keeping history. The exactly-once versus at-least-once distinction is the design consequence rather than a pricing footnote: Express workflows require idempotent steps. The lack of execution history also means observability depends on CloudWatch Logs being configured properly.

Question 16

How does error handling work in Step Functions?

Accepted Answer

Each task state can define Retry with error matchers, interval, backoff rate and maximum attempts, and Catch to route specific errors to a handling state. Errors can be AWS-defined such as States.Timeout and States.TaskFailed, or custom errors thrown by the task. Declarative retry with exponential backoff is one of the strongest reasons to use Step Functions — implementing correct retry and backoff inside every Lambda is repetitive and easy to get wrong. Catch routing to a compensation branch is how sagas are implemented.

Question 17

What is a Map state and what is distributed map?

Accepted Answer

A Map state iterates over an array, running the same sub-workflow for each element, with configurable concurrency. Distributed Map extends this to very large datasets — millions of S3 objects or rows in a file — running up to ten thousand parallel child executions with batching, error-tolerance thresholds and result aggregation. Distributed Map is the managed answer to large-scale parallel processing that previously required hand-built coordinator functions. The error-tolerance threshold — continue if fewer than a set percentage fail — is a genuinely useful feature for batch work.

Question 18

What are Step Functions service integrations and the callback pattern?

Accepted Answer

Step Functions can call over two hundred AWS services directly, in three modes: request-response, which calls and continues; sync, which waits for completion such as an ECS task or a Glue job; and waitForTaskToken, which pauses until an external system calls SendTaskSuccess with a token — used for human approval or a long external process. The callback pattern is the one that unlocks human-in-the-loop workflows: the state machine pauses for up to a year while an approval email is answered. Naming it, rather than describing polling, is what shows real Step Functions experience.

Question 19

How would you implement a saga on AWS?

Accepted Answer

Model the transaction as a Step Functions state machine where each step performs a local transaction and a Catch routes failures to compensating states that undo the completed steps in reverse. Compensations must be idempotent because they can be retried, and each step should record enough state to know what needs undoing. Orchestration is preferable to choreography here because the compensation logic and current position are visible in one place. Naming that compensations are themselves fallible and need retry and alerting is the detail that separates a real implementation from a diagram.

Question 20

What is AWS AppSync?

Accepted Answer

AppSync is a managed GraphQL service with resolvers connecting a schema to DynamoDB, Lambda, RDS, OpenSearch, HTTP endpoints or EventBridge, plus real-time subscriptions over WebSockets, offline sync for mobile clients, caching and fine-grained authorisation. The advantage over REST is that clients fetch exactly the fields they need in one request, which matters for mobile. The trade-offs are caching complexity, the N+1 resolver problem needing batching, and query cost analysis to prevent expensive nested queries.

Question 21

When would you choose API Gateway over an Application Load Balancer for a service?

Accepted Answer

API Gateway when you want managed authorisation, per-consumer throttling and quotas, request validation, caching, API keys, direct AWS service integration or WebSocket support. An ALB when you have long-lived connections, want lower per-request cost at very high volume, need to route to containers or instances, or already terminate other traffic there. Cost is the practical crossover: API Gateway charges per request, so at very high sustained volume an ALB with a fixed hourly rate plus LCU charges becomes cheaper. Naming that crossover rather than treating it as a feature comparison is the mature answer.

Question 22

What are the API Gateway timeout and payload limits?

Accepted Answer

The integration timeout was historically capped at 29 seconds and is now configurable higher on REST APIs, with the request and response payload limited to 10 MB. WebSocket connections have their own idle and duration limits. The design implication is that long-running work must be asynchronous: accept the request, start a Step Functions execution or enqueue the work, return 202 with a status URL. Raising a timeout to accommodate a slow backend is treating the symptom.

Question 23

How do you handle long-running operations behind an API?

Accepted Answer

Return 202 Accepted with a job identifier and a status endpoint, having started a Step Functions execution or enqueued work in SQS. The client polls the status endpoint or receives a WebSocket or webhook notification on completion. This decouples client timeouts from processing time entirely. This is a design-judgement question and the failure is answering "increase the timeout". The asynchronous pattern is platform-independent and interviewers ask it to see whether you recognise a synchronous request as the wrong shape for the work.

Question 24

How do you enable CORS on API Gateway?

Accepted Answer

Configure CORS on the API so it responds to OPTIONS preflight requests with the appropriate Access-Control-Allow-Origin, headers and methods, and ensure the actual integration response also includes the origin header. With Lambda proxy integration, the function must return the CORS headers itself on the real response. The split responsibility is what confuses people: the gateway handles preflight but the function must add headers to the real response under proxy integration. Also, error responses generated by the gateway itself need gateway response CORS configuration, or errors appear as CORS failures in the browser.

Question 25

How do you monitor an API in production?

Accepted Answer

CloudWatch metrics for count, latency, integration latency, 4XX and 5XX rates per stage and method; access logs with a custom format including request ID, caller and latency; execution logs for debugging; X-Ray for tracing through to the backend; and alarms on error rate and p99 latency rather than averages. The distinction between latency and integration latency is the diagnostic value: it separates time spent in the gateway from time in your backend, which immediately tells you where a slowdown is. Alerting on 4XX as well as 5XX catches authorisation regressions after a deploy.

Question 26

What is Amazon Cognito and how does it relate to API Gateway?

Accepted Answer

Cognito user pools provide user directories with sign-up, sign-in, MFA, password policies and federation with social and enterprise identity providers, issuing JWTs. Identity pools exchange those tokens for temporary AWS credentials. API Gateway can validate user pool tokens directly with a Cognito authoriser. The distinction between user pools and identity pools is what interviewers check: user pools authenticate people and issue tokens, identity pools grant AWS credentials to those identities. Conflating them is the most common Cognito misunderstanding.

Question 27

What is a private API in API Gateway?

Accepted Answer

A private REST API is only accessible from within a VPC through an interface VPC endpoint, with a resource policy restricting which VPCs or endpoints may call it. It is used for internal APIs that must never be reachable from the internet. The resource policy is essential and often forgotten: without it, any VPC endpoint in any account that can reach the service could call the API. Combining the private endpoint type with an explicit resource policy is what actually restricts it.

Question 28

How do you deploy API changes safely?

Accepted Answer

Use stages with canary deployments, sending a percentage of traffic to a new deployment while monitoring error rate and latency, then promoting or rolling back. Point stage variables at Lambda aliases so the function version moves with the deployment, and manage the whole definition as code with SAM, CDK or CloudFormation. Managing the API definition as code is the part people skip, and console-edited APIs drift and cannot be recreated. Canary at the stage level plus Lambda alias weighting gives two independent rollback mechanisms.

Question 29

What is the difference between edge-optimised, regional and private endpoint types?

Accepted Answer

Edge-optimised routes clients through CloudFront edge locations to the API in its home region, reducing latency for globally distributed users. Regional serves clients from the region directly, which is better when clients are in the same region or when you want your own CloudFront distribution in front. Private is VPC-only. The recommendation for a global API is often regional plus your own CloudFront distribution, because that gives you control over caching, WAF and origin failover, which the managed edge-optimised distribution does not expose.

Question 30

How is API Gateway priced and how do you reduce cost?

Accepted Answer

Per million requests, with HTTP APIs roughly a third the price of REST APIs, plus data transfer and cache hours if enabled. Reduce cost by choosing HTTP APIs where features permit, caching responses, validating and rejecting bad requests at the gateway, and moving very high-volume public traffic behind CloudFront so cached responses never reach the API. The CloudFront point is the largest lever for a read-heavy public API: a cached response costs a fraction of an API Gateway request plus a Lambda invocation. Naming that layering is what turns a pricing answer into an architecture one.

Question 31

What is the WebSocket API and how does it work?

Accepted Answer

A WebSocket API maintains persistent bidirectional connections, routing messages by a route selection expression to Lambda or other integrations, with $connect, $disconnect and $default routes. Your backend sends messages to clients through the management API using the stored connection ID. The state you must manage is the connection registry — typically a DynamoDB table mapping connection IDs to users — since API Gateway does not track which user owns which connection. Cleaning up stale connections on $disconnect and on send failure is the operational detail.

Question 32

How do you test a serverless API?

Accepted Answer

Unit test the handlers with the business logic separated from the framework; use SAM local or LocalStack for local invocation; deploy to a test environment and run integration tests against the real API including authorisation; and contract-test the request and response shapes so consumers are protected from breaking changes. Testing authorisation in integration tests is the part usually skipped, and authorisation misconfiguration is one of the most consequential API bugs. Naming contract testing shows you think about consumers rather than only about your own service.

Question 33

What is the difference between Step Functions and Lambda chaining?

Accepted Answer

Chaining Lambdas means each function invokes the next, so the flow is implicit in code, error handling is bespoke, retries are hand-rolled and there is no single view of where an execution is. Step Functions makes the flow explicit and observable, with declarative retries, catches, timeouts and full execution history. The failure mode of chaining is debugging: reconstructing which step failed from logs across five functions is painful, and a partial failure can leave inconsistent state with no record. That observability gap is the strongest argument for orchestration.

Question 34

How do you pass large payloads through Step Functions?

Accepted Answer

State machine payloads are limited to 256 KB per state transition, so large data should be written to S3 with only a reference passed between states. Result selectors and result paths let you keep the payload small by extracting only the fields the next state needs. The claim-check pattern applies here exactly as it does to messaging. Using ResultSelector to trim a large API response before it enters the state payload is the specific technique that avoids hitting the limit in the first place.

Question 35

What is the difference between Standard workflow state transitions and Express duration billing?

Accepted Answer

Standard workflows are billed per state transition, so a workflow with many small states is expensive even if fast. Express workflows are billed by duration and memory, so a long-running workflow is expensive even with few states. The cost model should influence how you decompose the workflow. This directly affects design: a high-volume workflow with dozens of trivial states is much cheaper as Express, while a long-waiting workflow with few states is much cheaper as Standard. Naming that trade-off is a genuinely practical insight.

Question 36

How would you implement human approval in a workflow?

Accepted Answer

Use a task with waitForTaskToken: the state machine calls a service that sends a notification containing the task token, then pauses — for up to a year on Standard workflows — until an approval endpoint calls SendTaskSuccess or SendTaskFailure with that token, at which point the workflow continues down the appropriate branch. The token must be stored and secured, since anyone holding it can approve. Adding a heartbeat or timeout so an unanswered approval eventually escalates rather than hanging indefinitely is the operational completeness interviewers look for.

Question 37

What is an idempotency key and how would you implement it in an API?

Accepted Answer

The client sends a unique key with a mutating request; the server records it with the result of the first successful execution and returns that stored result on retry rather than re-executing. Storing the key and the business change in one transaction — for example a conditional write in DynamoDB — is what makes it correct. The transactional coupling is the subtle part: recording the key outside the transaction that performs the work leaves a window where a crash produces either a duplicate or a lost operation. Lambda Powertools implements this pattern, which is worth naming.

Question 38

How do you handle API errors consistently?

Accepted Answer

Define a standard error response shape with a machine-readable code, a human-readable message and a request identifier for correlation; map exceptions to appropriate status codes; never leak stack traces or internal detail; use gateway responses to give the same shape for errors generated by API Gateway itself; and log the request ID on both sides. Configuring gateway responses is the part usually missed — an authoriser failure or a payload-too-large error returns API Gateway's default shape, so clients see two different error formats. Making them consistent is a small change with real integration value.

Question 39

Design a serverless API for a mobile application on AWS.

Accepted Answer

CloudFront in front of an HTTP API with WAF and managed rules; Cognito user pools for authentication with a JWT authoriser at the gateway; Lambda handlers behind it, or direct service integrations for simple writes; DynamoDB for data with an access-pattern-driven model; S3 with presigned URLs for media uploads so bytes bypass compute; EventBridge for domain events with per-consumer SQS queues; Step Functions for multi-step processes with compensation; Secrets Manager for credentials; per-consumer usage plans if third parties call it; and X-Ray, structured logs and SLO-based alarms for observability. The closing scenario. The senior markers are authenticating and rate-limiting at the edge before compute is invoked, presigned uploads so large files never traverse Lambda, and asynchronous processing behind a 202 rather than long synchronous requests.

AWS API Gateway & Step Functions Interview Questions and Answers

How to use this set