5 exercises — choose the best-structured answer to common API gateway architecture interview questions. Focus on rate limiting, circuit breakers, versioning, mTLS, and gateway extensibility.
Structure for API gateway interview answers
Name the algorithm or pattern mechanically: define how it works, not just what it does
Cover state machines: circuit breakers and rate limiters have explicit states and transition conditions
Address distributed concerns: shared state, consistency, and failure modes across gateway instances
Cite specific tooling: Kong, Envoy, Nginx — name the config options and plugin interfaces
0 / 15 completed
1 / 15
The interviewer asks: "Compare token bucket, leaky bucket, and sliding window counter rate limiting algorithms — when would you implement each at an API gateway?" Which answer best covers rate limiting algorithm trade-offs?
Option B is strongest: it defines all three primary algorithms mechanically (token refill, queue drain, weighted sliding average), explains when bursting is allowed (token bucket) vs forbidden (leaky bucket), identifies the fixed-window boundary attack that sliding window solves, describes the sliding window log variant for maximum accuracy, and covers distributed consistency requirements (Redis atomic Lua scripts) and the under-counting risk of local-only counters. Options A and C each state one correct trade-off but don't explain the algorithms mechanically, the boundary attack, or distributed state consistency.
2 / 15
The interviewer asks: "How does a circuit breaker pattern work at the API gateway layer — explain the state machine and what metrics determine state transitions?" Which answer best covers circuit breaker internals?
Option B covers the complete state machine with precise transition conditions (failure rate + minimum volume threshold + error type classification — 4xx excluded), latency-based failure counting, Kong and Envoy implementation specifics (outlier_detection config, ejection multiplier), three fallback strategies, and the cascade failure prevention rationale (retry storms, timeout budget). Options A and C describe the three states correctly but don't specify the metrics for state transitions, why 4xx is excluded, implementation in specific gateways, or fallback strategies.
3 / 15
The interviewer asks: "Compare URL path versioning, header-based versioning, and content negotiation for API versioning — what are the trade-offs and which would you recommend for a large platform?" Which answer best covers API versioning trade-offs?
Option B covers all five layers: URL versioning pros/cons with concrete examples (Stripe, Twilio, GitHub), header versioning with the CDN caching problem (Vary header, cache miss rate), content negotiation with the Accept media type format and its practical downsides, a concrete recommendation for external vs internal APIs with the Stripe date-versioning pattern, and the Sunset policy with RFC 8594 and the gateway injection pattern. Options A and C each identify the right trade-offs but don't cover CDN caching mechanics, the Vary header problem, the Sunset RFC, or gateway-level deprecation headers.
4 / 15
The interviewer asks: "How do you implement mTLS at the API gateway to enforce zero trust for service-to-service calls — what does the gateway verify and what are common implementation pitfalls?" Which answer best covers gateway mTLS implementation?
Option B covers all five dimensions: the mechanical difference mTLS adds over TLS (bidirectional verification), both upstream and downstream gateway configurations (terminate + re-originate vs passthrough), the four certificate validation checks (CA trust, expiry, revocation via OCSP, SPIFFE SAN), automatic rotation via cert-manager/SPIRE, five specific pitfalls (internal-IP trust anti-pattern, pinning without rotation, revocation omission, passthrough L7 blind spot, chain validation latency), and the authentication vs authorisation separation. Options A, C, D each describe the basic concept but don't cover upstream mTLS configuration, revocation checking, the passthrough pitfall, or the auth vs authz separation.
5 / 15
The interviewer asks: "Compare request transformation approaches in Kong (Lua plugins) and Envoy (HTTP filters, WASM) — what can each do, and what are the performance trade-offs?" Which answer best covers gateway extensibility?
Option B provides the complete picture: Kong lifecycle hooks by name (access, header_filter, body_filter, log), LuaJIT performance numbers (0.1-0.3ms), plugin architecture (base_plugin.lua interface), Envoy built-in filter names (ext_authz, grpc_json_transcoder, lua, header_to_metadata), proxy-wasm ABI hook names with supported languages (Rust, Go, C++), performance numbers for all four tiers (C++ 0.01ms, Lua 0.1-0.5ms, WASM 0.2-1ms, ext_authz 1-5ms), and a concrete decision framework. Options A, C, D each name the right technologies but provide no performance numbers, lifecycle hook names, or decision criteria.
6 / 15
Sarah from the Performance team just flagged a spike in latency for our user authentication API. She suspects it might be related to the gateway's caching implementation. Which of the following actions would you recommend investigating FIRST to pinpoint the root cause, focusing on quickly identifying potential issues within the gateway's configuration?
The initial response should focus on understanding the immediate impact of caching. Increasing the TTL allows the gateway to serve cached responses more frequently, which is a good starting point for investigating latency. Rate limiting and disabling caching are less targeted approaches that could mask underlying issues. Reviewing logs provides detailed metrics, but doesn't directly address the potential problem with the existing configuration.
7 / 15
David, a senior developer, has just submitted a PR to add a new authentication method using OAuth2. As part of your code review, he mentions using the API gateway's 'request transformation' feature to modify the incoming JWT claims before routing them to the backend service. Which of the following best describes the primary benefit of this approach in the context of API Gateway design?
Request transformation enables dynamic manipulation of requests at the gateway level. This is crucial for adapting to evolving API requirements and enforcing consistent request formats across different backend services – a key benefit for maintaining system integrity and reducing errors. While OAuth2 integration might occur *after* transformation, the core purpose here is about modifying the *request*, not delegating authentication.
8 / 15
Mark (Security Engineer) asks you: 'How can I ensure that our API gateway consistently enforces a specific security policy—say, requiring all requests to include a 'X-Correlation-ID' header—regardless of the backend service's implementation?' Which configuration option provides the most robust and centralized control for this scenario?
An Envoy HTTP filter offers the most direct and centralized control over request modification. This allows you to define a consistent enforcement mechanism at the gateway level without requiring changes in each individual backend service. While plugins could achieve this, filters are generally more performant and easier to manage for policy enforcement scenarios like this.
9 / 15
Emily (DevOps) is setting up a new API gateway deployment. She's considering using a 'dead letter queue' to handle failed requests that are routed through the gateway. What is the *primary* purpose of this configuration in relation to API Gateway operation?
A dead letter queue is designed primarily for capturing and analyzing failed request payloads. This allows you to investigate the root cause of failures—often by examining the data that triggered the failure—and then take appropriate action (e.g., retry, alert, or log). It's not about immediate blocking or indefinite retries; those are handled elsewhere.
10 / 15
John, a developer, is troubleshooting slow API responses. He notices that the gateway's logging mechanism is generating a high volume of log entries. What should John do *first* to address this issue and reduce the load on the gateway without impacting core functionality?
Disabling logging for non-critical requests is a pragmatic first step. Increasing the logging level (DEBUG) will *increase* log volume dramatically, exacerbating the problem. Centralized logging and Elasticsearch are good long-term solutions but require more setup and don't immediately address the immediate issue of excessive logs.
11 / 15
Sarah from the Performance team just flagged a spike in latency for our user authentication API. She suspects it might be related to the gateway's caching implementation. Which of the following actions would you recommend investigating FIRST to pinpoint the root cause, focusing on quickly identifying potential issues within the gateway's configuration?
The initial response should focus on understanding the immediate impact of caching. Increasing the TTL allows the gateway to serve cached responses more frequently, which is a good starting point for investigating latency. Rate limiting and disabling caching are less targeted approaches that could mask underlying issues. Reviewing logs provides detailed metrics, but doesn't directly address the potential problem with the existing configuration.
12 / 15
David, a senior developer, has just submitted a PR to add a new authentication method using OAuth2. As part of your code review, he mentions using the API gateway's 'request transformation' feature to modify the incoming JWT claims before routing them to the backend service. Which of the following best describes the primary benefit of this approach in the context of API Gateway design?
Request transformation enables dynamic manipulation of requests at the gateway level. This is crucial for adapting to evolving API requirements and enforcing consistent request formats across different backend services – a key benefit for maintaining system integrity and reducing errors. While OAuth2 integration might occur *after* transformation, the core purpose here is about modifying the *request*, not delegating authentication.
13 / 15
Mark (Security Engineer) asks you: 'How can I ensure that our API gateway consistently enforces a specific security policy—say, requiring all requests to include a 'X-Correlation-ID' header—regardless of the backend service's implementation?' Which configuration option provides the most robust and centralized control for this scenario?
An Envoy HTTP filter offers the most direct and centralized control over request modification. This allows you to define a consistent enforcement mechanism at the gateway level without requiring changes in each individual backend service. While plugins could achieve this, filters are generally more performant and easier to manage for policy enforcement scenarios like this.
14 / 15
Emily (DevOps) is setting up a new API gateway deployment. She's considering using a 'dead letter queue' to handle failed requests that are routed through the gateway. What is the *primary* purpose of this configuration in relation to API Gateway operation?
A dead letter queue is designed primarily for capturing and analyzing failed request payloads. This allows you to investigate the root cause of failures—often by examining the data that triggered the failure—and then take appropriate action (e.g., retry, alert, or log). It's not about immediate blocking or indefinite retries; those are handled elsewhere.
15 / 15
John, a developer, is troubleshooting slow API responses. He notices that the gateway's logging mechanism is generating a high volume of log entries. What should John do *first* to address this issue and reduce the load on the gateway without impacting core functionality?
Disabling logging for non-critical requests is a pragmatic first step. Increasing the logging level (DEBUG) will *increase* log volume dramatically, exacerbating the problem. Centralized logging and Elasticsearch are good long-term solutions but require more setup and don't immediately address the immediate issue of excessive logs.
What does "API Gateway Architect — Interview Questions — Best-Answer Practice" cover?
Practice answering API Gateway Architect interview questions in professional English. 5 exercises on rate limiting algorithms, circuit breaker patterns, API versioning strategies, mTLS zero trust, and request transformation.
How many questions are in this interview set?
This set has 15 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.