Amazon DVA-C02: Amazon API Gateway & App Integration — Study Guide
Part of the AWS Developer Associate DVA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Designing APIs with API Gateway (REST, HTTP, WebSocket) and integrations
Design starts with choosing the right API flavor: REST APIs (API Gateway REST) give fine-grained stage-level features such as per-stage caching and sophisticated mapping templates; HTTP APIs (API Gateway v2) provide lower latency and lower cost for common proxy patterns and native JWT/OIDC authorizers; WebSocket APIs provide persistent client-server channels with route keys ($connect, $disconnect, $default) and require the API Gateway Management API (PostToConnection) to send messages. Architect integrations by preferring AWS_PROXY/Lambda proxy for simple request/response (use aws apigateway put-integration –type AWS_PROXY or for v2 use CreateIntegration on ApiGatewayV2Client), and choose HTTP or VPC Link for private HTTP backends. For high-throughput backends use NLB + VPC Link. Mock integrations (put-integration –type MOCK) and integration response templates let frontend teams begin without backend readiness. When fronting APIs with CloudFront, use regional API endpoints as origins and set Origin Protocol Policy to HTTPS-only; edge-optimized REST APIs already sit behind CloudFront. Common traps include mismatched payload format versions between API and Lambda (v1.0 vs 2.0), forgetting to grant apigateway.amazonaws.com permission to invoke Lambda (add permission with aws lambda add-permission –principal apigateway.amazonaws.com), and CORS misconfigurations that block browsers.
Security and Authorization Patterns (Cognito, IAM, custom authorizers)
Security patterns should match client types and access models: use Amazon Cognito User Pools or an external OIDC provider and wire them as JWT authorizers for HTTP APIs (CreateAuthorizer in apigatewayv2 with identitySource set to $request.header.Authorization), or use REST API Cognito Authorizers for session-based user access. For service-to-service or admin APIs prefer IAM authorization (SigV4) and tightly-scoped IAM resource policies on stages and methods. Lambda (custom) authorizers offer maximum flexibility to implement bespoke auth rules, but remember they add latency and failure modes — cache authorizer responses with TTL to reduce cold starts and avoid throwing errors that return 500 to clients. Protect against abuse with usage plans and API keys (aws apigateway create-usage-plan and create-api-key) combined with throttling quotas. Ensure correct IAM permissions: grant API Gateway permission to invoke Lambda (aws lambda add-permission) and restrict Lambda execution roles to least privilege. Developer gotchas include forgetting to enable token extraction for JWT authorizers, authorizer timeouts impacting overall API latency, and forwarding of headers/cookies by CloudFront which can inadvertently bypass caches or leak user data.
Stage Management, Versioning, Caching, and Canary deployments
Treat stages as independent runtime surfaces: deployments are snapshots (aws apigateway create-deployment or apigatewayv2 create-deployment), and stages map to those snapshots. Use stage variables or, preferably, Lambda aliases to route traffic between versions; switch aliases atomically (UpdateAlias) or use API Gateway stage canary settings for gradual rollout. For REST APIs, enable caching at the stage (aws apigateway update-stage with patch-operations to set cacheClusterEnabled and cacheClusterSize) and control TTL and cache key parameters in method settings; HTTP APIs do not currently have built-in caching so use CloudFront or application-level caches. Evict cache on deploy or when underlying data changes; relying solely on TTL can return stale data. Versioning patterns: use semantic API versioning in path (/v1/…) or rely on staged deployments for blue/green flows. Common traps include assuming stage variables are secure (they are visible to devs with console access), misconfiguring cache keys (forgetting to include authorization header or query params), and not coordinating deployment of schema changes with client compatibility.
Performance, Observability, and Diagnostics
Instrument APIs end-to-end: enable execution logs and access logs on API Gateway and produce structured JSON ($context variables) to CloudWatch Logs; enable X-Ray on API Gateway and Lambda (set tracingEnabled in deployment/stage or use SDK: PutFunctionConcurrency/UpdateFunctionConfiguration with TracingConfig) to correlate traces. Monitor API Gateway metrics (Latency, IntegrationLatency, 4XX/5XX, CacheHitCount) and Lambda metrics (Duration, Throttles, ConcurrentExecutions) in CloudWatch; use metric math to identify where latency accumulates. For WebSocket, track connection count and API Gateway 5XX spikes. Troubleshooting steps include comparing IntegrationLatency to Latency to see if backend or gateway adds overhead, drilling into X-Ray segments for cold starts or VPC ENIs, and checking CloudWatch Logs for mapping template errors. Use DLQs and destinations for asynchronous Lambda failures, and set reserved concurrency or provisioned concurrency for critical functions. Developer pitfalls: logging sensitive PII to traces (redact at source or disable X-Ray sampling for those flows), missing provider certificates for custom domains (ACM regional vs us-east-1 for edge), and relying on default account throttling without usage plans for public APIs.
Practical Problem: Use-Case Scenario
Scenario: BrightCart runs a regional ecommerce frontend on a single-page application hosted in S3/CloudFront and exposes a checkout API via API Gateway (regional HTTP API) that invokes Lambda functions in a VPC and writes orders to DynamoDB. The environment uses a CI/CD pipeline that deploys Lambda versions to production aliases and exposes /checkout on a production stage.
Challenge: After a recent feature rollout, production API latency increased and some checkout requests return 502/504 intermittently; developers need a safe rollback mechanism and immediate diagnostics.
Recommended Approach:
- Create a deployment rollback by pointing the production API stage to the previous deployment: use aws apigatewayv2 create-deployment –api-id
<api>–description “rollback” then aws apigatewayv2 update-stage –api-id<api>–stage-name prod –deployment-id<old-deploy-id>. - Shift traffic safely using Lambda aliases: update the prod Lambda alias to the previous version with aws lambda update-alias –function-name CheckoutFn –name prod –function-version
<previous-version>and verify behavior. - Enable and collect diagnostics: enable X-Ray tracing for the API and Lambda (aws apigatewayv2 update-stage –tracing-enabled true and aws lambda update-function-configuration –function-name CheckoutFn –tracing-config Mode=Active) and turn on detailed access logs ($context.requestTime, $context.integrationErrorMessage) to CloudWatch Logs.
- Analyze metrics and traces: compare API Gateway IntegrationLatency vs Latency in CloudWatch, examine X-Ray segments to identify VPC ENI cold-starts, and check Lambda throttles or DynamoDB conditional writes; if VPC ENI latency is root cause, consider provisioned concurrency (aws lambda put-provisioned-concurrency-config) or moving to Lambda with VPC endpoint optimizations.
Rationale: Atomic stage redeploy and Lambda alias switches provide quick, low-risk rollback without code changes. Enabling X-Ray and structured access logs lets developers pinpoint whether the API Gateway, Lambda cold starts, VPC networking, or downstream DynamoDB calls are causing the errors, guiding the correct mitigation (provisioned concurrency, increased throughput, or configuration fixes).
← Serverless · All domains · Amazon DynamoDB →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →