API / APIGEE Gateway Interview Questions
What are common Apigee anti-patterns and best practices for production deployments?
Knowing what NOT to do is as important as knowing the policies. These anti-patterns are commonly asked about in senior Apigee interviews and architecture reviews.
| Anti-pattern | Problem | Best practice |
|---|---|---|
| Hardcoding backend URLs in proxy XML | URL breaks when environment changes; requires proxy redeployment to update | Use Target Servers (environment-scoped) for all backend URLs |
| No DefaultFaultRule | Apigee returns raw technical error messages to clients | Always define a DefaultFaultRule with a friendly JSON error response |
| Security policies in PostFlow | Auth bypass possible if a ConditionalFlow error occurs | Security policies (VerifyAPIKey, OAuthV2) must be in ProxyEndpoint PreFlow |
| Copying policies across proxies | Change in one proxy not reflected in others; drift | Extract common logic into Shared Flows and call via FlowCallout |
| Using target.url to hardcode in AssignMessage | Same as hardcoded URL issue | Use Target Servers or KVMs |
| No SpikeArrest before Quota | Sudden bursts still reach backend before Quota catches them | Always pair SpikeArrest (first) + Quota (second) for traffic management |
| Using Trace in production without restrictions | Sensitive data captured; performance impact | Restrict trace access via IAM; set short TTL on trace sessions |
| Deploying untested proxy to prod | Bugs in production | Enforce CI/CD: apigeelint + integration tests before prod promotion |
<!-- Best practice: complete PreFlow with both SpikeArrest and Quota --> <ProxyEndpoint name="default"> <PreFlow name="PreFlow"> <Request> <!-- 1. Protect from spikes first --> <Step><Name>SpikeArrest</Name></Step> <!-- 2. Validate the API key --> <Step><Name>VerifyAPIKey</Name></Step> <!-- 3. Enforce business quota (after key validation so the quota counter knows which developer) --> <Step><Name>Quota</Name></Step> </Request> <Response/> </PreFlow> <!-- 4. Always have a DefaultFaultRule --> <DefaultFaultRule name="DefaultFaultRule"> <Step><Name>AM.GenericErrorResponse</Name></Step> <AlwaysEnforce>true</AlwaysEnforce> </DefaultFaultRule> </ProxyEndpoint>
Why must the VerifyAPIKey policy be placed in the ProxyEndpoint PreFlow rather than a ConditionalFlow?
What is the correct order of traffic management policies in an Apigee PreFlow for a well-designed API proxy?
More Related questions...
