AWS Developer common mistakes
AWS Developer · Understand the traps and how to avoid them.
Choosing a synchronous, in-request processing pattern (e.g., doing image resizing or PDF generation inline in the Lambda or API handler) when the scenario states the work takes minutes or must survive downstream failures.
Candidates pattern-match on 'serverless' and forget that API Gateway and Lambda have timeout ceilings and that inline work couples user latency to task duration; the question's phrasing about 'long-running' or 'must not be lost' is the tell.
What to do instead
When you see duration, retry, or durability language, route to an asynchronous decoupling service: SQS between producer and consumer, SNS for fan-out, Step Functions for multi-step orchestration, and return a 202/job ID to the caller. Reserve synchronous invocation for sub-second request/response work.
Treating DynamoDB like a relational database in access-pattern design: picking a partition key with low cardinality, then relying on Scan or on FilterExpression to satisfy queries.
Candidates from an RDBMS background default to 'query then filter' thinking and underestimate that FilterExpression is applied after read, so consumed capacity reflects items scanned, not items returned.
What to do instead
Enumerate access patterns first, then choose a high-cardinality partition key and a sort key that supports range queries; use GSIs/LSIs or composite keys for alternate patterns, and Query (never Scan) on hot paths. If the prompt mentions a status or date filter with slow performance, that is the signal.
Assuming environment variables or a config file are the right place for secrets, or baking credentials into a Lambda deployment package or AMI.
Environment variables are visible to anyone with lambda:GetFunctionConfiguration and appear in console/CI logs; candidates conflate 'not in source code' with 'secure'.
What to do instead
Store secrets in Secrets Manager (with rotation) or SSM Parameter Store SecureString, grant the execution role least-privilege GetSecretValue, and cache the value in the execution environment outside the handler. For cross-account or short-lived needs, use IAM roles and STS rather than static keys.
Granting a resource policy or execution role broader permissions than the scenario requires - e.g., s3:* on * for a function that only reads one prefix, or an overly permissive Lambda resource policy instead of a source-account/source-ARN condition.
Candidates optimize for 'it will definitely work' and pick the widest option, missing that these questions frequently test least privilege and cross-account constraints as the discriminating detail.
What to do instead
Scope actions to the specific operations named in the prompt and resources to specific ARNs/prefixes. For cross-service triggers, prefer resource-based policies with aws:SourceAccount and aws:SourceArn conditions over wildcards, and use IAM roles rather than long-lived access keys.
Confusing Cognito User Pools with Identity Pools, or trying to authorize API Gateway directly against a User Pool without the right authorizer configuration.
Both are 'Cognito' and both return tokens/credentials; candidates memorize names without mapping them to authentication (who you are, JWT issuance) versus authorization to AWS resources (temporary credentials).
What to do instead
User Pool = sign-up/sign-in and JWT issuance; attach a Cognito authorizer or JWT authorizer to API Gateway to validate tokens and pass claims downstream. Identity Pool = exchange of a token for temporary AWS credentials via STS for direct AWS service access. If the prompt says 'call DynamoDB directly from the mobile app', that is Identity Pools.
Deploying SAM/CDK/CloudFormation changes with console edits or manual CLI patches, causing drift, or forgetting that change sets and stack updates can fail and roll back.
The console is the fastest path in practice, so candidates answer with the behaviour they habitually use, and they forget that CloudFormation rolls back on failure, leaving the previous stack in place.
What to do instead
Express all infrastructure as code and deploy through a pipeline stage; use change sets for review, and for Lambda use versioned aliases with gradual deployment preferences (Canary/Linear) so rollback is automatic. If a question asks how to trace what changed, the answer is CloudFormation stack events/drift detection, not console history.
Ignoring deployment-package mechanics: bundling native dependencies without building on the Lambda runtime's compatible architecture/OS, exceeding the 250 MB unzipped limit, or not realizing layer and /tmp limits.
Code works locally, so candidates select 'zip and upload' without considering that Lambda runs on Amazon Linux and that native modules must be compiled for that environment.
What to do instead
Build inside a container matching the runtime (or use SAM/CDK build with the right architecture), push large artifacts to S3 for deployment, prefer container images up to 10 GB when the package is heavy, and place shared libraries in layers. Remember /tmp is 512 MB and is not shared between concurrent invocations.
Debugging Lambda or container failures by looking only at application logs instead of the invocation metrics, and misreading throttling as a code bug.
Concurrency errors (Throttles, 429s from downstream, ProvisionedConcurrency shortfalls) produce symptoms identical to timeouts in application logs; candidates jump to code changes without checking account/function concurrency limits.
What to do instead
Check CloudWatch metrics first: Throttles, ConcurrentExecutions, Duration p99, Errors, and IteratorAge for stream sources. Distinguish Reserved vs Provisioned Concurrency, raise limits or request increases appropriately, and set DLQs or destinations so failed async invocations are recoverable rather than silently dropped.
Applying the wrong caching layer - enabling ElastiCache/DAX for data that must be strongly consistent, or assuming API Gateway caching is per-user by default.
Caching looks like a universal latency fix; candidates miss that API Gateway stage caching keys on request parameters by default (not on Authorization headers), a classic cause of data leaking between users.
What to do instead
Select the cache by requirement: DAX for DynamoDB microsecond reads (eventually consistent), ElastiCache for session/derived data, CloudFront for public content. For API Gateway, explicitly configure cache key parameters including the auth token/header when responses are user-specific, or disable caching on those methods.
Relying on infinite or unmanaged retries - e.g., SQS standard queue redrive without a DLQ, Lambda async retries without a destination, or SDK default retries on non-idempotent writes.
Candidates fix transient failures by 'adding retries' and overlook that SQS is at-least-once and Lambda async invokes retry twice by default, so non-idempotent handlers create duplicates or poison-pill loops.
What to do instead
Make handlers idempotent (conditional writes with a dedupe key, idempotency tokens), configure maxReceiveCount with a DLQ and alarm on DLQ depth, use FIFO queues with deduplication IDs where ordering/duplication matters, and use exponential backoff with jitter for downstream throttling.