Rate limiting: algorithm choice matters — token bucket (burst friendly) vs sliding window (smooth) vs leaky bucket (strict)
Auth at gateway: validate tokens at the edge, not in every service — but do not move business logic to the gateway
Request transformation: header injection, path rewriting, body transformation — each has a performance cost
Gateway selection: Kong (plugin ecosystem, open source) vs Apigee (analytics, GCP-native) vs AWS API GW (Lambda integration)
0 / 15 completed
1 / 15
The interviewer asks: "Explain the differences between token bucket, leaky bucket, and sliding window rate limiting algorithms. When do you use each?" Which answer is most precise?
Option B is strongest. It explains the mechanics of each algorithm, names the traffic shaping characteristic (burst-friendly, strict constant output, precision fairness), gives a concrete use case for each, and names a specific failure mode of an alternative (fixed-window double-counting at the boundary). Option A claims the choice does not matter — wrong; the algorithm determines traffic shape. Option C moves rate limiting to the application layer — valid but defeats the purpose of centralised enforcement at the gateway. Option D delegates the algorithm choice to the vendor without understanding what you are choosing.
2 / 15
The interviewer asks: "How do you implement authentication at an API gateway without creating a tight coupling between the gateway and your identity provider?" Which answer shows the most resilient design?
Option C is strongest. It describes JWT with local JWKS verification (decouples individual request validation from IdP availability), explains key rotation handling (cache both keys during transition), addresses the revocation problem (lightweight introspection with cache), and quantifies the downtime tolerance (JWT lifetime). Option A creates a hard synchronous dependency on the IdP — single point of failure. Option B uses database-backed sessions — the database becomes the dependency; also slower per-request than JWT. Option D uses API keys — simple but lacks claims, expiry, or user identity; appropriate for M2M not user auth.
3 / 15
The interviewer asks: "Describe a complex request transformation you have implemented at the gateway layer. What were the trade-offs?" Which answer is most technically detailed?
Option B is the strongest. It describes a complex real-world transformation scenario (three backend types unified), names the four transformation types (protocol, header enrichment, schema normalisation, error translation), quantifies the latency cost (2-5ms, SOAP being most expensive), and names all three trade-offs (complexity, latency, coupling) with their mitigations (test harness, decision record). Option A describes path rewriting — a simple transformation, not a complex one. Option C avoids the question. Option D is the minimum viable transformation, not a complex case.
4 / 15
The interviewer asks: "How do you manage traffic between multiple backend versions during an API migration?" Which answer is most operationally complete?
Option B is strongest. It describes five traffic management techniques for a migration: header-based opt-in routing, weighted splitting with automatic rollback on error rate threshold, consumer-based routing for SLA customers, deprecation tracking per consumer, and graceful cutover with a 410 response. This is the complete migration playbook. Option A is big-bang cutover with manual rollback — high risk. Option C uses DNS-based separation — works but does not allow gradual migration or per-consumer routing. Option D uses query parameters for versioning — generally discouraged (parameters should not change resource identity); header versioning is preferred.
5 / 15
The interviewer asks: "Compare Kong and Apigee for enterprise API gateway selection. When would you choose each?" Which answer demonstrates the most balanced judgement?
Option C is the strongest. It characterises each gateway along consistent dimensions (architecture, deployment model, cost, ideal team profile), names specific differentiating capabilities (Kong: plugins, multi-cloud; Apigee: analytics, monetisation, developer portal), provides three concrete decision criteria with conditions, and names anti-patterns for each (Apigee for internal-only APIs, self-managed Kong without a platform team). Option A uses only open source vs proprietary as the axis — oversimplified. Option B expresses a preference without criteria. Option D avoids making a recommendation — unhelpful in an interview.
6 / 15
Sarah (Senior DevOps Engineer) posted this to the #api-gateway Slack channel: 'We're seeing a huge spike in requests to our user profile API. Latency is up significantly. Any ideas?'
Which of the following actions would be MOST appropriate for an API Gateway Engineer to suggest, focusing on immediate mitigation?
The core issue is high latency. Rate limiting by IP is a blunt instrument and doesn't address the underlying problem; deploying a canary or automatic rollback are complex deployments with potential for further disruption. Sarah's message indicates urgency – immediate mitigation should focus on reducing load, making a temporary rate limit (option 1) the most sensible first step while investigation continues.
7 / 15
During a code review of a PR that implements JWT validation at an API gateway, your colleague, David (a junior developer), comments: 'I'm not sure if this is the best way to handle expired tokens. Shouldn't we just throw an HTTP 401 Unauthorized response?'
Which answer BEST addresses David's concern and demonstrates a thorough understanding of API gateway security?
David's comment highlights an important aspect of JWT handling – graceful error responses. While a 401 is standard, proactively implementing a refresh endpoint (option 3) provides a more robust solution and avoids forcing clients to re-authenticate frequently. Simply logging events (option 1) is helpful but doesn't address the core issue of how expired tokens are handled.
8 / 15
You're designing an API gateway to route requests to multiple microservices. One service, 'OrderService', is experiencing high latency during peak hours. You suspect this is due to inefficient database queries. Which monitoring metric would be MOST valuable for you to track in real-time from the API Gateway to understand the impact of OrderService's performance?
Response time is the most direct measure of OrderService's performance as experienced by clients. While other metrics (CPU usage, bandwidth) can provide context, they don't directly reflect the user experience or identify the root cause of latency within the service itself – a slow response time indicates a problem.
9 / 15
In your PR description for a new API gateway feature—a dynamic routing rule based on HTTP headers—you write: 'This feature allows us to intelligently route requests to different backend services based on the 'user-agent' header. This provides flexibility and avoids hardcoding service dependencies.'
Which of the following statements BEST captures the potential security implications of this approach?
While dynamic routing based on headers offers flexibility, it also introduces security vulnerabilities if the 'user-agent' header isn't properly validated. A malicious actor could potentially spoof this header to redirect traffic to unintended services – a critical oversight that needs mitigation.
10 / 15
A senior engineer, Maria, asks you: 'We're planning a phased rollout of our new payment API. We need to route 20% of traffic to the v1 version initially, 50% to v2, and the remaining 30% to v3. How should we configure the API Gateway to achieve this staged deployment?'
Which answer presents the MOST complete and robust solution?
Weighted routing (option 2) provides the necessary granularity and flexibility for staged rollouts. It allows you to dynamically adjust traffic percentages based on performance or user feedback – this is crucial for a phased deployment. A simple header-based approach (option 1) lacks precision, while separate Gateways (option 3) add unnecessary complexity.
11 / 15
Sarah (Senior DevOps Engineer) posted this to the #api-gateway Slack channel: 'We're seeing a huge spike in requests to our user profile API. Latency is up significantly. Any ideas?'
Which of the following actions would be MOST appropriate for an API Gateway Engineer to suggest, focusing on immediate mitigation?
The core issue is high latency. Rate limiting by IP is a blunt instrument and doesn't address the underlying problem; deploying a canary or automatic rollback are complex deployments with potential for further disruption. Sarah's message indicates urgency – immediate mitigation should focus on reducing load, making a temporary rate limit (option 1) the most sensible first step while investigation continues.
12 / 15
During a code review of a PR that implements JWT validation at an API gateway, your colleague, David (a junior developer), comments: 'I'm not sure if this is the best way to handle expired tokens. Shouldn't we just throw an HTTP 401 Unauthorized response?'
Which answer BEST addresses David's concern and demonstrates a thorough understanding of API gateway security?
David's comment highlights an important aspect of JWT handling – graceful error responses. While a 401 is standard, proactively implementing a refresh endpoint (option 3) provides a more robust solution and avoids forcing clients to re-authenticate frequently. Simply logging events (option 1) is helpful but doesn't address the core issue of how expired tokens are handled.
13 / 15
You're designing an API gateway to route requests to multiple microservices. One service, 'OrderService', is experiencing high latency during peak hours. You suspect this is due to inefficient database queries. Which monitoring metric would be MOST valuable for you to track in real-time from the API Gateway to understand the impact of OrderService's performance?
Response time is the most direct measure of OrderService's performance as experienced by clients. While other metrics (CPU usage, bandwidth) can provide context, they don't directly reflect the user experience or identify the root cause of latency within the service itself – a slow response time indicates a problem.
14 / 15
In your PR description for a new API gateway feature—a dynamic routing rule based on HTTP headers—you write: 'This feature allows us to intelligently route requests to different backend services based on the 'user-agent' header. This provides flexibility and avoids hardcoding service dependencies.'
Which of the following statements BEST captures the potential security implications of this approach?
While dynamic routing based on headers offers flexibility, it also introduces security vulnerabilities if the 'user-agent' header isn't properly validated. A malicious actor could potentially spoof this header to redirect traffic to unintended services – a critical oversight that needs mitigation.
15 / 15
A senior engineer, Maria, asks you: 'We're planning a phased rollout of our new payment API. We need to route 20% of traffic to the v1 version initially, 50% to v2, and the remaining 30% to v3. How should we configure the API Gateway to achieve this staged deployment?'
Which answer presents the MOST complete and robust solution?
Weighted routing (option 2) provides the necessary granularity and flexibility for staged rollouts. It allows you to dynamically adjust traffic percentages based on performance or user feedback – this is crucial for a phased deployment. A simple header-based approach (option 1) lacks precision, while separate Gateways (option 3) add unnecessary complexity.
What does "API Gateway Engineer Interview Questions — Best-Answer Practice" cover?
Practice answering API Gateway Engineer interview questions in professional English. 5 exercises on rate limiting, authentication, request transformation, traffic management, and Kong/Apigee.
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.