AWS Developer – Associate (DVA-C02) — Free Sample Questions
Practice with 30 free Developer Associate sample questions covering Lambda, DynamoDB, API Gateway, SQS, and CI/CD pipelines. Each includes an explanation of why the correct answer is right and why each wrong answer fails.
Exam Domains
- Development with AWS Services (32%) — Lambda handlers, DynamoDB access patterns, S3 event triggers, SDK retries
- Security (26%) — Cognito user/identity pools, IAM roles for Lambda, Secrets Manager, KMS envelope encryption
- Deployment (24%) — CodePipeline, CodeBuild buildspec, SAM templates, blue/green with CodeDeploy
- Troubleshooting and Optimization (18%) — X-Ray tracing, CloudWatch Logs Insights, Lambda cold starts, DynamoDB throttling
Key Concepts the Exam Tests
DVA-C02 focuses on the developer's perspective: writing code that interacts with AWS services correctly. You'll see questions about:
- Correct DynamoDB key design for specific query patterns
- When to use SQS standard vs. FIFO queues
- Lambda concurrency settings and error handling
- API Gateway integration types (proxy vs. custom)
- Environment variable encryption and parameter hierarchies
Study Strategy
- Build small projects using Lambda + API Gateway + DynamoDB — hands-on solidifies concepts
- Understand the difference between execution role and resource-based policies
- Practice interpreting CloudWatch metrics and X-Ray traces
- Know CI/CD: SAM, CloudFormation, CodePipeline stages
Continue Practicing
Access the full 600-question DVA-C02 bank — 30 quizzes and 2 full-length exams with domain-mapped explanations.
All 30 Free Sample Questions
Question 1
A development team is migrating from a monolithic application to microservices. Which TWO characteristics indicate a well-designed microservices architecture?
- All services must be written in the same programming language
- Each service can be deployed independently — Correct answer
- Services communicate through asynchronous messaging — Correct answer
- Services share a single database for data consistency
- Services share in-memory state for performance
Explanation:
- Why correct: Independent deployment (B) is a core microservices principle — each service has its own deployment lifecycle, allowing teams to release changes without coordinating with other teams. Asynchronous messaging (C) promotes loose coupling by allowing services to communicate without requiring both to be available simultaneously.
- Why A is wrong: Microservices support polyglot architecture, meaning each service can use the language best suited to its purpose. Requiring the same language removes this flexibility.
- Why B is correct: This is correct.
- Why C is correct: This is correct.
- Why D is wrong: Sharing a single database creates tight coupling between services because schema changes in one service can break others. Each microservice should own its data store (database-per-service pattern).
- Why E is wrong: Sharing in-memory state creates tight coupling, requires co-location on the same host, and doesn't work in distributed systems where services run on different instances.
Question 2
A developer needs to call the S3 GetObject API from a Lambda function. The function should handle throttling errors gracefully. What AWS SDK feature provides automatic retry logic?
- Custom exponential backoff implementation
- AWS SDK automatic retry with exponential backoff — Correct answer
- No retry mechanism available
- Manual retry loop implementation
Explanation:
- Why correct: The AWS SDK (for all supported languages) includes built-in automatic retry with exponential backoff. When a Lambda function receives a throttling error (HTTP 429 or 5xx) from S3, the SDK automatically retries the request with progressively longer wait times. Developers can customize the maximum number of retries and backoff strategy via SDK client configuration, but the default behavior handles most throttling scenarios without any custom code.
- Why A is wrong: Writing a custom exponential backoff implementation is unnecessary because the AWS SDK already provides this capability built-in. Custom implementations also risk introducing bugs in delay calculation or missing edge cases the SDK already handles.
- Why C is wrong: The AWS SDK does include automatic retry mechanisms — this statement is factually incorrect.
- Why D is wrong: A manual retry loop duplicates functionality the SDK already provides and is more error-prone. The SDK's built-in retry logic is well-tested and follows AWS best practices for backoff and jitter.
Question 3
A developer is building a banking application that uses DynamoDB. After a funds transfer is completed, the updated balance must be immediately visible to all subsequent read operations. Which read configuration should the developer use?
- Eventually consistent reads with a 5-second delay before reading
- Strongly consistent reads — Correct answer
- Eventually consistent reads with DynamoDB Accelerator (DAX)
- Transactional reads on an unrelated table
Explanation:
- Why correct: Strongly consistent reads in DynamoDB return the most up-to-date data, reflecting all successful write operations that occurred before the read. For a banking application where balance accuracy is critical after a transfer, strongly consistent reads guarantee the updated balance is returned immediately.
- Why A is wrong: Eventually consistent reads may return stale data regardless of any artificial delay. There is no guarantee that waiting 5 seconds will produce a consistent result, as DynamoDB's replication timing is not fixed.
- Why C is wrong: DAX is a caching layer that serves eventually consistent reads by default. Cached data may be stale, which is unacceptable for displaying a balance that was just updated by a transfer.
- Why D is wrong: Transactional reads (TransactGetItems) provide read isolation across multiple items, but reading from an unrelated table does not help retrieve the updated balance. The issue is consistency mode, not transaction scope.
Question 4
A Lambda function is invoked asynchronously by S3 event notifications. Occasionally the function fails, and the team has no visibility into which events were lost. Which TWO configurations help handle and capture failures for asynchronous invocations? (Select TWO.)
- Configure DLQ for failed invocations — Correct answer
- Remove timeout configuration
- Change function name
- Configure destinations for success and failure events — Correct answer
- Increase memory allocation
Explanation:
- Why A (DLQ) is correct: A Dead Letter Queue captures the event payload after all retry attempts are exhausted for asynchronous invocations. This ensures failed events are preserved for investigation or reprocessing rather than being silently lost.
- Why D (Destinations) is correct: Lambda Destinations allow you to route the invocation record to different targets (SQS, SNS, Lambda, EventBridge) based on whether the invocation succeeded or failed. Unlike DLQ, destinations work for both success and failure outcomes and include richer metadata such as request/response payloads.
- Why B (Remove timeout) is wrong: Removing the timeout is not possible (Lambda requires a timeout), and adjusting the timeout does not address failure handling. It only controls how long the function is allowed to run.
- Why C (Change function name) is wrong: The function name is an identifier and has no effect on failure handling, retry behavior, or invocation outcomes.
- Why E (Increase memory) is wrong: Increasing memory provides more CPU and can improve performance, but it does not provide a mechanism to capture or route failed invocation events.
Question 5
A developer is building a mobile application where users authenticate through a third-party identity provider (Google). After authentication, users need to upload files directly to a specific S3 bucket. How should the developer grant authenticated users temporary AWS credentials to access S3?
- Create IAM users for each mobile user and distribute access keys
- Use Amazon Cognito identity pools to exchange the IdP token for temporary AWS credentials — Correct answer
- Embed AWS root account credentials in the mobile application
- Use a single shared IAM role with permanent credentials stored in the app
Explanation:
- Why correct: Amazon Cognito identity pools (federated identities) allow you to exchange a token from a third-party identity provider (such as Google) for temporary, limited-privilege AWS credentials via AWS STS. These temporary credentials can be scoped to allow only the required S3 operations, following the principle of least privilege.
- Why A is wrong: Creating individual IAM users for each mobile user does not scale, is an operational burden, and distributing long-term access keys to mobile devices is a security risk.
- Why C is wrong: Embedding root account credentials in any application is an extreme security violation. Root credentials should never be shared or embedded.
- Why D is wrong: Using a single shared IAM role with permanent credentials violates security best practices. Permanent credentials stored in the app can be extracted and misused. Temporary credentials from Cognito identity pools are scoped, time-limited, and tied to individual authenticated sessions.
Question 6
A healthcare company must ensure that sensitive patient records stored in Amazon S3 cannot be read by anyone — including AWS — if the storage layer is compromised. The development team must manage the encryption keys themselves. Which approach meets this requirement?
- Use SSE-S3 (server-side encryption with S3-managed keys)
- Use SSE-KMS (server-side encryption with KMS keys)
- Use client-side encryption with application-managed keys — Correct answer
- Enable default bucket encryption on S3
Explanation:
- Why correct: With client-side encryption, the application encrypts data before sending it to S3, and only the application holds the keys. AWS never sees the plaintext data or the encryption keys. This provides the strongest guarantee that even AWS operators or a compromise of the S3 service cannot read the data.
- Why A is wrong: SSE-S3 uses keys managed entirely by AWS. While data is encrypted at rest, AWS controls the key lifecycle and performs the encryption/decryption. A sufficiently privileged AWS-side actor could technically access the plaintext, which does not meet the 'AWS cannot access plaintext' requirement.
- Why B is wrong: SSE-KMS uses AWS KMS to manage the encryption key. Although the customer can control key policies, the encryption and decryption still happen server-side within AWS. AWS services process the plaintext during the upload and download, so AWS infrastructure does handle unencrypted data.
- Why D is wrong: S3 default bucket encryption simply sets a default SSE mode (SSE-S3 or SSE-KMS) for new objects. It is a server-side mechanism and does not prevent AWS from accessing plaintext during processing.
Question 7
A developer has an AWS Lambda function that calls a third-party payment API. The API key must be kept confidential and should not be visible in plaintext in the Lambda console. Which approach BEST secures the API key?
- Store the API key in a plaintext environment variable and restrict IAM console access
- Embed the API key directly in the Lambda deployment package
- Enable encryption helpers in the Lambda console to encrypt the environment variable with an AWS KMS key, and decrypt it in the function code at runtime — Correct answer
- Store the API key in an Amazon DynamoDB table with no encryption
Explanation:
- Why correct: Lambda encryption helpers allow you to encrypt environment variables using a customer-managed AWS KMS key. The encrypted value is stored as ciphertext in the function configuration. At runtime, the function code calls the KMS Decrypt API to retrieve the plaintext value. This ensures the secret is encrypted at rest in the Lambda configuration and is only decrypted in memory during execution.
- Why A is wrong: Plaintext environment variables are encrypted at rest by Lambda's default service key, but they are visible in plaintext in the Lambda console and via the GetFunctionConfiguration API to anyone with sufficient IAM permissions. Restricting console access helps but does not encrypt the value itself in the configuration — the value is still returned in plaintext through the API.
- Why B is wrong: Embedding the API key in the deployment package means it exists in the source code or configuration files, making it visible in version control, build artifacts, and the deployed .zip. This is a critical security anti-pattern.
- Why D is wrong: Storing secrets in DynamoDB without encryption exposes them in plaintext to anyone with read access to the table. It also adds unnecessary latency and complexity without providing any security benefit over Secrets Manager or encrypted environment variables.
Question 8 — Security
A developer is building a REST API using Amazon API Gateway. The API must authenticate requests using JWT tokens issued by an external OpenID Connect (OIDC) identity provider. Which API Gateway feature should the developer configure to validate these bearer tokens with the LEAST custom code?
- An AWS Lambda authorizer that parses and validates the JWT token manually
- An API Gateway JWT authorizer configured with the issuer URL and audience — Correct answer
- IAM authorization with SigV4 signed requests from the client
- An API key requirement on each API method
Explanation:
- Why correct: API Gateway HTTP APIs support native JWT authorizers that validate bearer tokens against the specified issuer and audience without any custom code. API Gateway verifies the token signature, expiration, and claims automatically.
- Why A is wrong: A Lambda authorizer can validate JWT tokens but requires writing custom code to decode, verify signatures, and check claims — significantly more operational overhead than the built-in JWT authorizer.
- Why C is wrong: IAM authorization with SigV4 is used for AWS service-to-service authentication, not for validating JWT tokens from an external OIDC provider. Clients would need AWS credentials rather than JWT tokens.
- Why D is wrong: API keys are used for usage plans and throttling, not for authentication or authorization. API keys do not validate identity claims or enforce access control.
Question 9
A developer is containerizing a Python Lambda function that requires several large machine learning libraries. The final container image is 3 GB, causing slow deployments and high storage costs in Amazon ECR. Which approach will MOST effectively reduce the image size while keeping the function operational?
- Use a single-stage Dockerfile with a full OS base image and remove unused files with RUN rm commands after installation
- Use a multi-stage Docker build that installs dependencies in a build stage and copies only the required artifacts to a slim runtime stage — Correct answer
- Compress the entire container image using gzip before pushing to ECR
- Split the libraries across multiple smaller Lambda functions and invoke them in sequence
Explanation:
- Why correct (B): Multi-stage Docker builds let you use a full build environment (with compilers, headers, etc.) in the first stage to install dependencies, then copy only the compiled artifacts and runtime files into a minimal final image. This dramatically reduces image size because build-time tools are discarded. Lambda container images support multi-stage builds and this is the recommended approach for large dependency sets.
- Why A is wrong: Even with RUN rm commands, each Docker layer retains the files from previous layers due to how the union filesystem works. The deleted files still exist in earlier layers, so the overall image size is not reduced. Multi-stage builds avoid this by only copying what is needed into the final stage.
- Why C is wrong: You cannot compress a container image with gzip before pushing to ECR. Container registries handle image layers natively; the image must be pushed in OCI/Docker format. ECR already compresses layers during storage.
- Why D is wrong: Splitting libraries across functions adds orchestration complexity, increases latency from chained invocations, and does not address the root cause of a bloated image. Each function would still need its subset of large dependencies.
Question 10
A development team uses Amazon API Gateway to expose a REST API. They need separate configurations for development, staging, and production, each with different Lambda function endpoints and throttling settings. What is the BEST approach?
- Create three separate API Gateway APIs, one per environment
- Use a single stage and add conditional logic in the Lambda function to determine the environment
- Create stages (dev, staging, prod) in the same API and use stage variables to point to different Lambda aliases — Correct answer
- Use Amazon CloudFront distributions to route traffic to different environments
Explanation:
- Why correct: API Gateway stages (e.g., dev, staging, prod) allow developers to deploy the same API to different environments. Stage variables can reference different Lambda function aliases or ARNs per stage, and each stage can have its own throttling settings, logging configuration, and caching behavior. This is the native AWS mechanism for managing multiple environments in API Gateway.
- Why A is wrong: Creating entirely separate APIs duplicates configuration, increases maintenance overhead, and does not leverage API Gateway's built-in stage management features.
- Why B is wrong: A single stage with conditional logic in Lambda adds unnecessary complexity to the application code and doesn't provide environment-level configuration isolation (throttling, logging, caching differ per environment).
- Why D is wrong: CloudFront distributions route traffic but do not manage API Gateway-specific configurations like throttling, stage variables, or per-environment Lambda integrations.
Question 11
A developer is deploying a serverless application using AWS SAM. The SAM template defines an AWS::Serverless::Function and an AWS::Serverless::Api. Which TWO statements about SAM template deployment are correct?
- SAM templates require the `Transform: AWS::Serverless-2016-10-31` declaration to be processed by CloudFormation — Correct answer
- `sam deploy --guided` provides interactive prompts for stack name, region, and parameter overrides during the first deployment — Correct answer
- SAM templates cannot include standard CloudFormation resources such as AWS::DynamoDB::Table
- The `sam package` command creates the CloudFormation stack directly without needing `sam deploy`
- SAM templates are only compatible with Python and Node.js Lambda runtimes
- `sam deploy` automatically runs `sam build`, so explicitly running `sam build` is never required
Explanation:
- Why correct (A): SAM templates require the `Transform: AWS::Serverless-2016-10-31` declaration. Without it, CloudFormation does not recognize SAM resource types like `AWS::Serverless::Function`.
- Why correct (B): `sam deploy --guided` walks the developer through configuration options (stack name, region, S3 bucket, IAM capabilities) and saves choices to `samconfig.toml` for subsequent deployments.
- Why C is wrong: SAM templates fully support standard CloudFormation resources (e.g., `AWS::DynamoDB::Table`, `AWS::SQS::Queue`) alongside serverless resources.
- Why D is wrong: `sam package` only uploads artifacts (Lambda code, layers) to S3 and outputs a packaged template — it does not create or update CloudFormation stacks.
- Why E is wrong: SAM supports all Lambda runtimes including Python, Node.js, Java, .NET, Go, Ruby, and custom runtimes.
- Why F is wrong: `sam deploy` does not automatically run `sam build`. The developer must explicitly run `sam build` to resolve dependencies before deploying.
Question 12
A developer manages an API Gateway REST API that needs to serve three environments: dev, staging, and production. Each environment points to a different Lambda function alias. The developer wants to minimize duplication and manage all environments from a single API. What is the BEST approach?
- Create a new API Gateway API for each environment and hardcode the endpoint URLs in the application
- Use API Gateway stages (dev, staging, prod) with stage variables to point each stage to the correct Lambda alias or backend endpoint — Correct answer
- Deploy all environments to a single stage and use request headers to route traffic
- Create separate AWS accounts for each environment and duplicate the API configuration manually
Explanation:
- Why correct (B): API Gateway stages allow you to deploy the same API definition to multiple stages (e.g., dev, staging, prod). Stage variables act as environment-specific configuration — for example, a stage variable 'lambdaAlias' can be set to 'DEV' in the dev stage and 'PROD' in the prod stage. The integration URI references the stage variable (e.g., ${stageVariables.lambdaAlias}), so a single API definition serves all environments without duplication.
- Why A is wrong: Creating separate APIs for each environment causes configuration drift and increases maintenance overhead. Stages are specifically designed to avoid this.
- Why C is wrong: Routing based on request headers within a single stage conflates environment isolation with request-level logic. It doesn't provide separate deployment URLs or independent deployment lifecycles.
- Why D is wrong: While separate accounts can be used for environment isolation, manually duplicating API configuration is error-prone and doesn't leverage API Gateway's built-in stage management.
Question 13
A development team deploys a microservice to multiple environments (dev, staging, production). They need to change feature flags and logging levels per environment without redeploying the application. Which TWO capabilities of AWS AppConfig help achieve this?
- AppConfig requires a full application redeployment for any configuration change
- AppConfig supports deployment strategies with gradual rollout and automatic rollback on errors — Correct answer
- AppConfig can only store configuration in JSON format
- AppConfig integrates with Lambda extensions to retrieve configuration without modifying function code — Correct answer
- AppConfig replaces the need for environment variables in all AWS compute services
Explanation:
- Why correct: AppConfig supports deployment strategies (linear, exponential) with built-in rollback using CloudWatch alarms, ensuring safe configuration changes (B). The AppConfig Lambda extension runs as a sidecar process that caches and retrieves configuration, requiring no code changes to the function itself (D).
- Why A is wrong: AppConfig is specifically designed to deploy configuration changes independently of code deployments. Configuration updates are applied to running applications without redeployment.
- Why C is wrong: AppConfig supports multiple formats including JSON, YAML, and feature flags. It also supports freeform configurations and has a built-in feature flag data type.
- Why E is wrong: AppConfig complements environment variables but does not replace them. Environment variables remain useful for static, environment-specific settings. AppConfig is best for dynamic configuration that changes independently of deployments.
Question 14
A developer deploys a new version of a containerized application on Amazon ECS. The deployment completes, but the service's running task count drops to zero shortly after. The developer needs to determine why the new tasks keep failing. Which action should the developer take to troubleshoot?
- Check the ECS service's Events tab and inspect the stopped task's reason and exit code in the ECS console — Correct answer
- Redeploy the previous version of the container image without investigating
- Increase the ECS task CPU and memory limits to the maximum values
- Delete the ECS service and recreate it with the same task definition
Explanation:
- Why correct: The ECS service Events tab shows deployment events, placement failures, and health check results. Inspecting a stopped task reveals the stop reason (e.g., 'Essential container exited', 'CannotPullContainerError', health check failure) and the container exit code, which directly identifies the root cause. This is the standard first step in troubleshooting ECS deployment failures.
- Why B is wrong: Rolling back without investigating avoids root cause analysis. The same issue may recur, and you will not understand why the new version failed.
- Why C is wrong: Increasing CPU and memory is only appropriate if the stop reason indicates an OutOfMemory error or resource constraint. Without checking the actual error, this is a guess that may not address the real problem.
- Why D is wrong: Deleting and recreating the service does not fix the underlying issue (e.g., bad container image, failing health check, missing environment variable). The new service would fail in the same way.
Question 15
A developer is setting up observability for a new microservices application running on AWS. The team needs to implement the three pillars of observability. Which THREE AWS services map directly to the three observability pillars (logs, metrics, traces)?
- Amazon CloudWatch Logs — Correct answer
- Amazon CloudWatch Metrics — Correct answer
- AWS X-Ray — Correct answer
- AWS CodePipeline
- Amazon S3
Explanation:
- Why correct: The three pillars of observability are logs (detailed event records), metrics (numeric measurements over time), and traces (request flow across services). Together they give full visibility into distributed systems. CloudWatch Logs handles logs, CloudWatch Metrics handles metrics, and AWS X-Ray handles distributed tracing.
- Why A is correct: CloudWatch Logs provides logging (records of events), which is one of the three observability pillars—this is a correct choice.
- Why B is correct: This is correct. CloudWatch Metrics collects and tracks numeric measurements (CPU, latency, error rates, custom business metrics) over time—the metrics pillar.
- Why C is correct: This is correct. AWS X-Ray provides distributed tracing, showing how requests flow through microservices—the traces pillar.
- Why D is wrong: AWS CodePipeline is a CI/CD service for automating build, test, and deploy stages. It does not collect telemetry data and is not one of the three observability pillars.
- Why E is wrong: Amazon S3 is object storage. While logs can be archived to S3, S3 itself is not an observability pillar—it does not provide real-time log analysis, metrics, or tracing.
Question 16
A developer is troubleshooting a serverless application where an API Gateway endpoint backed by a Lambda function intermittently takes over 10 seconds to respond. The Lambda function calls a DynamoDB table and an external third-party API. The developer needs to identify which downstream call is causing the latency. What is the MOST effective approach?
- Enable VPC Flow Logs and analyze network traffic patterns
- Add print statements throughout the code and review CloudWatch Logs manually
- Enable AWS X-Ray tracing and use the X-Ray service map to identify high-latency segments — Correct answer
- Increase the Lambda function timeout to accommodate the slow responses
Explanation:
- Why correct: AWS X-Ray provides distributed tracing that breaks down the total request time into individual segments and subsegments. The X-Ray service map visually shows latency between each component (API Gateway → Lambda → DynamoDB, Lambda → external API), making it straightforward to pinpoint which downstream call is slow.
- Why A is wrong: VPC Flow Logs capture network-level metadata (source/destination IPs, ports, accept/reject) but do not capture application-level latency or show which specific API call within Lambda is slow.
- Why B is wrong: Adding print statements and manually reviewing CloudWatch Logs can show timing information if the developer adds timestamps, but this is a manual, time-consuming approach. X-Ray provides this breakdown automatically with visualization and requires no code changes beyond enabling the SDK.
- Why D is wrong: Increasing the timeout does not identify the root cause of the latency — it merely prevents the function from timing out. The bottleneck would remain undiagnosed.
Question 17
A developer needs to query CloudWatch Logs to find all Lambda cold starts that took longer than 5 seconds in the past 24 hours. The logs use the standard Lambda platform log format. Which approach should the developer use?
- Use CloudWatch Metrics filter to create a metric for cold starts, then set a threshold alarm at 5 seconds
- Export all logs to S3 and use Athena to query for cold starts
- Use CloudWatch Logs Insights with a query that filters on REPORT lines where Init Duration exceeds 5000 ms — Correct answer
- Enable X-Ray tracing and filter traces by initialization segment duration
Explanation:
- Why correct: CloudWatch Logs Insights allows direct querying of log data using its query language. Lambda REPORT lines include 'Init Duration' for cold starts. A Logs Insights query like `filter @type = "REPORT" and ispresent(@initDuration) and @initDuration > 5000` directly answers the question with no additional setup required.
- Why A is wrong: A CloudWatch Metrics filter can count cold starts or track init duration as a custom metric, but it requires creating the filter first, only captures data going forward, and does not allow querying historical log data from the past 24 hours that already exists.
- Why B is wrong: Exporting logs to S3 and querying with Athena is a valid approach for large-scale log analysis, but it is overly complex for this use case. Log exports are not real-time (they can take hours), and Logs Insights provides the same capability directly.
- Why D is wrong: X-Ray tracing can show initialization segments, but it must be enabled beforehand, adds cost, and samples traces rather than capturing every invocation. Logs Insights queries the complete log data that already exists.
Question 18 — Security
A company is building a mobile application that allows users to sign up with an email and password, then access an API Gateway REST API backed by Lambda. The developer needs to implement user registration, sign-in, and secure API authorization with minimal custom code. Which approach should the developer use?
- Create an IAM user for each application user and distribute access keys with the mobile app
- Build a custom authentication service on EC2 that issues signed JWTs and configure API Gateway to validate them with a Lambda authorizer
- Create an Amazon Cognito user pool for sign-up and sign-in, then use a Cognito user pool authorizer on the API Gateway — Correct answer
- Store usernames and hashed passwords in a DynamoDB table and validate credentials in each Lambda function
Explanation:
- Why correct: Amazon Cognito user pools provide managed sign-up, sign-in, password policies, and MFA out of the box. API Gateway has a native Cognito user pool authorizer that validates the JWT token from Cognito automatically — no custom Lambda authorizer code needed. This is the least operational effort solution.
- Why A is wrong: IAM users are meant for AWS account access, not application end users. Creating an IAM user per app user does not scale, violates security best practices, and distributing access keys in a mobile app is a serious security risk.
- Why B is wrong: Building a custom authentication service on EC2 requires managing servers, patching, scaling, and writing JWT issuance/validation logic — all of which Cognito handles as a managed service. This violates the 'minimal custom code' requirement.
- Why D is wrong: Storing credentials in DynamoDB means the developer must implement password hashing, token management, session handling, and authorization logic manually in every Lambda function. This is error-prone and unnecessary when Cognito provides these capabilities natively.
Question 19 — Domain 3: Deployment
A developer builds a Lambda function that includes a large machine learning library. The resulting ZIP deployment package is 100 MB. When the developer tries to upload the package through the Lambda console, the upload fails. What should the developer do to deploy this function?
- Retry the console upload with a smaller timeout setting
- Repackage the function as a container image and deploy from Amazon ECR
- Upload the ZIP to an S3 bucket and provide the S3 object location when creating the function — Correct answer
- Split the ML library into a Lambda Layer to reduce the main package size below 50 MB
Explanation:
- Why correct: Lambda's direct upload (via console or API) is limited to 50 MB for ZIP packages. For packages between 50 MB and 250 MB (uncompressed), the developer must first upload the ZIP to an S3 bucket and then provide the S3 object location when creating or updating the Lambda function. This is the standard approach for large deployment packages.
- Why A is wrong: The 50 MB direct upload limit is a hard limit for the Lambda console and UpdateFunctionCode API with ZipFile parameter. The developer cannot bypass this by retrying or using a different browser.
- Why B is wrong: While Lambda does support container images up to 10 GB, repackaging as a container image is unnecessary overhead when the ZIP is only 100 MB — well within the 250 MB S3 upload limit. Container images add complexity (Dockerfile, ECR repository) that isn't warranted here.
- Why D is wrong: Lambda Layers are designed for sharing common libraries across multiple functions, not for bypassing deployment size limits. The total unzipped size of the function plus all layers must still be under 250 MB. A layer doesn't solve the upload mechanism issue.
Question 20
A developer has a DynamoDB table with a partition key of UserId and a sort key of OrderDate. The application now needs to query orders by ProductCategory across all users. The table already contains data. Which approach should the developer use?
- Add a Local Secondary Index with ProductCategory as the sort key
- Use a Scan operation with a FilterExpression on ProductCategory
- Create a new table with ProductCategory as the partition key and replicate data
- Add a Local Secondary Index with ProductCategory as the partition key
- Add a Global Secondary Index with ProductCategory as the partition key — Correct answer
Explanation:
- Why correct: A Global Secondary Index (GSI) allows you to define an entirely different partition key and sort key from the base table. Creating a GSI with ProductCategory as the partition key enables efficient Query operations across all users for a given category. GSIs can be added to an existing table at any time, making this the correct solution for an already-populated table.
- Why A is wrong: A Local Secondary Index (LSI) shares the same partition key as the base table (UserId) and only allows an alternate sort key. Since the requirement is to query across all users by ProductCategory, an LSI would still require knowing the UserId first, which does not solve the access pattern.
- Why B is wrong: Using a Scan operation with a filter on ProductCategory reads the entire table and discards non-matching items. This consumes significant read capacity and becomes increasingly slow and expensive as the table grows. It is not an efficient solution.
- Why C is wrong: Creating a new table with ProductCategory as the partition key would require duplicating and synchronizing data between two tables, adding complexity and consistency challenges. A GSI achieves the same query capability without managing a separate table.
- Why D is wrong: LSIs can only be created at table creation time — they cannot be added after the table already contains data. This option is factually incorrect for an existing table.
Question 21
An e-commerce application must notify three independent microservices (inventory, shipping, analytics) whenever a new order is placed. Each service must process every order event independently. What is the MOST reliable and decoupled architecture?
- Create one SQS queue and have each microservice poll the same queue
- Publish the event to an SNS topic with SQS queues subscribed for each microservice — Correct answer
- Have the order service call each microservice synchronously via HTTP
- Write the event to an S3 bucket and configure each microservice to poll for new objects
Explanation:
- Why correct (B): The SNS-to-SQS fanout pattern publishes one message to an SNS topic, which delivers a copy to each subscribed SQS queue. Each microservice processes independently from its own queue, ensuring all three services receive every event with decoupled, asynchronous processing.
- Why A is wrong: With a single SQS queue and multiple consumers, each message is delivered to only one consumer (competing consumers pattern). The other two microservices would not receive the event.
- Why C is wrong: Synchronous HTTP calls tightly couple the order service to each downstream service. If any service is unavailable, the order processing fails, reducing reliability and increasing latency.
- Why D is wrong: S3 event notifications can trigger processing, but polling S3 for new objects introduces latency, complexity, and is not designed for real-time message fanout. S3 is optimized for object storage, not messaging.
Question 22 — Domain 3: Deployment
A developer is configuring a CodeBuild project and needs to install dependencies before building the application. The buildspec.yml file has multiple phases available. In which phase should the developer install dependencies such as npm packages or pip modules?
- The install phase, which is intended for installing dependencies needed for the build — Correct answer
- The post_build phase, which runs after the build completes
- The build phase, which is intended for the actual build commands
- The pre_build phase, which runs commands before the build but after installing dependencies
Explanation:
- Why correct: The buildspec.yml install phase is specifically designed for installing packages and dependencies (e.g., npm install, pip install). CodeBuild phases execute in order: install → pre_build → build → post_build.
- Why B is wrong: The post_build phase runs after the build completes and is typically used for packaging artifacts, notifications, or cleanup — not installing dependencies.
- Why C is wrong: The build phase is for running the actual build commands (e.g., compilation). Dependencies should already be available before this phase.
- Why D is wrong: The pre_build phase runs before the build and is used for tasks like logging into registries or running unit tests, but dependency installation should happen in the install phase so they are available for pre_build commands.
Question 23
A company is building a mobile application that authenticates users with Amazon Cognito user pools. After authentication, the app needs to allow users to upload files to an S3 bucket scoped to their identity. What is the MOST secure way to grant the mobile app temporary AWS credentials?
- Use a Cognito user pool to issue AWS credentials directly to the application
- Use a Cognito identity pool to exchange the user pool token for temporary AWS credentials — Correct answer
- Embed IAM access keys in the mobile application configuration
- Create an IAM user for each mobile app user and distribute credentials at registration
Explanation:
- Why correct: Amazon Cognito identity pools (federated identities) are designed to exchange authenticated tokens (from Cognito user pools, social providers, or SAML) for temporary AWS credentials via STS. This allows the mobile app to directly access AWS services like S3 or DynamoDB with scoped IAM permissions, without building a backend proxy.
- Why A is wrong: Cognito user pools handle authentication (sign-up, sign-in, tokens) but do not issue AWS credentials. A user pool alone cannot grant access to S3 or DynamoDB — you need an identity pool to exchange the user pool token for temporary AWS credentials.
- Why C is wrong: Embedding long-term IAM access keys in a mobile application is a critical security anti-pattern. Keys can be extracted through reverse engineering and cannot be rotated without redeploying the app. Temporary credentials from identity pools are the correct approach.
- Why D is wrong: Creating individual IAM users per mobile app user is unscalable and violates the principle of using federated access for external users. IAM users are intended for people or services within your organization, not for application end-users.
Question 24 — Domain 3: Deployment
A company is expanding an application to a second AWS Region. The developer wants to gradually shift 10% of production traffic to the new Region to validate performance before a full cutover. Which Route 53 configuration achieves this?
- Route 53 latency-based routing to direct traffic to the lowest-latency Region
- Route 53 weighted routing to send 10% of DNS queries to the new Region — Correct answer
- Route 53 failover routing with the new Region as the primary
- Route 53 geolocation routing to send all traffic to the new Region
Explanation:
- Why correct: Weighted routing lets the developer assign a numeric weight to each record set. By giving the new Region a weight of 10 and the existing Region a weight of 90, approximately 10% of DNS responses will resolve to the new Region. This is the standard approach for gradual traffic shifting during multi-Region rollouts, allowing the team to monitor error rates and performance before increasing the weight.
- Why A is wrong: Latency-based routing directs each user to the Region with the lowest network latency. It does not allow the developer to control what percentage of traffic goes to each Region — it is determined entirely by measured latency, so the team cannot limit exposure to the new Region.
- Why C is wrong: Failover routing designates a primary and secondary record. The secondary only receives traffic when the primary fails a health check. This would send all traffic to the new Region by default, which is the opposite of a controlled rollout.
- Why D is wrong: Geolocation routing directs traffic based on the geographic location of the user. It cannot split a percentage of traffic from the same geography across two Regions, so it does not support gradual traffic shifting.
Question 25
A security team requires comprehensive auditing for an AWS account. They need to track both API calls made to AWS services and access to data stored in Amazon S3 buckets. The team configures AWS CloudTrail. Which TWO event types must be enabled to meet both requirements?
- CloudWatch metric events
- AWS Config configuration events
- Management events to capture control plane API calls — Correct answer
- Data events to capture S3 object-level operations like GetObject and PutObject — Correct answer
- VPC Flow Log events
Explanation:
- Why C is correct: Management events (also called control plane events) record API calls that manage AWS resources — such as CreateBucket, RunInstances, CreateUser, and PutBucketPolicy. These are enabled by default in CloudTrail trails and cover the 'API calls made to AWS services' requirement.
- Why D is correct: Data events (also called data plane events) record resource operations performed on or within a resource — such as S3 GetObject, PutObject, and DeleteObject, or Lambda Invoke calls. Data events are NOT enabled by default because they are high-volume. They must be explicitly configured in the trail to capture S3 object-level access.
- Why A is wrong: CloudWatch metric events are not a CloudTrail event type. CloudWatch is a separate monitoring service. While CloudTrail can send logs to CloudWatch Logs, 'metric events' is not a valid CloudTrail category.
- Why B is wrong: AWS Config records resource configuration changes and compliance state, but these are AWS Config concepts, not CloudTrail event types. Config and CloudTrail are complementary but distinct services.
- Why E is wrong: VPC Flow Logs capture IP traffic information for network interfaces in a VPC. They are a VPC feature, not a CloudTrail event type. Flow Logs record network-level data (source/destination IPs, ports, protocols), not API calls or data access.
Question 26 — Domain 1: Development with AWS Services
A developer is configuring an Amazon Data Firehose delivery stream to deliver real-time application logs to multiple AWS services. Which THREE are supported built-in destinations for Firehose?
- Amazon S3 — Correct answer
- Amazon DynamoDB
- Amazon OpenSearch Service — Correct answer
- Amazon RDS
- Amazon Redshift — Correct answer
- Amazon Aurora
Explanation:
- Why correct: Amazon Data Firehose natively supports delivery to Amazon S3, Amazon Redshift (via S3 intermediate copy), and Amazon OpenSearch Service as built-in destinations. These are the three AWS-native destinations Firehose can deliver to directly.
- Why A is correct: S3 is a supported Firehose destination — this is correct.
- Why B is wrong: Amazon DynamoDB is not a supported Firehose destination. To write to DynamoDB, you would need to use a Lambda consumer on a Kinesis Data Stream or a custom integration.
- Why C is correct: OpenSearch Service is a supported Firehose destination — this is correct.
- Why D is wrong: Amazon RDS is not a supported Firehose destination. Firehose is designed for streaming delivery to storage and analytics services, not relational databases.
- Why E is correct: Redshift is a supported Firehose destination (data is staged in S3, then copied to Redshift via a COPY command) — this is correct.
- Why F is wrong: Amazon Aurora is not a supported Firehose destination. Like RDS, relational databases are not part of Firehose's built-in delivery targets.
Question 27 — Domain 1: Development with AWS Services
A developer is writing a Lambda function that processes large datasets. The function occasionally times out before completing. The developer wants to add logic that checks how much execution time remains so the function can save its progress and exit gracefully before the timeout. How should the developer determine the remaining execution time within the Lambda function?
- Read the event object's timeout_remaining field
- Use the context.get_remaining_time_in_millis() method — Correct answer
- Query the Lambda service API from within the function to check remaining time
- Parse the AWS_LAMBDA_FUNCTION_TIMEOUT environment variable at runtime
Explanation:
- Why correct: The Lambda context object provides the get_remaining_time_in_millis() method (Python) or getRemainingTimeInMillis() (Java/Node.js), which returns the number of milliseconds remaining before the function times out. This allows the developer to check remaining time and gracefully handle cleanup or partial processing before the timeout.
- Why A is wrong: The event object contains the input data that triggered the function (e.g., API Gateway request body, S3 event details). It does not contain any timeout or execution metadata — that information is only available through the context object.
- Why C is wrong: There is no Lambda service API call to check remaining execution time from within a running function. The context object is the only mechanism provided by the Lambda runtime to access this information, and it works locally without any API call overhead.
- Why D is wrong: There is no AWS_LAMBDA_FUNCTION_TIMEOUT environment variable. Lambda does provide environment variables like AWS_LAMBDA_FUNCTION_NAME and AWS_LAMBDA_FUNCTION_MEMORY_SIZE, but the configured timeout is not exposed as an environment variable. Even if it were, it would only give the total timeout, not the remaining time during execution.
Question 28
A company has a REST API on Amazon API Gateway that serves a single-page application. Users authenticate through Amazon Cognito User Pools and receive JWT tokens. The developer needs to authorize API requests using these tokens with the LEAST operational overhead. Which API Gateway authorizer type should the developer use?
- Lambda authorizer that validates the Cognito JWT in custom code
- Cognito User Pool authorizer configured with the User Pool ID — Correct answer
- IAM authorization with Signature Version 4 signing
- API key required on all methods via a usage plan
Explanation:
- Why correct: A Cognito User Pool authorizer validates JWT tokens issued by Cognito User Pools directly at the API Gateway level, with no custom code required. This is the simplest and most operationally efficient approach when the identity provider is already Cognito. API Gateway natively integrates with Cognito User Pools: you configure the authorizer with the User Pool ID, and API Gateway validates the token signature, expiration, and claims automatically.
- Why A is wrong: A Lambda authorizer (formerly custom authorizer) can validate tokens, but it requires writing and maintaining custom Lambda function code to parse and validate JWTs. This adds unnecessary operational overhead when Cognito is already the identity provider, since the built-in Cognito authorizer handles this natively.
- Why C is wrong: IAM authorization with SigV4 is designed for service-to-service or AWS SDK-based calls where the caller has AWS credentials. It is not appropriate for browser-based users authenticating with username/password through Cognito.
- Why D is wrong: API keys are not an authentication or authorization mechanism. API keys are used for tracking and throttling via usage plans. They can be easily shared or stolen and do not verify user identity. AWS documentation explicitly states API keys should not be used as the sole means of access control.
Question 29 — 1
A developer's AWS CodeBuild project must compile a Java application, run unit tests, and push the resulting Docker image to Amazon ECR. The developer is writing the buildspec.yml file. Which phase ordering correctly follows AWS CodeBuild best practices?
- install: compile and run tests; build: push Docker image to ECR
- pre_build: log in to Amazon ECR; build: compile source and run unit tests; post_build: build and push the Docker image — Correct answer
- build: compile, test, build Docker image, and push to ECR all in a single phase
- install: build Docker image; pre_build: compile source; build: run tests; post_build: log in to ECR and push
Explanation:
- Why correct: AWS best practice for buildspec.yml is to use pre_build for setup tasks such as logging into ECR, the build phase for the core compilation and testing work, and post_build for packaging and publishing artifacts like Docker images. This separation ensures that if the build or tests fail, the image is never pushed.
- Why A is wrong: The install phase is intended for installing build-time dependencies and runtime versions (e.g., a specific JDK), not for compiling application code or running tests.
- Why C is wrong: Putting everything in a single build phase works but is not a best practice—it loses the benefit of phase separation. If the Docker push fails after tests pass, there is no distinction in the build report between a test failure and a push failure.
- Why D is wrong: This inverts the logical flow. Building a Docker image before compiling the source code is nonsensical, and logging into ECR in post_build (after the image is built) is too late if the push needs credentials established beforehand.
Question 30
A developer's serverless application consists of API Gateway, Lambda, and DynamoDB. Users report intermittent latency spikes and occasional errors. The developer needs to identify which service in the call chain is causing the issue and correlate errors across requests. Which TWO AWS services should the developer use? (Select TWO.)
- AWS Config
- Amazon CloudWatch Logs Insights — Correct answer
- Amazon CodeGuru Profiler
- AWS CloudTrail
- AWS X-Ray — Correct answer
Explanation:
- Why correct: CloudWatch Logs Insights allows the developer to run queries across log groups to identify the specific error patterns, while X-Ray provides a service map and trace analysis that reveals which downstream service call is causing the intermittent latency spikes and failures.
- Why CloudWatch is correct: CloudWatch Logs Insights enables ad-hoc queries on structured log data to correlate error patterns with specific request attributes, and CloudWatch metrics can show error rate trends.
- Why X-Ray is correct: X-Ray's service map visualizes the call flow between API Gateway, Lambda, and DynamoDB, and its trace timeline pinpoints which segment (e.g., a DynamoDB call) is causing latency spikes.
- Why A is wrong: AWS Config tracks resource configuration changes and compliance, not application-level performance. It would help if the issue were a configuration drift, but the scenario describes intermittent runtime performance problems.
- Why C is wrong: CodeGuru Profiler identifies the most expensive lines of code within a single application, but it does not trace requests across multiple services. The developer needs cross-service visibility, not single-function profiling.
- Why D is wrong: CloudTrail logs AWS API calls for auditing and governance (e.g., who created or deleted a resource). It does not capture application-level performance metrics or request traces.
JavaScript is required to use this application.
Please enable JavaScript in your browser to access the full NestedCerts platform.
Contact: support@nestedcerts.com