AWS Certified Developer Associate DVA-C02 DVA-C02 Questions 901–975 | Page 13/16

901

MCQhard

A developer is deploying a serverless application that includes an AWS Lambda function with a dependency on a native library (e.g., a compiled C library). The developer uses AWS SAM. The Lambda function runs correctly in the local development environment but fails with an 'Unable to import module' error when deployed. What is the most likely cause?

A.The Lambda function's IAM role does not have permission to access the library.

B.The Lambda function's handler configuration is incorrect.

C.The native library is compiled for a different operating system than Lambda (Amazon Linux).

D.The Lambda function's timeout is too short.

AnswerC

AWS Lambda execution environments are based on Amazon Linux, requiring any native libraries (e.g., C/C++ compiled into .so files) to be compiled specifically for this operating system and its architecture (x86_64 or arm64). If a library is compiled on a different OS, such as macOS or Windows, or even a different Linux distribution, its binary format and system dependencies will be incompatible. This incompatibility leads to an ImportError when the Lambda runtime attempts to load the shared object, as it cannot resolve the necessary symbols or link against the correct system libraries.

Why this answer

AWS Lambda runs on Amazon Linux, which uses a different kernel and C runtime than typical local development environments (e.g., macOS or Windows). Native libraries compiled for a local OS will not be compatible with Lambda's execution environment, causing the 'Unable to import module' error. The developer must compile the native library on Amazon Linux or use a Lambda-compatible container to ensure binary compatibility.

Exam trap

The trap here is that candidates often confuse IAM permissions with filesystem access, or assume the error is a code-level issue (handler or timeout) rather than recognizing the OS-level binary incompatibility unique to Lambda's Amazon Linux environment.

How to eliminate wrong answers

Option A is wrong because IAM roles control permissions to AWS services and resources, not the ability to import or execute local native libraries within the Lambda runtime. Option B is wrong because the handler configuration (e.g., 'index.handler') is unrelated to native library import failures; a misconfigured handler would produce a 'Handler not found' error, not an import error. Option D is wrong because a timeout error occurs during function execution, not during the initialization/import phase; the 'Unable to import module' error happens before the handler runs.

Full explanation →

902

MCQmedium

A developer is building a serverless application using AWS Lambda functions that process events from Amazon SQS. The developer notices that some messages are being processed multiple times. What is the MOST likely cause of this issue?

A.The Lambda function's reserved concurrency is set too high.

B.The SQS visibility timeout is too short for the Lambda function's execution time.

C.The SQS queue has a dead-letter queue configured.

D.The Lambda function's batch size is set to more than 1.

AnswerB

When an SQS message is received by a Lambda function, it becomes temporarily invisible to other consumers for the duration of the visibility timeout. If the Lambda function's processing time exceeds this timeout, the message will reappear in the queue, becoming available for another Lambda invocation to pick up and process again. This scenario directly leads to duplicate message processing, as the original invocation might still be working on the message while a new one begins.

Why this answer

When an SQS message is processed by a Lambda function, the message becomes invisible to other consumers for the duration of the visibility timeout. If the Lambda function takes longer to process the message than the visibility timeout, SQS makes the message visible again and can deliver it to another consumer (or the same Lambda function in a new invocation), causing duplicate processing. This is the most likely cause of messages being processed multiple times.

Exam trap

The trap here is that candidates may confuse the visibility timeout with the Lambda function timeout or think that increasing concurrency or batch size causes duplicates, when in fact the visibility timeout directly controls the window for duplicate processing.

How to eliminate wrong answers

Option A is wrong because reserved concurrency limits the number of concurrent Lambda executions but does not cause duplicate message processing; it may actually throttle invocations. Option C is wrong because a dead-letter queue is used to capture messages that fail processing after a maximum number of retries, not to cause duplicate processing. Option D is wrong because setting the batch size to more than 1 allows Lambda to process multiple messages in a single invocation, which reduces the chance of duplicates by processing them together, not causing duplicates.

Full explanation →

903

MCQmedium

A developer is deploying a serverless application using AWS SAM. The developer runs 'sam deploy' but receives an error that the S3 bucket does not exist. How should the developer fix this?

A.Use sam publish to deploy the application.

B.Run sam build to generate the bucket.

C.Create an S3 bucket and specify it with --s3-bucket.

D.Run sam package to create the bucket automatically.

AnswerC

AWS SAM CLI does not automatically provision the S3 bucket used to stage CloudFormation deployment artifacts (unless using the guided deploy flow's managed bucket); the developer must create the bucket first and pass its name via --s3-bucket, or run sam deploy --guided to have SAM create and remember one.

Why this answer

AWS SAM requires an S3 bucket to store the packaged application artifacts (Lambda code, nested stacks) during deployment. If the bucket specified (or the default SAM-managed bucket) does not exist, the developer must create an S3 bucket and pass it via the --s3-bucket parameter to sam deploy.

Exam trap

DVA-C02 often tests the difference between sam build, sam package, sam deploy, and sam publish — the trap is assuming sam package or sam build creates the S3 bucket, when only an explicit bucket creation or --s3-bucket specification resolves the error.

How to eliminate wrong answers

Option A is wrong because sam publish publishes an application to the AWS Serverless Application Repository, not deploy it, and does not create an S3 bucket. Option B is wrong because sam build only compiles/builds the application locally; it does not create S3 buckets. Option D is wrong because sam package uploads artifacts to an existing S3 bucket (or one specified with --s3-bucket) but does not create the bucket automatically.

Full explanation →

904

MCQhard

Messages in an SQS queue are processed successfully but later reappear and are processed again. What is the most likely configuration issue?

A.The queue uses long polling

B.The queue has a dead-letter queue

C.The messages are encrypted with SSE-SQS

D.The visibility timeout is shorter than the processing time or messages are not deleted after processing

AnswerD

If the visibility timeout is shorter than the actual time required to process a message, the message will become visible again to other consumers before the initial consumer finishes and deletes it, leading to duplicate processing. Alternatively, if a consumer successfully processes a message but fails to explicitly call the `DeleteMessage` API, the message will remain in the queue and become visible again once its timeout expires, resulting in reprocessing. Both scenarios directly explain why messages might be processed successfully but still reappear.

Why this answer

When a message is processed but not deleted from the SQS queue, or when the visibility timeout expires before processing completes, the message becomes visible again in the queue and can be consumed by another worker. This causes duplicate processing. The correct fix is to ensure the visibility timeout is set longer than the expected processing time and that the message is explicitly deleted after successful processing.

Exam trap

The trap here is that candidates may confuse message reappearance with dead-letter queue behavior, but dead-letter queues only trigger after a configurable number of receive attempts, not after a single successful processing cycle.

How to eliminate wrong answers

Option A is wrong because long polling reduces empty responses and cost by waiting for messages, but does not cause messages to reappear after processing. Option B is wrong because a dead-letter queue captures messages that have failed processing multiple times, not cause reprocessing of successfully handled messages. Option C is wrong because SSE-SQS encrypts messages at rest, which has no effect on message visibility or deletion behavior.

Full explanation →

905

Multi-Selectmedium

A developer is configuring an Amazon S3 bucket for static website hosting. The website includes JavaScript that makes AJAX calls to an API Gateway endpoint. Which TWO actions should the developer take to allow cross-origin requests?

Select 2 answers

A.Use Amazon CloudFront to serve the website and set CORS headers.

B.Add a CORS configuration to the S3 bucket.

C.Enable CORS on the API Gateway API.

D.Configure the S3 bucket policy to allow cross-origin access.

E.Modify the Lambda function to include CORS headers in the response.

AnswersC, E

Correct: Enabling CORS on API Gateway configures the API to respond to preflight OPTIONS requests with the necessary CORS headers.

Why this answer

The API Gateway API must have CORS enabled to accept cross-origin requests from the S3-hosted static website. For an API Gateway endpoint backed by a Lambda proxy integration, enabling CORS in API Gateway alone is not enough — the Lambda function must also include the appropriate CORS headers (such as Access-Control-Allow-Origin) in its response. Therefore, the developer should both enable CORS on the API and modify the Lambda function to return CORS headers.

Exam trap

The trap is to think that enabling CORS on API Gateway alone is sufficient or that the S3 bucket policy/CORS is involved. In cross-origin calls to an API Gateway endpoint from an S3-hosted site, the browser enforces CORS based on the API Gateway/Lambda response; for Lambda proxy integrations, both the API Gateway CORS setting and the Lambda response headers are required.

Full explanation →

906

MCQmedium

A company is using an S3 bucket to store sensitive data. They want to ensure that all objects uploaded to the bucket are encrypted at rest using server-side encryption with AWS KMS (SSE-KMS). What is the most secure way to enforce this?

A.Enable default encryption on the bucket with SSE-KMS.

B.Create a bucket policy that denies PutObject without encryption.

C.Create a bucket policy that denies PutObject unless the x-amz-server-side-encryption header is set to aws:kms.

D.Enable S3 Block Public Access on the bucket.

AnswerC

This bucket policy precisely enforces server-side encryption using AWS KMS for all new objects uploaded to the bucket. By including a Condition that checks StringEquals on the s3:x-amz-server-side-encryption key with a value of aws:kms, any PutObject request not specifying SSE-KMS will be explicitly denied. This ensures that all sensitive data at rest is encrypted with customer-managed or AWS-managed KMS keys, providing robust protection.

Why this answer

Option C is correct because a bucket policy that denies PutObject unless the x-amz-server-side-encryption header equals aws:kms actively rejects any upload that does not explicitly request SSE-KMS, making it the strongest enforcement mechanism for this scenario. This policy-level Deny cannot be bypassed by users or roles, and it ensures every object is encrypted with AWS KMS keys rather than weaker or default encryption. Option A only sets a default that can be overridden by an uploader specifying a different encryption method, so it does not truly enforce SSE-KMS.

Option B is too vague because it does not specify the required encryption type, allowing SSE-S3 or other algorithms, and Option D addresses public access, not encryption at rest.

Full explanation →

907

Multi-Selecteasy

Which TWO actions can help reduce Lambda cold start times? (Choose two.)

Select 2 answers

A.Increase the deployment package size.

B.Increase the memory allocated to the function.

C.Use Provisioned Concurrency.

D.Place the function in a VPC.

E.Reduce the function timeout.

AnswersB, C

Lambda allocates CPU proportionally to the amount of memory configured, so more memory means more CPU power available during initialization. This speeds up tasks like loading the runtime, unpacking code, and running static initializers, thereby shortening the cold start duration. It is a practical tuning knob, though it increases cost per invocation.

Why this answer

Option B is correct because AWS Lambda allocates CPU proportionally to the configured memory, so increasing the memory allocated to the function gives it more CPU power and speeds up initialization of the runtime and code, thereby reducing cold start duration. Option C is correct because Provisioned Concurrency pre-initializes a requested number of execution environments and keeps them warm, so invocations are served by already-initialized environments and avoid the cold start entirely. Option A is incorrect because a larger deployment package takes longer to download and unpack during initialization, which increases cold start time.

Option D is incorrect because placing the function in a VPC adds ENI creation and attachment overhead during initialization, typically worsening cold starts. Option E is incorrect because the function timeout only limits how long an invocation may run; it does not affect initialization time and can even cause failures if set too low.

Exam trap

DVA-C02 often tests the misconception that a larger deployment package or VPC placement improves cold start performance, when in reality both tend to worsen it; the correct levers are memory allocation and Provisioned Concurrency.

Full explanation →

908

Multi-Selecthard

A security audit reveals that an S3 bucket is publicly accessible. The bucket policy is as follows: {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":"*","Action":"s3:GetObject","Resource":"arn:aws:s3:::my-bucket/*"}]}. Which TWO actions should be taken to remediate this issue? (Select TWO.)

Select 2 answers

A.Remove the public access grant from the bucket ACL.

B.Create an IAM user policy that denies s3:GetObject for anonymous users.

C.Enable versioning on the bucket.

D.Modify the bucket policy to remove the Allow effect for Principal "*".

E.Enable default encryption on the bucket.

AnswersA, D

Removing a public access grant from the bucket Access Control List (ACL) is a direct and effective method to revoke public access. ACLs are a legacy access control mechanism that can explicitly grant read or write permissions to predefined groups like "Everyone" (public access) or "Authenticated Users". By deleting the specific ACL entry that allows public read access, the bucket immediately ceases to be publicly accessible via that mechanism.

Why this answer

The bucket ACL may still grant public access even if the bucket policy is the primary issue. Removing the public access grant from the ACL ensures that no anonymous principals have s3:GetObject permissions via ACLs, which is a separate access control mechanism from bucket policies. This is a direct remediation step to eliminate public read access.

Exam trap

The trap here is that candidates may think only the bucket policy needs fixing, overlooking that ACLs can independently grant public access, so both the policy and ACL must be remediated.

Full explanation →

909

MCQmedium

A company is using AWS Lambda to process sensitive data. The Lambda function needs to access an S3 bucket in the same account. What is the BEST practice for granting permissions?

A.Use an S3 bucket policy that allows access from the Lambda function's ARN.

B.Create an IAM role with a policy granting S3 access and attach it to the Lambda function.

C.Generate a key pair and use it to authenticate the Lambda function to S3.

D.Store the AWS access key ID and secret access key in the Lambda environment variables.

AnswerB

This is the AWS best practice for granting permissions to Lambda functions. By assigning an IAM execution role, the Lambda function automatically assumes this role and receives temporary, frequently rotated credentials from the AWS Security Token Service (STS) to interact with S3. This approach adheres to the principle of least privilege, centralizes access control, and eliminates the need to manage long-term static credentials within the function code or configuration, significantly enhancing security.

Why this answer

The AWS best practice for granting a Lambda function access to other AWS services is to create an IAM role with the required permissions and assign it as the function's execution role. Lambda assumes this role at runtime and the function receives temporary credentials via the environment, so no long-lived secrets are needed. This follows least-privilege and avoids credential management overhead.

Exam trap

DVA-C02 often tests the misconception that embedding access keys in environment variables is acceptable for Lambda, when the correct answer is always an IAM execution role with temporary credentials.

How to eliminate wrong answers

Option A is wrong because an S3 bucket policy alone does not give the Lambda function an identity to authenticate with — the function still needs an IAM role to obtain credentials, and resource-based policies are typically used in addition to, not instead of, identity-based permissions. Option C is wrong because key pairs are used for EC2 SSH access, not for authenticating Lambda to S3; S3 uses IAM, not SSH keys. Option D is wrong because storing long-lived access keys in environment variables is an anti-pattern that exposes credentials, requires manual rotation, and violates AWS security best practices.

Full explanation →

910

Multi-Selecthard

A company runs a serverless application on AWS using API Gateway, AWS Lambda, and DynamoDB. The application processes user uploads and stores metadata in DynamoDB. Recently, users have reported that some uploads fail with a 500 Internal Server Error. The CloudWatch Logs for the Lambda function show 'ProvisionedThroughputExceededException' errors for DynamoDB, followed by 'Task timed out after 3.00 seconds' errors. The Lambda function has a 3-second timeout and 128 MB of memory. The DynamoDB table has 5 read capacity units and 5 write capacity units. The application uses a single Lambda function that processes each upload synchronously. The company expects a steady increase in uploads. Which combination of actions should a developer take to resolve the errors and prepare for future growth? (Choose TWO.)

Select 2 answers

A.Increase the DynamoDB table's write capacity units to a higher value.

B.Switch the Lambda function to asynchronous invocation with a DLQ.

C.Modify the Lambda function to implement retries with exponential backoff on DynamoDB write operations.

D.Increase the Lambda function's timeout to 30 seconds.

E.Increase the Lambda function's reserved concurrency to 100.

AnswersA, C

The ProvisionedThroughputExceededException explicitly indicates that the DynamoDB table's allocated write capacity has been surpassed. Increasing the Write Capacity Units (WCUs) directly provisions more throughput for the table, allowing it to handle a higher volume of write requests per second without throttling. This is a direct and effective solution to prevent future throttling errors by scaling the underlying resource.

Why this answer

The errors are caused by DynamoDB throttling due to insufficient write capacity. Option A increases write capacity to handle the load. Option C implements retries with exponential backoff to handle occasional throttling without failing.

Option B would not help because the errors are from DynamoDB, not Lambda concurrency. Option D would increase latency but not solve throttling. Option E might cause duplicate processing.

Full explanation →

911

MCQmedium

A developer has an AWS Lambda function that processes messages from an Amazon SQS queue. The function is configured with a batch size of 10, reserved concurrency of 5, and a timeout of 5 minutes. The SQS queue has a large backlog, and CloudWatch metrics show high throttling (Throttles) for the Lambda function. The function is idempotent and can process up to 100 messages in a single invocation. What is the MOST effective way to increase throughput without increasing the reserved concurrency?

A.Increase the batch size to 100.

B.Increase the reserved concurrency to 10.

C.Reduce the batch size to 1.

D.Enable the SQS queue to use long polling.

AnswerA

Increasing the batch size for an SQS event source mapping allows each AWS Lambda invocation to process a larger number of messages simultaneously. This significantly reduces the total number of Lambda invocations required to process a given volume of messages, thereby lowering the demand for concurrent executions. By processing more work per invocation, the function is less likely to hit its concurrency limit and experience throttling, effectively optimizing resource utilization without increasing reserved concurrency.

Why this answer

Increasing the batch size to 100 allows each Lambda invocation to process up to 100 messages from the SQS queue instead of the current 10. Since the function is idempotent and can handle 100 messages per invocation, this change maximizes the number of messages processed per invocation without altering the reserved concurrency of 5. With a batch size of 100, each of the 5 concurrent invocations can process up to 100 messages, yielding a potential throughput of 500 messages per invocation cycle, which directly reduces the backlog and throttling by consuming messages faster.

Exam trap

The trap here is that candidates may think increasing reserved concurrency is the only way to improve throughput, but the question explicitly forbids that, and they overlook that increasing the batch size can achieve the same goal by processing more messages per invocation without adding more concurrent executions.

How to eliminate wrong answers

Option B is wrong because increasing reserved concurrency to 10 would increase throughput but directly violates the constraint of not increasing reserved concurrency, and it would also increase the risk of throttling other functions sharing the account concurrency limit. Option C is wrong because reducing the batch size to 1 would drastically decrease throughput, as each invocation would process only one message, requiring more invocations to handle the same backlog and potentially increasing throttling due to more concurrent executions. Option D is wrong because enabling long polling for the SQS queue reduces the number of empty responses and improves efficiency in message retrieval, but it does not increase the number of messages processed per invocation or reduce throttling caused by the Lambda function's concurrency limit.

Full explanation →

912

MCQeasy

A developer is creating a new DynamoDB table to store order data. The orders have a unique order ID and are retrieved by order ID. Occasionally, the developer needs to query orders by customer ID. Which design approach would minimize costs and provide the fastest queries?

A.Use the order ID as the partition key and create a global secondary index on customer ID

B.Use the customer ID as the partition key and order ID as the sort key

C.Use the order ID as the partition key and scan the table for customer ID queries

D.Use the customer ID as the partition key and create a local secondary index on order ID

AnswerA

This design effectively supports two distinct access patterns: retrieving a specific order by its unique order ID using a highly efficient GetItem operation, and querying all orders associated with a particular customer ID. By establishing a Global Secondary Index (GSI) with customer ID as its partition key, DynamoDB can efficiently retrieve all items matching that customer, optimizing performance and minimizing read capacity unit consumption for both primary and secondary query types.

Why this answer

Using the order ID as the partition key ensures the most efficient primary key access for the primary query pattern (retrieving by order ID). Creating a Global Secondary Index (GSI) on customer ID allows efficient querying by customer ID without scanning the base table, and GSIs have separate read/write capacity from the base table, so you only pay for the index when it is used. This design minimizes costs by avoiding unnecessary scans and provides the fastest queries for both access patterns.

Exam trap

The trap here is that candidates often choose Option B (customer ID as partition key) thinking it naturally supports both access patterns, but they overlook the hot partition problem and the fact that retrieving a single order by order ID would require a scan or a query with a known customer ID, which is not always available.

How to eliminate wrong answers

Option B is wrong because using customer ID as the partition key would cause all orders for the same customer to be stored in the same partition, leading to hot partitions and potential throttling, and it does not provide efficient retrieval by order ID (which would require a scan or a query with a known customer ID). Option C is wrong because scanning the entire table to find orders by customer ID is extremely inefficient and costly, as it reads every item in the table and incurs read capacity for all items, even those not matching the query. Option D is wrong because a Local Secondary Index (LSI) requires the same partition key as the base table (customer ID), which would still cause hot partitions for high-volume customers, and LSIs share the base table's read/write capacity, so they do not provide the same cost flexibility as a GSI.

Full explanation →

913

MCQhard

A company is deploying a critical application using AWS CloudFormation. The stack creation fails with a 'ROLLBACK_COMPLETE' status. The engineer wants to troubleshoot the failure without deleting the stack. What should the engineer do?

A.Use the 'aws cloudformation create-change-set' command with a rollback trigger.

B.Recreate the stack using the '--on-failure DO_NOTHING' option.

C.Use the 'aws cloudformation describe-stack-events' command to view the error messages.

D.Delete the stack and recreate it with the '--disable-rollback' flag.

AnswerC

The 'aws cloudformation describe-stack-events' command is the most effective method for troubleshooting a failed stack creation. It provides a chronological log of all events related to the stack, including the status of each resource operation (e.g., CREATE_IN_PROGRESS, CREATE_FAILED). Crucially, for failed events, it includes detailed error messages directly from the underlying AWS service, clearly indicating the specific resource that failed and the precise reason for its failure, enabling targeted debugging.

Why this answer

When a CloudFormation stack enters ROLLBACK_COMPLETE, the stack is in a terminal state and cannot be updated or re-created directly. The only way to troubleshoot without deleting the stack is to inspect the stack events, which contain detailed error messages for each resource failure. The 'aws cloudformation describe-stack-events' command returns a chronological list of events, including the exact reason why resource creation failed, such as insufficient permissions, invalid AMI ID, or dependency issues.

This allows the engineer to diagnose the root cause while preserving the stack for further analysis.

Exam trap

DVA-C02 often tests the misconception that you can update or recreate a stack in ROLLBACK_COMPLETE without deleting it, or that rollback options like DO_NOTHING or disable-rollback can be applied after the fact, when in reality the stack is immutable and only event logs provide diagnostic insight.

How to eliminate wrong answers

Option A is wrong because 'create-change-set' is used to propose changes to an existing stack in a non-terminal state (e.g., CREATE_COMPLETE or UPDATE_COMPLETE); it cannot be used on a stack in ROLLBACK_COMPLETE, and a rollback trigger is not a valid parameter for change sets. Option B is wrong because '--on-failure DO_NOTHING' is only applicable during stack creation, not after a rollback has already occurred; moreover, recreating the stack would not troubleshoot the existing failed stack and would leave the original stack in ROLLBACK_COMPLETE. Option D is wrong because deleting the stack destroys all associated resources and event history, which contradicts the requirement to troubleshoot without deleting; additionally, '--disable-rollback' is a creation-time option that would not help diagnose the existing failure.

Full explanation →

914

MCQhard

A developer is migrating a monolithic application to a microservices architecture on AWS. The application uses a relational database. The developer wants to use Amazon RDS for the database and needs to ensure that each microservice can only access its own set of tables. Which approach should the developer take?

A.Create a single RDS instance with a separate database per microservice.

B.Use RDS with IAM database authentication and create database users with limited privileges for each microservice.

C.Use RDS in a VPC and restrict network access per microservice using security groups.

D.Use Amazon RDS Proxy to control access.

AnswerB

AWS IAM database authentication integrates directly with IAM, allowing microservices to authenticate using IAM roles or users, eliminating the need for hardcoded database credentials. This method enables the creation of highly granular database users with specific permissions (e.g., SELECT on tableA, INSERT on tableB), ensuring each microservice can only access the precise tables and operations it requires. This robust, fine-grained access control is essential for securing a microservices architecture.

Why this answer

IAM database authentication allows the developer to create database users with granular, table-level privileges using standard SQL GRANT statements, ensuring each microservice can only access its own set of tables. By combining IAM roles with database user credentials, the developer can enforce least-privilege access without sharing a single database user across services. This approach directly addresses the requirement for per-microservice table isolation while leveraging RDS's native authentication and authorization capabilities.

Exam trap

The trap here is that candidates often confuse network-level isolation (security groups) with database-level authorization, assuming that restricting network access per microservice is sufficient to enforce table-level separation, when in fact security groups cannot differentiate between tables within the same database instance.

How to eliminate wrong answers

Option A is wrong because creating a separate database per microservice on a single RDS instance does not prevent a microservice from connecting to another microservice's database if it has the same database user credentials or network access; it only provides logical separation, not access control. Option C is wrong because security groups control network-layer access to the RDS instance as a whole, not to individual tables or databases within it; once a microservice can connect to the RDS endpoint, it can access any table unless further database-level permissions are enforced. Option D is wrong because Amazon RDS Proxy manages connection pooling and provides some IAM authentication support, but it does not enforce table-level access control; it still relies on the underlying database user permissions for authorization.

Full explanation →

915

Multi-Selectmedium

A developer is designing a microservices architecture using Amazon ECS with Fargate. The application needs to store and retrieve user session data. Which TWO AWS services can be used to store session state?

Select 2 answers

A.Amazon DynamoDB

B.Amazon ElastiCache for Redis

C.Amazon S3

D.Amazon EFS

E.Amazon RDS for MySQL

AnswersA, B

Amazon DynamoDB is a fully managed, serverless NoSQL database service offering single-digit millisecond performance at any scale. Its key-value data model is exceptionally well-suited for storing session state, where a session ID serves as the primary key for rapid retrieval and updates of associated user data. This low-latency, highly available, and scalable nature ensures a consistent and responsive user experience across distributed microservices without operational overhead.

Why this answer

Amazon DynamoDB (A) is correct because it is a fully managed, low-latency key-value NoSQL database that is commonly used to store session state for microservices, allowing fast reads/writes keyed by session ID with automatic scaling and TTL-based expiration. Amazon ElastiCache for Redis (B) is also correct because Redis is an in-memory data store with sub-millisecond latency and native support for data structures and key expiration, making it a standard choice for session caching and storage in containerized ECS/Fargate architectures. Amazon S3 (C) is not suitable because it is object storage with higher latency and eventual consistency characteristics, not designed for frequent small session reads/writes.

Amazon EFS (D) is a shared file system for POSIX workloads and is not intended as a low-latency session state store. Amazon RDS for MySQL (E) is a relational database that can technically store sessions, but it is not the typical high-throughput, low-latency session store for microservices and is not marked correct here.

Exam trap

The exam frequently tests your ability to choose the most performant and scalable options for session state. While you *can* technically store session data in RDS or S3, they are not optimized for the high-frequency, low-latency read/write patterns of session state. DynamoDB and ElastiCache are the standard AWS best-practice recommendations for this use case.

Full explanation →

916

MCQeasy

A development team uses AWS Elastic Beanstalk to deploy a web application. They want to perform a blue/green deployment to minimize downtime. What should they do to implement this?

A.Create an Auto Scaling group and manually replace instances.

B.Update the existing environment with the new version and set the deployment policy to 'Rolling'.

C.Use AWS CodeDeploy to perform a blue/green deployment on the EC2 instances.

D.Create a new environment, deploy the new version, and then swap the environment URLs.

AnswerD

Creating a second environment and swapping URLs uses Elastic Beanstalk's CNAME swap, which redirects traffic at the DNS level once the new version passes health checks. This satisfies the minimal-downtime constraint, since the original environment keeps serving until the swap completes, enabling instant rollback by swapping back.

Why this answer

Blue/green deployment in Elastic Beanstalk is achieved by creating a separate environment (the green environment) with the new application version, then swapping the CNAME records (URLs) of the two environments. This instantly routes traffic from the old (blue) environment to the new (green) environment with zero downtime, and allows quick rollback by swapping back.

Exam trap

The trap here is that candidates confuse the built-in Elastic Beanstalk blue/green deployment (environment swap) with the deployment policies (e.g., Rolling, Immutable) that operate within a single environment, or they incorrectly assume CodeDeploy is the only way to perform blue/green deployments.

How to eliminate wrong answers

Option A is wrong because manually replacing instances in an Auto Scaling group is not a blue/green deployment; it is a manual, error-prone process that does not provide instant traffic switching or easy rollback. Option B is wrong because updating the existing environment with a 'Rolling' deployment policy updates instances in batches within the same environment, which does not create a separate, isolated environment for the new version and still risks partial downtime. Option C is wrong because AWS CodeDeploy is a separate service that can perform blue/green deployments on EC2 instances, but the question specifically asks about using AWS Elastic Beanstalk, which has its own built-in blue/green deployment mechanism via environment URL swaps.

Full explanation →

917

MCQmedium

A developer is troubleshooting an AWS CloudFormation stack that failed to create. The error message says 'The following resource(s) failed to create: [MyEC2Instance]'. What is the first step the developer should take?

A.Update the stack with a new template.

B.Delete the stack and try again.

C.Review the CloudFormation template for syntax errors.

D.View the stack events in the CloudFormation console to see the specific error for the resource.

AnswerD

The CloudFormation console's "Events" tab provides a chronological log of every action taken by the stack, including resource creation attempts, status changes, and, critically, any errors encountered. When a resource fails to create, CloudFormation logs a specific CREATE_FAILED event for that resource, often including the underlying AWS service error message (e.g., "User is not authorized to perform this operation," "The specified S3 bucket already exists"). This detailed information is essential for diagnosing the exact cause of the failure.

Why this answer

When a CloudFormation stack fails to create, the error message only indicates which resource failed, not why. The first troubleshooting step is to view the stack events in the CloudFormation console, which provides detailed error messages for each resource, such as an API call failure, insufficient permissions, or a resource limit exceeded. This allows the developer to diagnose the root cause before making any changes.

Exam trap

The trap here is that candidates often jump to fixing the template or retrying the stack, overlooking that the specific error details are available in the stack events, which is the fastest path to identifying the actual cause.

How to eliminate wrong answers

Option A is wrong because updating the stack with a new template without understanding the failure reason could introduce additional errors or mask the underlying issue. Option B is wrong because deleting the stack and retrying without investigation wastes time and may repeat the same failure if the root cause (e.g., a missing parameter or IAM role) is not addressed. Option C is wrong because syntax errors in the template would typically be caught during validation before stack creation, and the error message specifically indicates a resource creation failure, not a template syntax issue.

Full explanation →

918

MCQhard

A developer wants a Lambda function to process SQS messages in batches but avoid losing the whole batch when only one record fails. Which feature should be enabled?

A.Partial batch response for SQS event source mapping

B.Reserved concurrency of one

C.Maximum message size increase

D.SQS short polling

AnswerA

Partial batch response for SQS event source mapping directly addresses the challenge of handling failures within a batch of messages processed by a Lambda function. When enabled, the Lambda function can return a list of message IDs that failed processing, allowing SQS to only return those specific messages to the queue for retry. This prevents successful messages within the same batch from being reprocessed, significantly improving efficiency, reducing costs, and simplifying error handling logic.

Why this answer

Partial batch response for SQS event source mapping allows the Lambda function to report which messages in a batch failed processing. When enabled, Lambda retries only the failed messages instead of the entire batch, preventing successful messages from being reprocessed or lost. This is achieved by returning a `batchItemFailures` array in the function's response, which tells Lambda which message IDs to retry.

Exam trap

The trap here is that candidates may confuse partial batch response with SQS dead-letter queues or retry policies, but the key differentiator is that partial batch response is a Lambda event source mapping feature that specifically allows per-message failure handling within a batch.

How to eliminate wrong answers

Option B is wrong because reserved concurrency of one limits the Lambda function to a single concurrent execution, which does not affect how individual messages within a batch are handled; it only throttles overall throughput. Option C is wrong because maximum message size increase is a queue-level setting in SQS that controls the maximum payload size (up to 256 KB for standard queues), not a mechanism for handling partial batch failures. Option D is wrong because SQS short polling returns immediately with available messages but does not provide any per-message failure handling within a batch; it only affects message retrieval latency.

Full explanation →

919

MCQmedium

A company's application running on Amazon ECS Fargate is experiencing high CPU utilization. The task definition has CPU set to 256 units. What should be done to improve performance?

A.Increase the desired count of tasks.

B.Increase the CPU value in the task definition and redeploy the service.

C.Increase the memory value in the task definition.

D.Switch to EC2 launch type.

AnswerB

The "cpu" parameter in an ECS Fargate task definition directly controls the amount of virtual CPU units allocated to each running task. By increasing this value, the application container within the task gains access to more processing power, enabling it to execute computations faster and reduce its overall CPU utilization percentage. Redeploying the service ensures that all new tasks launched by ECS will utilize this updated, higher CPU allocation, directly addressing the bottleneck.

Why this answer

Increasing CPU units in the task definition and redeploying the service will allocate more CPU to the tasks. Option A is wrong because horizontal scaling can help but the root cause is insufficient CPU per task. Option C is wrong because increasing memory does not affect CPU.

Option D is wrong because changing the launch type changes billing but not CPU allocation.

Full explanation →

920

Multi-Selecteasy

Which TWO AWS services can be used to automatically deploy code to Amazon EC2 instances? (Choose two.)

Select 2 answers

A.AWS Elastic Beanstalk

B.AWS CodeDeploy

C.AWS CloudFormation

D.AWS OpsWorks

E.AWS CodeBuild

AnswersA, B

AWS Elastic Beanstalk is a fully managed Platform as a Service (PaaS) that automatically handles the deployment, provisioning, and scaling of application code. Developers simply upload their application, and Beanstalk provisions and manages the underlying infrastructure, including EC2 instances, load balancers, and databases, enabling rapid and automated code deployment without manual server configuration.

Why this answer

AWS Elastic Beanstalk is a PaaS service that automates the deployment of applications to EC2 instances by handling capacity provisioning, load balancing, and health monitoring. It automatically deploys code when you upload a new application version, making it a correct choice for automated deployment to EC2.

Exam trap

The trap here is that candidates often confuse AWS CloudFormation's ability to deploy infrastructure with deploying application code, or they mistakenly think AWS CodeBuild's build process includes deployment, when in fact CodeBuild only produces artifacts and requires a separate service like CodeDeploy for actual deployment.

Full explanation →

921

MCQeasy

A developer is creating an AWS Lambda function that processes files uploaded to an S3 bucket. The developer wants to invoke the Lambda function automatically when a new file is uploaded. Which approach should the developer use?

A.Use Amazon API Gateway to expose an endpoint and have S3 call it.

B.Configure S3 to send events to an SQS queue, and configure Lambda to poll the queue.

C.Configure S3 event notifications to invoke the Lambda function directly.

D.Use Amazon CloudWatch Events to trigger Lambda on S3 PUT events.

AnswerC

Configuring S3 event notifications to invoke the Lambda function directly is the most straightforward and recommended approach for processing S3 object events. S3's native event notification feature allows a bucket to publish events, such as `s3:ObjectCreated:Put`, directly to an AWS Lambda function. This establishes a direct, asynchronous invocation model where S3 acts as the event source, pushing events to Lambda without requiring any intermediary services.

Why this answer

S3 can directly invoke a Lambda function via S3 event notifications. When a new object is created in the bucket, S3 publishes a notification with the event type `s3:ObjectCreated:*` and the Lambda function is triggered asynchronously. This is the simplest and most direct integration for this use case, requiring no intermediate services.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing an indirect pattern like SQS or CloudWatch Events, not realizing that S3 has a built-in, direct integration with Lambda for event notifications.

How to eliminate wrong answers

Option A is wrong because API Gateway is an unnecessary intermediary; S3 can invoke Lambda directly without needing an HTTP endpoint. Option B is wrong because while S3 can send events to SQS and Lambda can poll the queue, this adds complexity and latency for a simple file-processing scenario where direct invocation is supported. Option D is wrong because CloudWatch Events (now Amazon EventBridge) can trigger Lambda on S3 events, but this requires setting up a rule and is an indirect pattern; S3 event notifications are the native, simpler approach.

Full explanation →

922

MCQhard

A company runs a containerized application on Amazon ECS with Fargate launch type. The application needs to access an Amazon RDS MySQL database using credentials stored in AWS Secrets Manager. The ECS task role has the following IAM policy: {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["secretsmanager:GetSecretValue"],"Resource":"arn:aws:secretsmanager:us-east-1:123456789012:secret:prod-db-*"}]}. The application fails to retrieve the secret with an AccessDeniedException. What is the most likely cause?

A.The task execution role does not have permission to retrieve the secret.

B.The secret's resource-based policy denies access to the task role.

C.The task is in a private subnet without a VPC endpoint to Secrets Manager.

D.The secret name does not match the pattern in the policy.

AnswerB

AWS Secrets Manager supports resource-based policies, which are attached directly to the secret itself and specify which principals (like an ECS Task Role) are allowed or denied access. Even if the ECS Task Role has an identity-based policy that explicitly grants permission to retrieve secrets, an explicit Deny statement in the secret's resource-based policy will always override any Allow statements, effectively blocking access for the task role. This provides a powerful mechanism for fine-grained access control at the resource level.

Why this answer

The IAM policy on the ECS task role allows access to secrets matching the pattern `prod-db-*`. However, if the secret has a resource-based policy that explicitly denies access to the task role, that denial overrides the IAM allow, causing an AccessDeniedException. AWS Secrets Manager evaluates both identity-based policies (task role) and resource-based policies, and an explicit deny in either results in denial.

Exam trap

The trap here is that candidates confuse the task execution role with the task role, or assume network connectivity issues (VPC endpoints) are the cause when the error is clearly an IAM permissions denial.

How to eliminate wrong answers

Option A is wrong because the task execution role is used to pull container images and write logs, not to retrieve secrets; the task role (which has the policy shown) is used for application-level API calls like GetSecretValue. Option C is wrong because while a VPC endpoint can improve network connectivity, it is not required for Fargate tasks to reach Secrets Manager over the public internet or via NAT gateway; the error is an AccessDeniedException, not a network timeout. Option D is wrong because the secret name matches the pattern `prod-db-*` in the policy; the error is an access denial, not a resource mismatch.

Full explanation →

923

MCQhard

A developer is investigating why an AWS Lambda function is not writing logs to CloudWatch Logs. The function has been invoked multiple times, but the log group shows 0 stored bytes. What is the most likely cause?

A.The CloudWatch Logs log group does not exist.

B.The Lambda execution role lacks permissions to write to CloudWatch Logs.

C.The Lambda function is failing before any logging code is executed.

D.The Lambda function is configured to use a different log group name.

AnswerB

For an AWS Lambda function to successfully send its runtime logs and any application-specific output (e.g., from `console.log`) to CloudWatch Logs, its associated IAM execution role must possess specific permissions. Crucially, these include `logs:CreateLogStream` to create a new log stream within the log group and `logs:PutLogEvents` to send log data to that stream. Without these explicit permissions, the function will execute, but its logging attempts will silently fail, resulting in no log entries appearing in CloudWatch.

Why this answer

The most likely cause is that the Lambda execution role lacks the necessary IAM permissions to write logs to CloudWatch Logs. Without permissions such as `logs:CreateLogGroup`, `logs:CreateLogStream`, and `logs:PutLogEvents`, the Lambda function cannot create the log group or stream, nor can it write log events, resulting in 0 stored bytes despite successful invocations.

Exam trap

The trap here is that candidates assume a missing log group (Option A) is the root cause, when in fact the log group is automatically created if the IAM permissions are correct, making the permission issue the more fundamental problem.

How to eliminate wrong answers

Option A is wrong because the log group is automatically created by the Lambda service on the first invocation if the execution role has the required permissions; its absence is a symptom, not the root cause. Option C is wrong because if the function were failing before any logging code, the Lambda runtime itself would still attempt to write execution logs (e.g., START, END, REPORT messages) to CloudWatch, which would produce stored bytes. Option D is wrong because the log group name is predetermined by the Lambda service (e.g., /aws/lambda/<function-name>) and cannot be changed by the developer; a different log group name would not prevent logs from being written to the default group.

Full explanation →

924

MCQeasy

A developer is using AWS Lambda to process messages from an Amazon SQS queue. The function needs to access an Amazon DynamoDB table. What is the MOST secure way to grant the Lambda function access to DynamoDB?

A.Use the Lambda function's execution role to grant full administrative access to DynamoDB.

B.Store the AWS access key and secret access key as environment variables in the Lambda function.

C.Assign an IAM role to the Lambda function with a policy that grants the required DynamoDB permissions.

D.Create an IAM user with DynamoDB access and use its credentials in the Lambda function.

AnswerC

Assigning an IAM role to the Lambda function with a precisely scoped policy is the secure and recommended method for granting AWS service permissions. This approach leverages temporary credentials automatically managed by AWS, eliminating the need to store static access keys. The IAM policy can be crafted to adhere strictly to the principle of least privilege, allowing the function only the specific DynamoDB actions (e.g., dynamodb:PutItem, dynamodb:GetItem) on designated resources it requires to perform its task.

Why this answer

AWS Lambda uses an IAM execution role to securely obtain temporary credentials via the AWS Security Token Service (STS). By attaching a policy that grants only the required DynamoDB actions (e.g., GetItem, PutItem) on specific tables, you follow the principle of least privilege. This avoids hardcoding long-term credentials and eliminates the risk of credential exposure.

Exam trap

The trap here is that candidates may think storing credentials as environment variables is acceptable for simplicity, but the exam emphasizes that IAM roles with least-privilege policies are the most secure and AWS-recommended approach for granting permissions to AWS services like Lambda.

How to eliminate wrong answers

Option A is wrong because granting full administrative access (e.g., dynamodb:* on all resources) violates least privilege and could allow unintended actions like deleting tables. Option B is wrong because storing AWS access keys and secret access keys as environment variables exposes long-term credentials in plaintext, increasing the risk of leakage through logs or function output. Option D is wrong because creating an IAM user and embedding its credentials in the function requires managing long-term keys, which is less secure than using an execution role that automatically rotates temporary credentials.

Full explanation →

925

MCQmedium

A developer is building a serverless application using AWS Lambda and needs to securely store database credentials. Which AWS service should be used to store and retrieve the credentials?

A.AWS CloudFormation

B.AWS Secrets Manager

C.AWS Systems Manager Parameter Store

D.AWS Key Management Service (KMS)

AnswerB

AWS Secrets Manager is purpose-built for securely storing, managing, and retrieving sensitive information such as database credentials, API keys, and other application secrets throughout their lifecycle. It offers robust features like automatic rotation of secrets, fine-grained access control through IAM, and integration with other AWS services for easy secret injection into applications. Its ability to automatically rotate secrets without requiring application code changes is a key advantage for enhancing security posture and reducing operational overhead, making it the ideal choice for dynamic secret management.

Why this answer

AWS Secrets Manager (option B) is the correct choice because it is purpose-built to store, rotate, and retrieve secrets such as database credentials via API calls, and Lambda functions can fetch them at runtime using the AWS SDK with fine-grained IAM permissions. It also natively supports automatic rotation of credentials for supported databases like Amazon RDS, MySQL, and PostgreSQL, which reduces the risk of long-lived static credentials. AWS CloudFormation (A) is an infrastructure-as-code service for provisioning resources, not for storing secrets.

AWS Systems Manager Parameter Store (C) can hold parameters including SecureString values, but it lacks built-in secret rotation and is less tailored to credential lifecycle management. AWS KMS (D) is an encryption key management service that encrypts data but does not itself store or serve database credentials.

Full explanation →

926

MCQmedium

A company is building a serverless application using AWS Lambda and Amazon API Gateway. The application needs to process user uploads to an S3 bucket. The Lambda function should be invoked only when new objects are created in the bucket. Which service should be used to trigger the Lambda function?

A.Amazon Kinesis Data Streams

B.Amazon S3 event notifications

C.Amazon CloudWatch Events

D.Amazon Simple Queue Service (SQS)

AnswerB

Amazon S3 event notifications provide a direct, highly efficient, and serverless mechanism to trigger AWS Lambda functions in response to various object lifecycle events, such as object creation (e.g., `s3:ObjectCreated:*`). By configuring an event notification on an S3 bucket, S3 directly invokes the specified Lambda function with a detailed event payload. This eliminates the need for polling, custom code, or intermediary services, making it the most straightforward and cost-effective solution for reacting to S3 object uploads.

Why this answer

Amazon S3 event notifications can be configured to trigger AWS Lambda functions when specific events occur in an S3 bucket, such as when a new object is created (e.g., s3:ObjectCreated:*). This is the native and most direct way to invoke a Lambda function in response to S3 object uploads. It requires no additional polling or infrastructure and is highly scalable.

Exam trap

DVA-C02 often tests the confusion between S3 event notifications and other services like SQS or CloudWatch Events; candidates may overcomplicate by choosing SQS when S3 event notifications directly trigger Lambda.

How to eliminate wrong answers

Option A is wrong because Amazon Kinesis Data Streams is used for real-time streaming data, not for triggering Lambda on S3 object creation; it would require custom integration. Option C is wrong because Amazon CloudWatch Events (now Amazon EventBridge) can trigger Lambda on a schedule or in response to AWS API calls, but it does not natively capture S3 object creation events without additional configuration and is not the primary service for this use case. Option D is wrong because Amazon SQS is a message queue that decouples components; it does not directly trigger Lambda on S3 events unless you configure S3 to send notifications to SQS and then have Lambda poll the queue, which adds unnecessary complexity.

Full explanation →

927

MCQmedium

A developer is using Amazon SQS to decouple microservices. The consumer service processes messages from the queue. To reduce processing time, the developer wants to receive multiple messages in a single API call. What is the maximum number of messages that can be received at once?

A.5

B.100

C.20

D.10

AnswerD

This is the correct maximum value for the `MaxNumberOfMessages` parameter when calling the SQS `ReceiveMessage` API. Amazon SQS allows consumers to retrieve up to 10 messages in a single batch, which helps reduce the number of API calls, minimize network overhead, and improve overall processing efficiency for microservices. Requesting 10 messages optimizes throughput while adhering to the service's defined limits.

Why this answer

Amazon SQS allows a consumer to retrieve up to 10 messages in a single ReceiveMessage API call. This is the hard limit enforced by the SQS service, regardless of the queue type (standard or FIFO). Using this maximum batch size can reduce the number of API calls and improve throughput, but each message must still be processed individually and deleted after processing.

Exam trap

The trap here is confusing the SQS ReceiveMessage batch limit (10) with the SQS SendMessageBatch limit (10) or the Lambda event source mapping batch size (up to 10,000), leading candidates to pick 5, 20, or 100.

How to eliminate wrong answers

Option A is wrong because 5 is the maximum number of messages that can be sent in a single SendMessageBatch API call, not received. Option B is wrong because 100 is the maximum number of messages that can be sent or received in a single batch for Amazon SNS or Kinesis, but SQS limits ReceiveMessage to 10. Option C is wrong because 20 is the maximum batch size for AWS Lambda event source mappings when polling an SQS queue, not the limit for a single ReceiveMessage API call.

Full explanation →

928

MCQhard

A developer is writing a Lambda function that processes messages from an Amazon SQS queue. The function must ensure that if a message fails to process, it is retried later without blocking other messages. The queue is a standard queue. Which configuration should the developer use?

A.Use a Lambda event source mapping with a batch size greater than 1 and enable partial batch responses by returning batchItemFailures.

B.Configure a dead-letter queue on the SQS queue and set maxReceiveCount to 1.

C.Set the SQS queue's visibility timeout to 0 seconds so failed messages become immediately visible again.

D.Configure the Lambda event source mapping with a batch size of 1 and set the maximumBatchingWindowInSeconds to 0.

AnswerA

For standard queues, enabling partial batch responses lets the function return a list of failed message IDs. Lambda deletes only the successfully processed messages and returns the failed ones to the queue for retry, so one bad message does not force the entire batch to be reprocessed.

Why this answer

For standard queues, Lambda event source mappings support partial batch responses. When the function returns a batchItemFailures list, Lambda marks only those messages as failed, deletes the rest, and allows the failed messages to be retried according to the queue's visibility timeout and redrive policy.

Exam trap

The trap here is believing that any batch failure automatically retries only the failed message, when without partial batch responses the entire batch is retried and duplicates can occur.

Full explanation →

929

MCQhard

A company is designing a multi-account strategy using AWS Organizations. They want to enable cross-account access for developers using IAM roles. Each developer has an IAM user in the 'developers' account. The 'production' account has an IAM role 'AdminRole' that can be assumed by the 'developers' account. Which trust policy should be attached to 'AdminRole'?

A.{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:root"},"Action":"sts:AssumeRole"}]} where 123456789012 is the developers account ID.

B.{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ec2.amazonaws.com"},"Action":"sts:AssumeRole"}]}

C.{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:user/*"},"Action":"sts:AssumeRole"}]}

D.{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/AdminRole"},"Action":"sts:AssumeRole"}]}

AnswerA

The trust policy's Principal must name the trusting account's root ARN, 123456789012, which delegates assumption to that account's IAM users. Developers then attach a policy permitting sts:AssumeRole on AdminRole, satisfying cross-account role assumption from the developers account.

Why this answer

The trust policy on the 'AdminRole' in the production account must allow the entire 'developers' account (using its root ARN) to assume the role. When an IAM user in the developers account calls sts:AssumeRole, AWS evaluates the trust policy; specifying the root ARN of the developers account (arn:aws:iam::123456789012:root) delegates trust to the entire account, and the individual user's permissions are then controlled by an IAM policy attached to the user or a group that grants sts:AssumeRole for this role.

Exam trap

The trap here is that candidates often confuse the trust policy's Principal with the resource being accessed, mistakenly specifying the role's own ARN (Option D) or limiting to specific users (Option C), instead of using the root ARN of the trusted account to allow any authorized entity in that account to assume the role.

How to eliminate wrong answers

Option B is wrong because it specifies a Service principal (ec2.amazonaws.com), which is used for AWS services like EC2 to assume a role, not for cross-account IAM users. Option C is wrong because it restricts the principal to IAM users with a wildcard (arn:aws:iam::123456789012:user/*), which would not allow IAM roles or the root account to assume the role, and also does not cover cases where the developer might be using an IAM role in the developers account. Option D is wrong because it specifies the ARN of the AdminRole itself as the principal, which would create a self-referential trust policy that does not grant access to any external account; the principal must be the trusted account's root or specific IAM entities.

Full explanation →

930

MCQmedium

A company has a Lambda function that processes records from an SQS queue. The function is failing intermittently with timeout errors. The processing time per record varies, but the SQS queue has a visibility timeout of 30 seconds. The Lambda function has a timeout of 1 minute. What is the MOST likely cause of the timeout errors?

A.The Lambda function's reserved concurrency is set too low.

B.The SQS queue has too many messages causing Lambda to throttle.

C.The SQS visibility timeout is shorter than the Lambda function timeout.

D.The SQS queue's default visibility timeout of 30 seconds is too long.

AnswerC

If the SQS visibility timeout is configured to be shorter than the Lambda function's execution timeout, a message being processed by Lambda can become visible again in the queue before the function successfully completes its work. This scenario can lead to other Lambda instances, or even the same one, picking up and attempting to process the identical message again. Such duplicate processing can cause resource contention, unexpected behavior, and ultimately result in the original or subsequent Lambda invocations timing out as they struggle to complete the task or handle redundant operations.

Why this answer

When the SQS visibility timeout (30 seconds) is shorter than the Lambda function timeout (1 minute), the message becomes visible again in the queue before the function finishes processing it. This causes the same message to be picked up by another consumer (or the same Lambda invocation) while the original invocation is still running, leading to duplicate processing and eventual timeout errors as the function repeatedly attempts to process the same record.

Exam trap

The trap here is that candidates often confuse timeout errors with throttling or concurrency issues, but the specific interplay between SQS visibility timeout and Lambda function timeout is a classic DVA-C02 pitfall that tests understanding of asynchronous message processing lifecycle.

How to eliminate wrong answers

Option A is wrong because reserved concurrency limits the maximum number of concurrent Lambda executions, but timeout errors are not caused by concurrency limits—they occur when the function execution exceeds its configured timeout. Option B is wrong because Lambda throttling occurs when the number of concurrent invocations exceeds the account or function concurrency limit, not from too many messages in the queue; throttling results in invocation failures (e.g., 429 errors), not timeout errors within the function. Option D is wrong because a 30-second visibility timeout is not too long; in fact, it is too short relative to the Lambda timeout, causing premature message reappearance—a longer visibility timeout would help prevent the issue.

Full explanation →

931

MCQeasy

Refer to the exhibit. A CloudFormation stack update resulted in a rollback. What is the most likely reason for the rollback?

A.A user manually cancelled the update of the Lambda function.

B.The Lambda function update timed out.

C.The Lambda function's IAM role did not have sufficient permissions.

D.The Lambda function code was invalid.

AnswerA

When the exhibit shows the resource status reason as 'Resource update cancelled by user' or 'User Initiated Cancel', CloudFormation interprets this as an explicit cancel-update-stack API call or console action during the in-progress update, which halts the change set and triggers an automatic rollback of already-modified resources to their prior state.

Why this answer

The event message 'Resource update cancelled by user' indicates that the Lambda function update was cancelled by a user, triggering the rollback. Options B, C, and D are incorrect because there is no indication of a timeout, insufficient permissions, or invalid code; the error explicitly states user cancellation.

Full explanation →

932

MCQhard

A company uses AWS Lambda to process sensitive data. The Lambda function needs to access an RDS database with a password stored in AWS Secrets Manager. The function currently retrieves the secret using the AWS SDK. What is the best practice to secure this setup?

A.Configure the Lambda function to use IAM database authentication for RDS.

B.Store the password as a Lambda environment variable encrypted with KMS.

C.Use the AWS CLI within the Lambda function to fetch the secret each time.

D.Rotate the secret daily using Secrets Manager and cache it in Lambda.

AnswerA

Configuring the Lambda function to use IAM database authentication for RDS is the most secure and recommended approach. This method allows the Lambda function to connect using its execution role, generating short-lived, temporary authentication tokens instead of relying on static usernames and passwords. It eliminates the need to store or manage long-term database credentials, significantly enhancing security by leveraging AWS IAM's robust permission model and automatic credential rotation.

Why this answer

IAM database authentication eliminates the need to store or retrieve a password entirely. The Lambda function assumes an IAM role that generates a temporary authentication token (valid for 15 minutes) using the AWS SDK, which is then used to connect to RDS via TLS. This approach follows the principle of least privilege and removes the risk of static credentials being exposed or misused.

Exam trap

The trap here is that candidates assume Secrets Manager is always the best practice for secrets, but the question specifically asks for the best practice to secure the setup, and IAM authentication removes the secret entirely, which is more secure than any secret management approach.

How to eliminate wrong answers

Option B is wrong because storing the password as a Lambda environment variable, even if encrypted with KMS, still introduces a static secret that could be exposed through logs, error messages, or function configuration views. Option C is wrong because using the AWS CLI within a Lambda function is inefficient (adds cold-start latency and dependency on the CLI binary) and still requires the function to handle the secret in memory, whereas the SDK is the recommended method. Option D is wrong because daily rotation and caching in Lambda does not address the fundamental risk of a static password; the secret still exists and could be compromised, whereas IAM authentication removes the password entirely.

Full explanation →

933

MCQmedium

A company has a requirement to automatically rotate database credentials every 30 days. Which AWS service can meet this requirement with minimal development effort?

A.AWS KMS

B.AWS IAM

C.AWS Systems Manager Parameter Store

D.AWS Secrets Manager

AnswerD

AWS Secrets Manager is specifically designed to help you protect access to your applications, services, and IT resources by enabling you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle. It offers built-in, automated rotation for various database types, including Amazon RDS, Amazon DocumentDB, and other services, ensuring credentials are regularly updated without requiring application code changes.

Why this answer

AWS Secrets Manager is the correct choice because it provides built-in, automated rotation of database credentials without custom code. You can define a rotation schedule (e.g., every 30 days) and Secrets Manager will automatically update the secret and the database password using a Lambda function, meeting the requirement with minimal development effort.

Exam trap

The trap here is that candidates often confuse Systems Manager Parameter Store (which can store secrets but lacks automatic rotation) with Secrets Manager, overlooking the critical requirement for automated rotation with minimal effort.

How to eliminate wrong answers

Option A is wrong because AWS KMS is a key management service for encryption keys, not for storing or rotating database credentials. Option B is wrong because AWS IAM manages users, roles, and permissions, but it does not natively rotate database credentials or store secrets. Option C is wrong because AWS Systems Manager Parameter Store can store secrets but lacks built-in automatic rotation; you would need to build custom automation to rotate credentials every 30 days, which contradicts the 'minimal development effort' requirement.

Full explanation →

934

MCQmedium

A company stores sensitive documents in an Amazon S3 bucket. The security team requires that all objects uploaded must be encrypted at rest using a specific customer-managed AWS KMS key (key-id: 1234-5678). The developer must enforce this by denying any PutObject request that does not use the correct key. Which S3 bucket policy condition should be used?

A.s3:x-amz-server-side-encryption with value 'aws:kms'

B.s3:x-amz-server-side-encryption-aws-kms-key-id with value 'arn:aws:kms:us-east-1:123456789012:key/1234-5678'

C.s3:x-amz-acl with value 'bucket-owner-full-control'

D.aws:SourceArn with value the bucket ARN

AnswerB

The `s3:x-amz-server-side-encryption-aws-kms-key-id` condition directly enforces the use of a specific AWS KMS key by comparing its ARN against the value provided in the S3 PUT object request header. This precise condition ensures that only objects encrypted with the designated customer-managed key (CMK) are successfully uploaded to the bucket. It provides the granular control necessary to meet strict compliance requirements for sensitive data, ensuring data at rest is secured with an auditable, pre-approved key.

Why this answer

The condition key `s3:x-amz-server-side-encryption-aws-kms-key-id` allows you to enforce that a specific customer-managed AWS KMS key (identified by its full ARN) is used for server-side encryption. By denying PutObject requests that do not match this key ID, the security team ensures all uploaded objects are encrypted at rest with the required KMS key.

Exam trap

The trap here is that candidates often confuse `s3:x-amz-server-side-encryption` (which only checks if SSE-KMS is enabled) with `s3:x-amz-server-side-encryption-aws-kms-key-id` (which checks the specific key ID), leading them to pick Option A, which does not enforce the required customer-managed key.

How to eliminate wrong answers

Option A is wrong because `s3:x-amz-server-side-encryption` with value `aws:kms` only enforces that SSE-KMS is used, but does not restrict which KMS key is used; any KMS key (including default AWS-managed keys) would satisfy the condition. Option C is wrong because `s3:x-amz-acl` with value `bucket-owner-full-control` controls access permissions via ACLs, not encryption requirements, and is irrelevant to enforcing encryption key usage. Option D is wrong because `aws:SourceArn` is used to restrict requests based on the source ARN (e.g., to prevent cross-service confused deputy attacks), not to enforce encryption key selection.

Full explanation →

935

Multi-Selecteasy

Which TWO of the following are best practices for securing AWS account root user?

Select 2 answers

A.Delete the root user access keys.

B.Use the root user for daily administrative tasks.

C.Set a password policy that locks the root user after 10 failed attempts.

D.Share the root user password with senior developers for emergencies.

E.Enable multi-factor authentication (MFA) for the root user.

AnswersA, E

Root user access keys are permanent long-term credentials with unrestricted privileges across the account, including billing and even account closure. They cannot be constrained by IAM policies or permission boundaries, so if they are compromised, the attacker gains full control without any possibility of mitigating the scope. AWS best practice is to never create root access keys, and if they already exist, delete them immediately and rely on password plus MFA for the rare root sign-in.

Why this answer

Option A is correct because AWS best practice is to remove (delete) any access keys associated with the root user, since long-term programmatic credentials on the root account pose a severe risk if leaked and root should not be used for API/CLI access. Option E is correct because enabling MFA on the root user adds a critical second authentication factor, protecting the account from password compromise and required for sensitive root-only operations. Options B, C, and D are not best practices: the root user should not be used for daily administrative tasks (use IAM users/roles instead), AWS does not provide an account-level password policy that locks the root user after failed attempts, and sharing the root password with developers violates least privilege and accountability.

Exam trap

DVA-C02 often tests the misconception that the root user should be used for convenience or that IAM password policies apply to it — candidates must remember the root user is special-cased and should be locked down, not used.

Full explanation →

936

MCQhard

A company uses AWS Lambda functions behind an API Gateway REST API. The Lambda functions are written in Python and use the boto3 SDK to interact with DynamoDB. After a recent deployment, some users report sporadic 502 Bad Gateway errors when calling the API. The Lambda function logs show occasional 'AccessDeniedException' errors. What is the most likely cause and solution?

A.The Lambda function is timing out. Increase the timeout value in the Lambda configuration.

B.The DynamoDB table is throttling requests. Enable auto-scaling for the table.

C.The Lambda execution role lacks permissions to access DynamoDB. Update the role to include the necessary DynamoDB actions.

D.The API Gateway request is too large. Set the payload size limit higher in API Gateway settings.

AnswerC

An "AccessDeniedException" from DynamoDB, when invoked by a Lambda function, unequivocally indicates that the Lambda function's IAM execution role does not possess the required permissions to perform the requested DynamoDB actions. Granting specific DynamoDB permissions, such as "dynamodb:GetItem" or "dynamodb:PutItem", to the Lambda's execution role will resolve this authorization error, allowing the function to interact with the table successfully.

Why this answer

The 'AccessDeniedException' error in the Lambda logs indicates that the Lambda function's execution role does not have the necessary IAM permissions to perform the requested DynamoDB operation. This is a common misconfiguration after deployments where the role or its attached policies are not updated to include the required DynamoDB actions (e.g., dynamodb:GetItem, dynamodb:PutItem). The 502 Bad Gateway from API Gateway is a direct consequence of the Lambda function failing internally due to this permission error.

Exam trap

The trap here is that candidates often confuse 'AccessDeniedException' with throttling or timeout errors, but the specific error message in the logs directly points to an IAM permissions issue, not a capacity or performance problem.

How to eliminate wrong answers

Option A is wrong because a timeout would produce a 'Task timed out' error in the logs, not an 'AccessDeniedException'. Option B is wrong because throttling from DynamoDB would result in 'ProvisionedThroughputExceededException' errors, not 'AccessDeniedException'. Option D is wrong because a request payload size issue would cause a '413 Request Entity Too Large' error from API Gateway, not a 502 Bad Gateway, and the Lambda logs would not show an 'AccessDeniedException'.

Full explanation →

937

MCQhard

A company has a multi-account architecture using AWS Organizations. The security team wants to centrally manage IAM policies that apply to all accounts. Which AWS feature should the developer use?

A.Service control policies (SCPs) in AWS Organizations.

B.IAM cross-account roles.

C.AWS Config conformance packs.

D.IAM policies attached to the root user.

AnswerA

Service Control Policies (SCPs) in AWS Organizations are powerful guardrails that define the maximum available permissions for accounts, Organizational Units (OUs), or the entire organization. They do not grant permissions themselves but filter the permissions that IAM policies can grant, effectively restricting actions across all affected accounts centrally. This centralized enforcement mechanism is ideal for establishing and maintaining security and compliance standards across a multi-account architecture, ensuring no account can exceed the defined boundaries.

Why this answer

Service control policies (SCPs) in AWS Organizations are the only feature that lets you centrally define and enforce permission guardrails across every account in the organization. SCPs are attached at the OU or account level and define the maximum permissions available to IAM principals in member accounts, so a single policy change propagates to all accounts. This directly satisfies the requirement to 'centrally manage IAM policies that apply to all accounts.'

Exam trap

DVA-C02 often tests the misconception that IAM policies or cross-account roles can centrally govern all accounts, when in fact only SCPs in AWS Organizations provide organization-wide permission guardrails.

How to eliminate wrong answers

Option B is wrong because IAM cross-account roles only grant access between specific accounts and do not centrally enforce or manage policies across the entire organization. Option C is wrong because AWS Config conformance packs are used for compliance assessment and reporting against configuration rules, not for centrally managing or enforcing IAM permissions. Option D is wrong because IAM policies attached to a root user apply only to that single account's root user and cannot be used to govern all accounts in an organization.

Full explanation →

938

MCQmedium

A developer is deploying a new version of an AWS Lambda function. The function uses an environment variable for a database password. The developer wants to securely store the password and automatically rotate it. Which combination of AWS services should the developer use?

A.Use AWS KMS to generate a data key and store it in the Lambda environment variable.

B.Store the password in AWS Secrets Manager and retrieve it in the Lambda function using the AWS SDK.

C.Store the password in AWS Systems Manager Parameter Store and reference it in the Lambda function.

D.Encrypt the password using AWS KMS and store it in Amazon DynamoDB.

AnswerB

AWS Secrets Manager is the most appropriate and secure solution for storing and retrieving sensitive credentials like passwords in Lambda functions. It is purpose-built for secret management, offering features such as automatic rotation of secrets, fine-grained access control, and comprehensive auditing. Lambda functions can securely retrieve these secrets at runtime using the AWS SDK, ensuring credentials are never hardcoded or exposed in environment variables.

Why this answer

AWS Secrets Manager is specifically designed to securely store secrets like database passwords, supports automatic rotation of secrets, and integrates with Lambda via the AWS SDK to retrieve the secret at runtime. This ensures the password is never hardcoded or exposed in environment variables, and rotation can be scheduled without code changes.

Exam trap

The trap here is that candidates may confuse Parameter Store (Option C) with Secrets Manager, but Parameter Store lacks built-in automatic rotation, which is explicitly required in the question, making Secrets Manager the only correct choice.

How to eliminate wrong answers

Option A is wrong because AWS KMS generates data keys for encryption, not for storing secrets, and storing a data key in an environment variable does not provide automatic rotation or secure secret management. Option C is wrong because AWS Systems Manager Parameter Store can store passwords but does not natively support automatic rotation of secrets; it requires custom solutions or integration with Secrets Manager for rotation. Option D is wrong because storing an encrypted password in DynamoDB adds unnecessary complexity, does not provide automatic rotation, and requires custom encryption/decryption logic, whereas Secrets Manager handles both securely.

Full explanation →

939

MCQhard

A developer is troubleshooting an IAM policy that is supposed to allow a Lambda function to read objects from an S3 bucket. The Lambda function role has the following policy attached: {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:GetObject","s3:ListBucket"],"Resource":["arn:aws:s3:::example-bucket/*","arn:aws:s3:::example-bucket"]}]}. Despite this, the Lambda function receives an AccessDenied error when trying to read objects. What is the most likely cause?

A.The S3 bucket has a bucket policy that explicitly denies the Lambda function's access.

B.The IAM policy does not include the s3:GetObjectVersion action.

C.The Lambda function is in a different AWS account than the S3 bucket.

D.The IAM policy uses an incorrect resource ARN format.

AnswerA

AWS IAM policy evaluation logic dictates that an explicit deny in any applicable policy always overrides an explicit allow. Even if the Lambda function's execution role has an IAM policy granting s3:GetObject access, a bucket policy on the target S3 bucket that explicitly denies access to that specific Lambda role will prevent the action. This creates an effective deny, regardless of the identity-based policy, making it the most probable cause for troubleshooting.

Why this answer

The IAM policy attached to the Lambda function role correctly grants s3:GetObject and s3:ListBucket permissions on the bucket and its objects. However, if the S3 bucket itself has a bucket policy that explicitly denies access to the Lambda function's role, that explicit deny overrides any allow from IAM policies, resulting in an AccessDenied error. This is because AWS evaluates all policies (identity-based and resource-based) and an explicit deny always takes precedence.

Exam trap

The trap here is that candidates often assume the IAM policy alone is sufficient and overlook the possibility of a bucket policy that explicitly denies access, which overrides any IAM allow.

How to eliminate wrong answers

Option B is wrong because the s3:GetObjectVersion action is only needed when accessing a specific version of an object using version ID; the error occurs on a standard read, which only requires s3:GetObject. Option C is wrong because cross-account access would still work if the bucket policy grants access to the Lambda function's role; the error is not inherently caused by being in a different account. Option D is wrong because the resource ARN format is correct: 'arn:aws:s3:::example-bucket/*' for objects and 'arn:aws:s3:::example-bucket' for the bucket itself, which is the standard format for S3 ARNs.

Full explanation →

940

MCQmedium

A developer is troubleshooting a Lambda function that intermittently times out. The function makes HTTP requests to an external API. The function's CloudWatch logs show 'Task timed out after 3.01 seconds'. What is the MOST likely cause?

A.The Lambda function timeout is set to 3 seconds, but the HTTP request takes longer.

B.The Lambda function has insufficient reserved concurrency causing throttling.

C.The Lambda function is not configured with a VPC and cannot reach the external API.

D.The Lambda function is not starting execution due to a missing IAM role.

AnswerA

The default timeout for an AWS Lambda function is indeed 3 seconds. When an HTTP request or any other operation within the function exceeds this configured duration, Lambda forcefully terminates the execution, logging a 'Task timed out' error. The log showing 3.01 seconds precisely indicates that the function was terminated just after exceeding its allowed execution time, making the long-running HTTP request the root cause of the observed timeout.

Why this answer

The Lambda function timeout is set to 3 seconds, and the HTTP request to the external API takes longer than that, causing the 'Task timed out after 3.01 seconds' error. Option B is incorrect because throttling due to insufficient reserved concurrency would result in a 'Rate exceeded' error, not a timeout. Option C is incorrect because if the function couldn't reach the external API due to VPC configuration, it would result in a connection error, not a timeout.

Option D is incorrect because a missing IAM role would prevent the function from executing at all, and the logs show the function started execution.

Full explanation →

941

Multi-Selecteasy

Which TWO of the following are benefits of using Amazon API Gateway to manage APIs? (Choose two.)

Select 2 answers

A.Built-in caching of database queries to Amazon RDS

B.Direct integration with Amazon S3 for file storage

C.Throttling and rate limiting of API requests

D.Generation of client SDKs for multiple programming languages

E.Automatic connection pooling for backend databases

AnswersC, D

Amazon API Gateway provides robust capabilities for throttling and rate limiting API requests, which is crucial for protecting backend services from being overwhelmed and ensuring fair usage among consumers. You can configure global request limits, burst limits, and even define usage plans with specific quotas and throttles per API key. This prevents denial-of-service attacks and maintains API stability under high load.

Why this answer

Option C is correct because API Gateway provides built-in throttling and rate limiting through usage plans and API keys, allowing you to control request rates per client and protect backend services from being overwhelmed. Option D is correct because API Gateway can automatically generate client SDKs for multiple programming languages (such as Java, JavaScript, Python, and iOS/Android) from an API's definition, simplifying client integration. Option A is not a feature of API Gateway, which does not cache database queries to Amazon RDS; it can cache API responses at the stage level, but not RDS queries.

Option B is inaccurate as a benefit of API Gateway itself, since API Gateway can proxy to S3 but does not provide direct S3 file storage management as a core API management benefit. Option E is incorrect because automatic connection pooling for backend databases is handled by services like Amazon RDS Proxy, not API Gateway.

Exam trap

The trap here is that candidates confuse API Gateway's integration capabilities (e.g., proxying to S3 or RDS) with built-in backend features like caching or connection pooling, leading them to select options that describe backend functionality rather than API management features.

Full explanation →

942

Multi-Selecteasy

Which TWO actions are required to enable server-side encryption for an Amazon RDS instance? (Choose 2)

Select 2 answers

A.Enable encryption on the database after creation

B.Use client-side encryption in the application

C.Configure the DB instance to use a VPC

D.Use AWS KMS to manage the encryption key

E.Specify encryption at rest when creating the DB instance

AnswersD, E

Amazon RDS server-side encryption is built on AWS KMS; you must select a customer master key (CMK) when enabling encryption at rest. The KMS key encrypts the database storage, automated snapshots, and read replicas through envelope encryption, and RDS uses the key to encrypt the data key that protects the volume. Without specifying a KMS key, the encryption option cannot be applied, making KMS key management an essential part of the required configuration.

Why this answer

Option D is correct because Amazon RDS encryption at rest is implemented using AWS Key Management Service (KMS) customer master keys (CMKs), so you must use AWS KMS to manage the encryption key that protects the DB instance's storage and snapshots. Option E is correct because RDS encryption at rest can only be enabled at the moment of DB instance creation (via the console, CLI --storage-encrypted, or API StorageEncrypted=true); you cannot turn it on afterward. Option A is wrong because an existing unencrypted RDS instance cannot simply have encryption enabled after creation—you must create a new encrypted instance from a snapshot.

Option B is wrong because client-side encryption is an application-level concern and does not enable RDS server-side encryption at rest. Option C is wrong because placing the DB instance in a VPC is a networking configuration and has no bearing on enabling storage encryption.

Exam trap

DVA-C02 often tests the immutability of RDS encryption — candidates pick 'enable encryption after creation' because they assume it is a toggleable setting like in some other services, but RDS requires encryption at creation time.

Full explanation →

943

MCQmedium

A developer needs to prevent accidental public access to all S3 buckets in an account. Which account-level control should be enabled?

A.S3 Transfer Acceleration

B.S3 Block Public Access

C.S3 Inventory

D.S3 Object Lambda

AnswerB

S3 Block Public Access is the correct and most effective service for preventing accidental public access to S3 buckets and objects across an entire AWS account or specific buckets. It offers four distinct settings that can be applied at the account or bucket level: blocking new public ACLs, ignoring existing public ACLs, blocking new public bucket policies, and blocking public and cross-account access to buckets with public policies. These controls override other access configurations, ensuring strong protection against unintended public exposure.

Why this answer

S3 Block Public Access is an account-level control that provides a centralized way to enforce that no S3 buckets or objects in the account can be made publicly accessible, regardless of individual bucket policies or ACLs. This setting overrides any bucket-level public access settings, effectively preventing accidental exposure of data to the internet.

Exam trap

The trap here is that candidates may confuse bucket-level controls (like bucket policies or ACLs) with account-level controls, or mistakenly think features like Transfer Acceleration or Inventory provide security, when only S3 Block Public Access offers a centralized, account-wide safeguard against public exposure.

How to eliminate wrong answers

Option A is wrong because S3 Transfer Acceleration is a feature that speeds up uploads over long distances using AWS edge locations, not a security control for preventing public access. Option C is wrong because S3 Inventory is used to generate reports on object metadata and replication status for auditing and compliance, not to block public access. Option D is wrong because S3 Object Lambda allows you to add custom code to process data during S3 GET, HEAD, and LIST requests, but it does not provide any access control or public access blocking functionality.

Full explanation →

944

Multi-Selectmedium

A developer is designing a serverless application that processes orders. The order processing must be transactional: either all steps succeed or none. Which TWO AWS services can be combined to achieve this?

Select 2 answers

A.AWS Step Functions

B.Amazon SNS with filtering

C.Amazon SQS with FIFO queues

D.Amazon DynamoDB transactions

E.AWS Lambda with DLQ

AnswersA, D

AWS Step Functions is a powerful orchestration service that enables developers to define and execute complex, multi-step serverless workflows as state machines. It inherently supports error handling, retries, and parallel execution, making it ideal for coordinating multiple AWS services to achieve transactional-like behavior. By managing the state between steps and allowing for explicit success and failure paths, including compensating actions, Step Functions can ensure that a series of operations either completes entirely or is rolled back to a consistent state, effectively providing atomicity across distributed components.

Why this answer

AWS Step Functions is correct because it provides a state machine that can coordinate multiple AWS services (e.g., Lambda, DynamoDB) in a defined workflow. It supports error handling, retries, and a 'catch' mechanism to roll back or compensate for failed steps, enabling transactional order processing where all steps succeed or none do.

Exam trap

The trap here is that candidates often confuse message ordering or delivery guarantees (SQS FIFO) with transactional orchestration, failing to recognize that Step Functions is needed for coordinating multi-step rollback logic.

Full explanation →

945

MCQhard

A company uses AWS Secrets Manager to rotate database credentials for an RDS MySQL instance. The rotation Lambda function fails with the error: 'Secret is scheduled for deletion.' What is the MOST likely cause?

A.The secret has been marked for deletion and is in the waiting period.

B.The secret's rotation schedule has been disabled.

C.The Lambda function does not have permission to access the secret.

D.The RDS instance is not in the same VPC as the Lambda function.

AnswerA

When a secret in AWS Secrets Manager is marked for deletion, it enters a configurable waiting period (3 to 30 days) before permanent removal. During this period, the secret is effectively read-only and cannot be modified, including initiating a rotation. Any attempt to rotate a secret in this state will fail, as Secrets Manager prevents operations that would alter a secret designated for deletion, ensuring data integrity before its final removal. This specific state directly causes rotation failures.

Why this answer

The error 'Secret is scheduled for deletion' indicates that the secret has been marked for deletion and is currently in the mandatory waiting period (default 7 to 30 days). During this period, AWS Secrets Manager prevents any operations on the secret, including rotation, to ensure the deletion is intentional. The rotation Lambda function fails because it cannot access or modify a secret that is pending deletion.

Exam trap

The trap here is that candidates may confuse the 'scheduled for deletion' error with a permissions or network issue, but the error message directly points to the secret's lifecycle state, which is a distinct concept in AWS Secrets Manager.

How to eliminate wrong answers

Option B is wrong because disabling the rotation schedule would prevent the Lambda function from being triggered, but it would not cause a 'Secret is scheduled for deletion' error; the secret would still be accessible. Option C is wrong because a permissions issue would result in an 'AccessDeniedException' or similar authorization error, not a deletion-specific error message. Option D is wrong because VPC mismatch would cause a network timeout or connectivity error, not a deletion-related error; the Lambda function would still be able to call the Secrets Manager API if network access is configured.

Full explanation →

946

MCQhard

An organization uses AWS Lambda functions behind an Amazon API Gateway REST API. They want to deploy a new version of the Lambda function using canary deployments. What is the recommended approach?

A.Use AWS CodeDeploy to create a canary deployment for the Lambda function.

B.Use API Gateway canary release deployment to shift traffic to the new Lambda version.

C.Deploy the new Lambda version using AWS SAM with AutoPublishAlias and DeploymentPreference.

D.Configure the Lambda function alias with traffic shifting using weights.

AnswerC

While AWS SAM's AutoPublishAlias and DeploymentPreference properties can automate the creation of Lambda aliases and integrate with AWS CodeDeploy for controlled deployments, this option describes an orchestration tool rather than the direct mechanism for traffic shifting. CodeDeploy, when used with SAM, manages the *process* of shifting traffic between Lambda aliases by updating the alias configuration over time. However, the question asks for the specific Lambda feature that enables traffic shifting, not the deployment pipeline that orchestrates it.

Why this answer

AWS SAM (Serverless Application Model) provides built-in support for safe Lambda deployments. By defining the `AutoPublishAlias` and `DeploymentPreference` (such as `Canary10Percent10Minutes`) in the SAM template, AWS SAM automatically configures AWS CodeDeploy to gradually shift traffic to the new Lambda version. It also monitors CloudWatch alarms and automatically rolls back if any errors are detected, making it the recommended and most robust approach.

Exam trap

Candidates often get confused between manual Lambda alias traffic shifting (Option D) and automated canary deployments. While you can manually adjust alias weights, it is not the recommended approach for deployments because it lacks automated rollback capabilities. AWS SAM with DeploymentPreference (Option C) is the standard AWS-recommended best practice.

How to eliminate wrong answers

Option A is wrong because AWS CodeDeploy can orchestrate canary deployments for Lambda, but it is not the recommended approach when using API Gateway; the question asks for the recommended approach, and native Lambda alias traffic shifting is simpler and more direct. Option B is wrong because API Gateway canary release deployments shift traffic between API stages (e.g., prod vs. canary), not between Lambda function versions; the canary is at the API level, not the Lambda function level. Option C is wrong because AWS SAM with AutoPublishAlias and DeploymentPreference is a valid method for canary deployments, but it is a framework-level abstraction that ultimately configures Lambda alias traffic shifting under the hood; the question asks for the recommended approach, and the native, direct method is configuring the alias with weights.

Full explanation →

947

MCQmedium

A company uses Amazon CloudFront to distribute content from an S3 bucket. The content is static and rarely changes. The developer wants to reduce the load on the origin and improve performance for users. Which configuration change would achieve this?

A.Disable caching for the distribution.

B.Enable Lambda@Edge to process requests at edge locations.

C.Decrease the TTL (Time to Live) for the cache behavior.

D.Increase the TTL (Time to Live) for the cache behavior.

AnswerD

Increasing the TTL (Time to Live) for a cache behavior allows CloudFront to serve objects directly from its edge caches for a longer period before needing to revalidate or fetch them from the origin. This significantly improves the cache hit ratio, meaning more requests are served directly from the edge, which drastically reduces the number of requests reaching the origin server and lowers its operational load.

Why this answer

Increasing the TTL for the cache behavior tells CloudFront edge locations to retain cached copies of the static content for a longer period before re-validating with the origin S3 bucket. This reduces the number of requests that reach the origin, lowering load on the S3 bucket, and improves user performance by serving content directly from the edge cache more frequently.

Exam trap

The trap here is that candidates often confuse decreasing TTL with improving freshness, but for static, rarely changing content, a longer TTL reduces origin load and improves performance, not a shorter one.

How to eliminate wrong answers

Option A is wrong because disabling caching would force every request to go to the origin S3 bucket, increasing load and degrading performance, which is the opposite of the desired outcome. Option B is wrong because Lambda@Edge is used for custom logic at edge locations (e.g., authentication, header manipulation) and does not directly reduce origin load or improve caching for static, rarely changing content. Option C is wrong because decreasing the TTL causes CloudFront to re-validate content with the origin more often, increasing origin requests and latency, which contradicts the goal of reducing load and improving performance.

Full explanation →

948

MCQeasy

A company uses AWS Elastic Beanstalk to run a web application. They want to deploy a new version with zero downtime. They have a production environment running the current version and a staging environment running the new version. After thoroughly testing the staging environment, they want to swap the URLs so that production now points to the new version. Which deployment strategy should they use?

A.Blue/green deployment with CNAME swap

B.Rolling deployment

C.Immutable deployment

D.All at once deployment

AnswerA

Swapping the environment CNAMEs redirects production traffic to the already-tested staging environment instantly, so the old version stays live until the switch. This satisfies the zero-downtime constraint without redeploying, since both environments run concurrently and DNS cutover avoids in-place instance restarts.

Why this answer

Blue/green deployment with a CNAME swap is the correct strategy because it allows you to run two identical environments (blue = current production, green = new version) and switch traffic atomically by updating the DNS CNAME record. This achieves zero downtime since the production environment remains active until the swap is complete, and the staging environment has been fully tested. Elastic Beanstalk supports this by letting you perform a CNAME swap between environments via the console, CLI, or API.

Exam trap

The trap here is that candidates confuse blue/green deployment with immutable deployment, but immutable deployment does not allow you to maintain a separate staging environment for testing before the swap; it only replaces instances in the same environment.

How to eliminate wrong answers

Option B (Rolling deployment) is wrong because it updates instances in batches within the same environment, which can cause temporary capacity reduction and potential downtime if the new version has issues. Option C (Immutable deployment) is wrong because it launches a new Auto Scaling group with the new version, then swaps instances, but it does not allow you to pre-test the new version in a separate staging environment before traffic is routed. Option D (All at once deployment) is wrong because it deploys the new version to all instances simultaneously, causing downtime during the deployment process and no ability to test the new version in isolation.

Full explanation →

949

Multi-Selectmedium

A company is running a web application on EC2 instances behind an Application Load Balancer. The application experiences high latency during peak hours. A developer needs to improve performance. Which TWO actions should the developer take? (Choose TWO.)

Select 2 answers

A.Configure Auto Scaling to add more instances during peak hours.

B.Increase the ALB idle timeout.

C.Implement Amazon ElastiCache to cache frequently accessed data.

D.Use larger EC2 instance types.

E.Enable EBS optimization on the instances.

AnswersA, C

Configuring Auto Scaling allows the web application to dynamically adjust its capacity by launching additional EC2 instances when demand increases, such as during peak hours. This horizontal scaling approach ensures that the application maintains responsiveness and high availability by distributing the load across more resources, effectively preventing performance degradation and latency spikes. It automatically scales out to meet demand and scales in to optimize costs.

Why this answer

Option A is correct because configuring Auto Scaling to add more instances during peak hours horizontally scales the compute capacity behind the Application Load Balancer, distributing the increased request load across more targets and directly reducing the per-instance latency caused by peak traffic. Option C is correct because implementing Amazon ElastiCache (Redis or Memcached) offloads repeated reads of frequently accessed data from the backend instances and any database, cutting response times and reducing the load that contributes to high latency during peaks. Option B is not appropriate because increasing the ALB idle timeout only affects how long idle connections are kept open and does not improve application response latency.

Option D is not the best fit because vertically scaling with larger instance types is a single-instance change that does not address load distribution and is less elastic than Auto Scaling. Option E is incorrect because EBS optimization improves storage throughput/IOPS consistency for EBS-backed volumes, not the application's peak-hour latency driven by request load.

Exam trap

The trap here is that candidates often confuse vertical scaling (larger instances) with horizontal scaling (Auto Scaling), or think that increasing timeouts or enabling EBS optimization will fix application-level latency issues.

Full explanation →

950

MCQmedium

A developer is building a RESTful API using Amazon API Gateway (REST API) and AWS Lambda. The API receives a large number of requests with duplicate payloads within a short time window. To improve performance and reduce costs, the developer wants to ensure that if the same request (based on a unique client ID) is sent within 5 minutes, the Lambda function is not invoked again, and the previously calculated response is returned. Which API Gateway feature should the developer use?

A.Enable API caching on the stage with a TTL of 300 seconds and configure the client ID as a cache key parameter.

B.Enable request validation to reject duplicate requests.

C.Configure a usage plan with a throttle rate to limit requests from each client.

D.Enable stage variables to store the previous response.

AnswerA

API Gateway's built-in caching mechanism is exclusively available for REST APIs, not HTTP APIs. While enabling caching on a stage with a specified TTL and using a client ID as a cache key parameter is a valid strategy for optimizing REST API performance and reducing backend load, this functionality is simply not supported for HTTP APIs. Therefore, this option cannot be implemented for the API type specified in the question, rendering it ineffective for the stated goal.

Why this answer

Amazon API Gateway (REST API) supports response caching at the stage level. By enabling API caching with a TTL of 300 seconds (5 minutes) and specifying the client ID as a cache key parameter, identical requests with the same client ID within the TTL will return the cached response without invoking the Lambda function. This reduces latency and cost.

Exam trap

Candidates might confuse this with HTTP APIs, which do not support native caching. The question specifies a REST API, making caching a valid feature. Also, ensure the cache key is configured correctly to avoid returning incorrect cached responses.

How to eliminate wrong answers

Option B is wrong because request validation in API Gateway checks for required headers, query strings, or body structure, but it does not detect or reject duplicate requests based on content or client ID. Option C is wrong because a usage plan with throttling limits the rate of requests per client (e.g., requests per second), but it does not cache responses or prevent Lambda invocation for duplicate requests within a time window; it simply rejects excess requests. Option D is wrong because stage variables are used to pass configuration values (like endpoint URLs) to integration functions at deployment time, not to store or return previous responses.

Full explanation →

951

MCQhard

Refer to the exhibit. An IAM policy is attached to a user who needs to deploy a serverless application. The user reports that they cannot upload a new version of a Lambda function using the AWS CLI. What is the MOST likely reason?

A.The Lambda invoke permission is scoped to a specific function.

B.The policy does not include lambda:UpdateFunctionCode.

C.The user does not have permission to write to the S3 bucket.

D.The user is not in the same AWS region as the Lambda function.

AnswerB

To modify the deployment package or code of an existing AWS Lambda function, an IAM principal requires the `lambda:UpdateFunctionCode` action to be explicitly allowed in their attached policy. Since the provided policy document does not list `lambda:UpdateFunctionCode` among its allowed actions, the user lacks the necessary permission to perform this specific administrative operation. This correctly identifies a missing capability for code updates.

Why this answer

The error occurs because the IAM policy attached to the user does not include the `lambda:UpdateFunctionCode` permission, which is required to upload a new version of a Lambda function via the AWS CLI. Without this action, the `update-function-code` command fails, even if other Lambda permissions like `lambda:InvokeFunction` are present. The policy must explicitly allow `lambda:UpdateFunctionCode` to enable code updates.

Exam trap

The trap here is that candidates assume the error is due to S3 permissions (Option C) because they think Lambda code must be uploaded from S3, but the CLI can upload directly from a local file, and the real missing permission is `lambda:UpdateFunctionCode`.

How to eliminate wrong answers

Option A is wrong because `lambda:InvokeFunction` permission scoped to a specific function does not affect the ability to upload code; it only controls invocation access. Option C is wrong because the error is about uploading a new Lambda function version, not about writing to an S3 bucket; the CLI command `update-function-code` can accept a zip file directly without S3. Option D is wrong because AWS CLI operations for Lambda are region-scoped by the user's configuration, not by IAM policy; the user can specify the region via `--region` flag or config, and the policy does not restrict regions.

Full explanation →

952

MCQhard

A developer is deploying a microservices application on Amazon ECS with the Fargate launch type. The application uses an Application Load Balancer (ALB) to route traffic. The developer wants to perform a blue/green deployment with automated traffic shifting using AWS CodeDeploy. What is the minimum number of target groups required for this deployment?

A.One

B.Two

C.Three

D.Four

AnswerB

For a successful blue/green deployment with AWS CodeDeploy and ECS, two distinct target groups are essential. One target group is initially associated with the "blue" (current production) task set, while the second target group is associated with the "green" (new version) task set. AWS CodeDeploy orchestrates the traffic shift by updating the listener rules on the Application Load Balancer (ALB) to gradually or instantly direct traffic from the blue target group to the green target group. This setup facilitates seamless cutovers and provides a straightforward rollback mechanism.

Why this answer

In a blue/green deployment with AWS CodeDeploy and an Application Load Balancer (ALB) on Amazon ECS (Fargate), two target groups are required: one for the 'blue' (current) environment and one for the 'green' (new) environment. CodeDeploy shifts traffic from the blue target group to the green target group by updating the ALB listener rules, allowing zero-downtime deployments and automated rollback if needed.

Exam trap

The trap here is that candidates often confuse blue/green deployments with canary deployments or assume that a single target group with multiple ports can serve both environments, but AWS CodeDeploy for ECS explicitly requires two distinct target groups to manage traffic shifting and rollback.

How to eliminate wrong answers

Option A is wrong because a single target group cannot differentiate between the blue and green environments; traffic shifting requires two separate target groups to route traffic to the old and new task sets independently. Option C is wrong because three target groups are unnecessary; the blue/green deployment model only needs one target group for each environment (two total), and no additional target group is required for the ALB listener. Option D is wrong because four target groups are excessive; the deployment does not require any extra target groups beyond the two used for blue and green.

Full explanation →

953

MCQhard

Refer to the exhibit. An IAM policy is attached to a user. The user tries to download an object from s3://my-bucket/secret/config.txt. What will happen?

A.The user is denied access only if the bucket policy also denies access.

B.The user can download the object because the Deny statement only applies to 's3:*' actions, not s3:GetObject.

C.The user can download the object because the Allow statement grants s3:GetObject on the bucket.

D.The user is denied access because the Deny statement explicitly denies access to the 'secret/' prefix.

AnswerD

The policy's Deny statement denies all s3 actions on the ARN arn:aws:s3:::bucket/secret/*, which matches the requested object in the 'secret/' prefix. An explicit deny always overrides any allow, including the separate Allow statement granting s3:GetObject on the bucket. Therefore, the user is denied access to that object, and this is the correct interpretation of the policy evaluation outcome.

Why this answer

The Deny statement explicitly denies all s3 actions on the 'secret/' prefix. Deny statements override Allow statements. Therefore, the user is denied access to objects under the 'secret/' prefix, including s3://my-bucket/secret/config.txt.

Option D is correct. Option A is incorrect because the explicit Deny overrides any bucket policy allow. Option B is incorrect because the Deny applies to all s3 actions, including s3:GetObject, and is scoped to the 'secret/' prefix.

Option C is incorrect because the Allow statement does not grant access to the 'secret/' prefix; the Deny overrides it.

Full explanation →

954

MCQhard

A company has a multi-account AWS environment using AWS Organizations. The security team wants to enforce that all S3 buckets across all accounts are encrypted using SSE-KMS with a specific KMS key from the central security account. They also want to prevent any unencrypted bucket creation. A developer in the development account creates a new S3 bucket and enables default encryption using SSE-S3. The bucket creation succeeds, but the security team wants to prevent this. The developer argues that the bucket still encrypts data at rest. Compliance requires SSE-KMS only. What should the security team do to enforce this policy across all accounts?

A.Create an IAM policy in the central security account that denies s3:PutBucketEncryption if the encryption is not SSE-KMS.

B.Use AWS Config to detect non-compliant buckets and automatically apply default encryption with SSE-KMS.

C.Enable CloudTrail to log all S3 API calls and manually review for non-compliant buckets.

D.Create a service control policy (SCP) that denies s3:PutObject and s3:PutBucketEncryption unless the encryption is SSE-KMS with the specific KMS key.

AnswerD

Service Control Policies (SCPs) are a feature of AWS Organizations that allow central management of permissions across all accounts in the organization. An SCP can explicitly deny actions like `s3:PutObject` and `s3:PutBucketEncryption` unless specific conditions, such as the use of SSE-KMS with a designated KMS key, are met. This provides proactive, preventative enforcement at the organizational level, ensuring compliance before resources are created or modified.

Why this answer

A service control policy (SCP) applied at the AWS Organizations root or OU level can centrally deny S3 bucket creation and encryption configuration unless SSE-KMS with the specific KMS key is used. SCPs affect all accounts in the organization, preventing developers from bypassing the policy by creating buckets with SSE-S3, as the SCP condition key `s3:x-amz-server-side-encryption` and `s3:x-amz-server-side-encryption-aws-kms-key-id` enforce the required encryption at the API level before the bucket is created.

Exam trap

The trap here is that candidates often confuse IAM policies (which are account-scoped) with SCPs (which are organization-wide), and assume that AWS Config remediation or CloudTrail can proactively enforce encryption, when in fact only SCPs can deny the API call at the point of creation across all accounts.

How to eliminate wrong answers

Option A is wrong because an IAM policy in the central security account only applies to principals in that account, not to developers in other accounts, and cannot prevent bucket creation across the organization. Option B is wrong because AWS Config can detect non-compliant buckets and trigger remediation (e.g., via Lambda), but it is reactive—it does not prevent the initial creation of an unencrypted bucket, which the security team explicitly wants to block. Option C is wrong because CloudTrail logging only provides auditing after the fact, not proactive enforcement; manual review is impractical and does not prevent non-compliant bucket creation.

Full explanation →

955

MCQmedium

A developer is building a serverless application that processes user-submitted images. The images are uploaded to an S3 bucket, which triggers an AWS Lambda function that creates a thumbnail and stores it in another S3 bucket. The developer notices that sometimes the Lambda function is invoked multiple times for a single image upload. What should the developer configure to ensure idempotent processing?

A.Enable S3 event notifications with a suffix filter.

B.Use an SQS queue to decouple S3 events.

C.Implement a DynamoDB table to track processed objects.

D.Increase the Lambda function's timeout.

AnswerC

Implementing a DynamoDB table to store identifiers of successfully processed objects (e.g., S3 object key and version ID) is an effective strategy for achieving idempotency. Before processing an S3 event, the Lambda function can attempt to write the object's unique identifier to the DynamoDB table with a `ConditionExpression` that ensures the item does not already exist. If the write fails because the item is already present, it indicates a duplicate event, and the function can safely exit without reprocessing, thus preventing unintended side effects.

Why this answer

S3 event notifications can occasionally deliver duplicate events (at-least-once semantics). By storing the unique object key (or ETag) in a DynamoDB table with a TTL, the Lambda function can check if the object has already been processed and skip duplicate invocations, ensuring idempotent processing.

Exam trap

The trap here is that candidates often assume SQS or filters guarantee exactly-once delivery, but AWS services like S3 and SQS both use at-least-once semantics, so idempotency must be implemented at the consumer level.

How to eliminate wrong answers

Option A is wrong because suffix filters only control which objects trigger notifications based on file extension; they do not prevent duplicate invocations for the same object. Option B is wrong because while an SQS queue can buffer events and reduce throttling, it does not eliminate duplicate events—S3 still sends at-least-once notifications to SQS, so duplicates can still occur. Option D is wrong because increasing the Lambda timeout only allows the function to run longer; it does not address the root cause of duplicate invocations or provide idempotency.

Full explanation →

956

MCQmedium

A developer uses AWS CodeBuild to run unit tests. The build succeeds but the tests fail. The developer wants to fail the build if tests fail. What should the developer do?

A.Ensure the test command exits with a non-zero status on failure.

B.Run tests in the post_build phase.

C.Set the command to always exit 0.

D.Enable build badges.

AnswerA

AWS CodeBuild determines the success or failure of a build step based on the exit code of the executed command. A non-zero exit status, by convention in Unix-like systems, signals an error or failure. Therefore, configuring the test runner to return a non-zero exit code when tests fail will correctly propagate the test failure to CodeBuild, causing the entire build to fail and alert developers to issues. This mechanism is fundamental for automated CI/CD pipelines to accurately reflect the health of the codebase.

Why this answer

In CodeBuild, the build phase succeeds or fails based on the exit code of the commands in the buildspec. By default, if a test command exits with a non-zero status, CodeBuild marks the build as FAILED. Therefore, ensuring the test command exits with a non-zero status on failure is the correct approach to fail the build when tests fail.

Exam trap

The trap here is that candidates may think moving tests to a different phase (post_build) or enabling badges will fix the issue, but the core mechanism is the exit code of the command, not the phase or visual indicators.

How to eliminate wrong answers

Option B is wrong because running tests in the post_build phase does not change the exit code behavior; the post_build phase also respects exit codes, but the issue is about the test command's exit status, not the phase. Option C is wrong because setting the command to always exit 0 would suppress the failure indication, causing the build to succeed even when tests fail, which is the opposite of the desired outcome. Option D is wrong because enabling build badges only adds a visual status badge to the repository; it does not affect build success or failure behavior.

Full explanation →

957

MCQmedium

A developer is building a serverless application that processes personally identifiable information (PII). The application uses API Gateway, Lambda, and DynamoDB. The developer needs to ensure that the PII is encrypted at rest in DynamoDB. The company already uses AWS KMS with a customer-managed key for other services. The developer wants to reuse the same KMS key for DynamoDB. After enabling encryption with the KMS key, the Lambda function fails to write to the table with an AccessDenied error. The Lambda execution role has dynamodb:PutItem permission. What is the most likely cause?

A.The Lambda execution role lacks kms:Encrypt and kms:Decrypt permissions on the customer-managed KMS key.

B.The Lambda execution role does not have DynamoDB write permissions.

C.The DynamoDB table has a resource-based policy that denies access.

D.The Lambda function is not in a VPC, so it cannot access the KMS key.

AnswerA

The Lambda execution role requires kms:Encrypt and kms:Decrypt permissions on the customer-managed KMS key (CMK) when interacting with a DynamoDB table encrypted with that CMK. Although DynamoDB handles the actual encryption and decryption at rest, it performs these KMS operations on behalf of the calling principal, which is the Lambda function in this scenario. Without these specific KMS permissions granted to its execution role, the Lambda function cannot authorize DynamoDB to use the CMK for data operations, leading to access denied errors when attempting to write or read items.

Why this answer

When a DynamoDB table is encrypted with a customer-managed KMS key, any operation that reads or writes data to the table requires the caller to have permissions to use that KMS key. Even though the Lambda execution role has dynamodb:PutItem permission, the PutItem operation internally triggers KMS Encrypt and Decrypt calls to manage the encryption of the item. Without kms:Encrypt and kms:Decrypt permissions on the specific KMS key, the request fails with an AccessDenied error.

Exam trap

The trap here is that candidates assume DynamoDB's built-in encryption with a KMS key is transparent and does not require additional IAM permissions beyond the DynamoDB actions, but in reality, the caller must have explicit KMS permissions on the key for any read or write operation.

How to eliminate wrong answers

Option B is wrong because the question explicitly states that the Lambda execution role has dynamodb:PutItem permission, so the failure is not due to missing DynamoDB write permissions. Option C is wrong because there is no mention of a resource-based policy on the DynamoDB table, and the error is specifically related to KMS permissions, not a table policy denying access. Option D is wrong because Lambda functions do not need to be in a VPC to access KMS; KMS is a regional service accessible over the public AWS network, and VPC configuration is irrelevant to KMS key access permissions.

Full explanation →

958

Multi-Selecthard

Which THREE actions can a developer take to improve the cold start latency of an AWS Lambda function?

Select 3 answers

A.Use a language runtime with faster startup time, such as Python or Node.js.

B.Place the Lambda function inside a VPC.

C.Enable provisioned concurrency for the function.

D.Increase the function's memory allocation.

E.Increase the function's timeout setting.

AnswersA, C, D

Python and Node.js runtimes generally exhibit significantly faster startup times compared to compiled languages like Java or .NET. This is primarily due to their lighter runtime environments and quicker code interpretation/JIT compilation processes. They require less time to load the runtime, initialize the execution environment, and parse/execute the initial function code, thereby reducing the duration of a cold start. This optimization directly minimizes the latency experienced by the end-user during the first invocation of an idle function.

Why this answer

Python and Node.js use interpreted runtimes with faster initialization times compared to compiled runtimes like Java or .NET. These runtimes have smaller binary sizes and lower startup overhead, reducing the time from invocation to execution start, which directly improves cold start latency.

Exam trap

The trap here is that candidates often confuse increasing timeout or placing functions in a VPC as performance optimizations, when in reality VPCs worsen cold starts and timeout only affects execution duration, not initialization speed.

Full explanation →

959

MCQeasy

A developer is deploying an application on Amazon ECS using the Fargate launch type. The application needs to read configuration data from an Amazon S3 bucket. How should the developer securely provide the S3 bucket name to the container at runtime?

A.Define an environment variable in the ECS task definition with the bucket name.

B.Hardcode the bucket name in the application code.

C.Use AWS Systems Manager Parameter Store and retrieve the bucket name at startup.

D.Store the bucket name in the container image's environment file.

AnswerA

Defining the bucket name as an environment variable within the ECS task definition is the recommended practice for injecting configuration. This approach decouples the application code from environment-specific details, allowing the same container image to be used across development, staging, and production environments. The containerized application can then easily access this value at runtime through standard environment variable retrieval mechanisms, promoting flexibility and maintainability without requiring code changes or image rebuilds.

Why this answer

Defining an environment variable in the ECS task definition is the simplest and most secure way to inject the S3 bucket name into the container at runtime. Environment variables are passed to the container when it starts, and they can be stored in the task definition itself or referenced from AWS Secrets Manager or Systems Manager Parameter Store for sensitive values. This approach avoids hardcoding and keeps the configuration decoupled from the application code.

Exam trap

The trap here is that candidates often over-engineer the solution by choosing AWS Systems Manager Parameter Store for all configuration data, even when the value is not sensitive and a simpler environment variable suffices, leading to unnecessary complexity and potential startup delays.

How to eliminate wrong answers

Option B is wrong because hardcoding the bucket name in the application code violates the principle of configuration externalization, making the application inflexible and requiring code changes for different environments. Option C is wrong because while Systems Manager Parameter Store can securely store the bucket name, it requires additional SDK calls and IAM permissions at startup, adding unnecessary complexity for a non-sensitive value like a bucket name; environment variables are more straightforward. Option D is wrong because storing the bucket name in the container image's environment file embeds configuration into the image, which breaks immutability and forces rebuilding the image for any configuration change, contrary to best practices for containerized applications.

Full explanation →

960

MCQeasy

A developer is designing a web application that will run on EC2 instances behind an Application Load Balancer. The application needs to authenticate users. Which service should the developer use to manage user identities and provide single sign-on?

A.AWS IAM

B.Amazon Cognito

C.AWS Directory Service

D.AWS Security Token Service (STS)

AnswerB

Amazon Cognito is the ideal service for managing user identities and authentication for web and mobile applications, offering highly scalable user directories through its User Pools feature. It handles user registration, sign-in, and account recovery, and can integrate with social identity providers or enterprise directories. Cognito provides robust authentication flows and token management, specifically designed for application end-users.

Why this answer

Amazon Cognito is the correct choice because it is a fully managed identity service designed for web and mobile applications. It provides user sign-up, sign-in, and access control, and supports single sign-on (SSO) through federation with social identity providers (e.g., Google, Facebook) and enterprise identity providers via SAML 2.0 or OIDC. This makes it ideal for authenticating users in an application running behind an Application Load Balancer.

Exam trap

The trap here is confusing AWS IAM (for AWS resource access) with a customer-facing identity service, leading candidates to choose IAM for user authentication instead of Cognito.

How to eliminate wrong answers

Option A is wrong because AWS IAM is designed for managing permissions for AWS services and resources, not for authenticating end users of a web application; it lacks built-in user registration, sign-in UI, and SSO federation for external identities. Option C is wrong because AWS Directory Service is primarily for integrating with Microsoft Active Directory or creating managed directories for enterprise workloads, not for providing a simple, scalable user identity store with social login or SSO for web applications. Option D is wrong because AWS Security Token Service (STS) is used to issue temporary security credentials for AWS API requests, not for managing user identities or providing authentication and SSO for application users.

Full explanation →

961

Multi-Selectmedium

Which TWO actions can help reduce latency for a web application hosted on EC2 instances behind an Application Load Balancer? (Select TWO.)

Select 2 answers

A.Increase the EC2 instance size to a larger type.

B.Use Amazon CloudFront as a content delivery network.

C.Disable keep-alive connections on the ALB.

D.Use multiple Availability Zones for the ALB.

E.Enable HTTP/2 on the Application Load Balancer.

AnswersB, E

Amazon CloudFront, a global content delivery network (CDN), significantly reduces latency by caching static and dynamic content at edge locations worldwide. When a user requests content, CloudFront serves it from the nearest edge location, minimizing the physical distance data must travel. This reduces the round-trip time (RTT) between the user and the content source, resulting in faster load times and an improved user experience compared to fetching all content directly from the origin server in a single AWS region.

Why this answer

Option B is correct because Amazon CloudFront caches content at edge locations closer to end users, reducing round-trip time and offloading requests from the ALB and EC2 origin, which directly lowers latency for the web application. Option E is correct because ALBs natively support HTTP/2, and enabling it allows multiplexed streams over a single TCP connection, reducing connection overhead and improving page load latency for clients. Option A is not necessarily correct because a larger instance type increases compute capacity but does not inherently reduce network latency.

Option C is incorrect because disabling keep-alive forces new TCP/TLS handshakes per request, increasing latency. Option D is incorrect because using multiple Availability Zones improves availability and fault tolerance, not latency.

Exam trap

DVA-C02 often tests the misconception that adding AZs or scaling instance size reduces latency, when those address availability and capacity, not network round-trip time.

Full explanation →

962

MCQmedium

A developer is using the AWS Serverless Application Model (SAM) to define a serverless application with an API Gateway endpoint. The developer wants to enable API caching only in the development stage to speed up testing, but disable it in the production stage to ensure data freshness. What is the most efficient way to achieve this with SAM?

A.Use AWS SAM parameters with a condition to set CacheClusterEnabled based on the stage parameter.

B.Deploy two separate SAM templates, one for each stage.

C.Use a custom resource to toggle caching after deployment.

D.Enable caching globally and configure a usage plan with a quota for production.

AnswerA

AWS SAM parameters, combined with CloudFormation conditions, provide a robust mechanism to tailor resource configurations based on deployment-time inputs, such as a 'stage' parameter. By defining a condition that evaluates the 'stage' parameter (e.g., `Fn::Equals` 'prod'), the `CacheClusterEnabled` property can be conditionally set to `true` or `false` using `Fn::If`. This approach allows a single, consistent SAM template to manage multiple environments (e.g., dev, prod) without requiring manual modifications or separate template files, adhering to Infrastructure as Code best practices.

Why this answer

AWS SAM parameters allow you to define a stage parameter (e.g., 'dev' or 'prod') and use a condition to conditionally set the `CacheClusterEnabled` property on the `AWS::Serverless::Api` resource. This is the most efficient approach because it uses a single template and SAM's built-in intrinsic functions (like `Fn::Equals`) to toggle caching based on the deployment stage, avoiding separate templates or post-deployment custom resources.

Exam trap

The trap here is that candidates may think caching must be managed via usage plans or custom resources, overlooking SAM's ability to conditionally set API Gateway stage properties directly through parameters and conditions in a single template.

How to eliminate wrong answers

Option B is wrong because deploying two separate SAM templates duplicates infrastructure code and increases maintenance overhead, which is less efficient than using a single parameterized template. Option C is wrong because using a custom resource to toggle caching after deployment adds unnecessary complexity and latency, and SAM already supports conditional resource properties natively. Option D is wrong because enabling caching globally and using a usage plan with a quota does not disable caching for production; usage plans control throttling and API keys, not the API Gateway cache behavior, and caching would still be active in production, violating the requirement for data freshness.

Full explanation →

963

Multi-Selectmedium

A developer is deploying a web application using AWS Elastic Beanstalk. The application needs to store session state. Which THREE services can be used for session state storage? (Choose THREE.)

Select 3 answers

A.Amazon ElastiCache for Redis

B.Amazon DynamoDB

C.Amazon S3

D.Amazon CloudFront

E.Amazon RDS

AnswersA, B, E

Amazon ElastiCache for Redis is an excellent choice for session storage due to its in-memory, key-value data store capabilities. It provides sub-millisecond latency and high throughput, which are critical for quickly retrieving and updating user session data with every request. Its ability to scale horizontally and its robust feature set make it ideal for managing transient, high-access application state efficiently.

Why this answer

Amazon ElastiCache for Redis (A) is correct because it is an in-memory data store that supports fast key-value session data with sub-millisecond latency and optional persistence, making it a standard choice for shared session state in Elastic Beanstalk applications. Amazon DynamoDB (B) is correct because it is a fully managed, highly available key-value NoSQL database that can store session tokens and attributes with consistent low-latency reads/writes at scale. Amazon RDS (E) is correct because a relational database such as MySQL, PostgreSQL, or SQL Server can persist session state in a table, and Elastic Beanstalk applications commonly use RDS for shared session storage.

Amazon S3 (C) is not appropriate because it is object storage with eventual consistency characteristics and higher latency, not designed for frequent small session reads/writes. Amazon CloudFront (D) is a content delivery network that caches HTTP content at edge locations and does not provide writable session state storage.

Exam trap

Candidates may mistakenly think Amazon S3 can be used for session state due to its general-purpose storage capabilities, but S3's high latency for small, frequent writes makes it unsuitable for session management. Additionally, some candidates might overlook RDS, but relational databases are a very common (though less performant) destination for session state, especially during lift-and-shift migrations.

Full explanation →

964

MCQmedium

A developer is using AWS CodeDeploy to deploy an application to a fleet of EC2 instances in an Auto Scaling group. The application must remain available during the deployment. The developer wants to update one instance at a time, ensuring that only one instance is taken offline at any moment. Which deployment configuration should the developer choose?

A.CodeDeployDefault.OneAtATime

B.CodeDeployDefault.HalfAtATime

C.CodeDeployDefault.AllAtOnce

D.CodeDeployDefault.LambdaCanary10Percent5Minutes

AnswerA

The CodeDeployDefault.OneAtATime configuration deploys application revisions to exactly one EC2 instance at a time within the target fleet. This strategy ensures maximum application availability during deployments, as only a single instance is ever out of service or being updated at any given moment. While slower, it significantly minimizes the risk of widespread service disruption and is ideal for critical applications requiring continuous uptime.

Why this answer

CodeDeployDefault.OneAtATime is the correct deployment configuration because it deploys the application to only one instance at a time, ensuring that the remaining instances continue to serve traffic. This matches the requirement to take only one instance offline at any moment, preserving high availability throughout the deployment.

Exam trap

The trap here is that candidates may confuse 'one at a time' with 'half at a time' or 'all at once' due to misreading the requirement for minimal disruption, or they may incorrectly apply a Lambda-specific configuration to an EC2 deployment.

How to eliminate wrong answers

Option B is wrong because CodeDeployDefault.HalfAtATime deploys to half of the instances simultaneously, which would take multiple instances offline at once, violating the requirement to update only one instance at a time. Option C is wrong because CodeDeployDefault.AllAtOnce deploys to all instances concurrently, taking the entire fleet offline simultaneously and causing downtime. Option D is wrong because CodeDeployDefault.LambdaCanary10Percent5Minutes is a deployment configuration for AWS Lambda functions, not for EC2 instances in an Auto Scaling group, and it uses a canary traffic-shifting pattern irrelevant to EC2-based deployments.

Full explanation →

965

MCQmedium

A developer is creating a web application that uses Amazon Cognito for user authentication. The application needs to verify the identity of users before allowing access to the API. Which Cognito feature should the developer use?

A.User Pools

B.Identity Pools

C.Cognito Sync

D.Cognito Events

AnswerA

Amazon Cognito User Pools serve as a secure, scalable user directory that handles user registration, authentication, and account recovery for web and mobile applications. They manage user identities, issue JSON Web Tokens (JWTs) upon successful authentication, including ID, access, and refresh tokens, which are then used to authorize access to application APIs. This service is the primary component for directly authenticating users into your application, making it the correct choice for managing user sign-in.

Why this answer

Amazon Cognito User Pools provide a fully managed identity and access management service specifically designed for user authentication and authorization in web and mobile applications. They handle user sign-up, sign-in, and identity verification through features like multi-factor authentication (MFA) and JSON Web Token (JWT) issuance, making them the correct choice for verifying user identity before granting API access.

Exam trap

The trap here is confusing Identity Pools (which grant AWS credentials) with User Pools (which authenticate users), leading candidates to select Identity Pools when the question explicitly asks about verifying user identity, not granting AWS resource access.

How to eliminate wrong answers

Option B (Identity Pools) is wrong because Identity Pools are used to exchange user tokens (from a User Pool or other identity provider) for temporary AWS credentials to access AWS services like DynamoDB or S3, not for authenticating users directly. Option C (Cognito Sync) is wrong because Cognito Sync is a deprecated service for synchronizing user profile data across devices, not for identity verification. Option D (Cognito Events) is wrong because Cognito Events are AWS Lambda triggers that run during User Pool operations (e.g., pre-sign-up), but they do not perform user authentication themselves.

Full explanation →

966

MCQmedium

A developer has deployed a serverless application using AWS SAM. After a recent update, the API Gateway endpoints return 500 errors. The Lambda function logs show no errors. What should the developer investigate first?

A.Increase the Lambda function timeout.

B.Check the Lambda function's reserved concurrency.

C.Review the CloudFormation stack events for any failures.

D.Verify the API Gateway integration response and mapping templates.

AnswerD

Even if a Lambda function executes successfully and returns a valid response, API Gateway can still return a 500 Internal Server Error to the client if its integration response or mapping templates are misconfigured. These templates are responsible for transforming the Lambda function's output into the final HTTP response format expected by the client. A failure in this transformation process within API Gateway itself often manifests as a 500 error.

Why this answer

When API Gateway returns 500 errors but Lambda logs show no errors, the issue is typically in the API Gateway integration response or mapping templates. API Gateway may fail to transform the Lambda response into the expected format, causing an internal server error without the Lambda function ever throwing an exception.

Exam trap

The trap here is that candidates assume 500 errors always originate from the Lambda function, but the question explicitly states Lambda logs show no errors, forcing the candidate to look at the API Gateway integration layer instead.

How to eliminate wrong answers

Option A is wrong because increasing the Lambda function timeout would not resolve 500 errors if the function is completing successfully (as indicated by no errors in logs); timeout issues would manifest as 504 errors, not 500. Option B is wrong because reserved concurrency controls the number of concurrent executions, not response formatting; concurrency issues would cause throttling (429 errors) or invocation failures, not 500 errors with successful logs. Option C is wrong because CloudFormation stack events would show deployment failures, but the question states the application was deployed successfully and only after an update the errors appeared; stack events would not reveal runtime integration issues between API Gateway and Lambda.

Full explanation →

967

MCQeasy

A developer wants to securely store database credentials used by a Lambda function. The credentials should be automatically rotated every 90 days. Which service should be used?

A.AWS Secrets Manager

B.AWS Key Management Service (KMS)

C.AWS Identity and Access Management (IAM)

D.AWS Systems Manager Parameter Store

AnswerA

AWS Secrets Manager stores credentials securely and natively supports automatic rotation through Lambda rotation functions, satisfying the 90-day rotation constraint. Unlike Parameter Store, which offers no built-in rotation, Secrets Manager schedules rotation and updates the secret, so the Lambda function retrieves current database credentials without manual intervention.

Why this answer

AWS Secrets Manager is the correct choice because it is purpose-built for securely storing, retrieving, and automatically rotating database credentials and other secrets. It supports native rotation with built-in integration for Amazon RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB) and Amazon DocumentDB, allowing you to configure automatic rotation every 90 days without custom code. The service encrypts secrets at rest using AWS KMS and enforces fine-grained access control via IAM policies.

Exam trap

The trap here is that candidates often confuse AWS Systems Manager Parameter Store with Secrets Manager because both can store secrets, but Parameter Store lacks native automatic rotation, which is explicitly required by the 90-day rotation requirement in the question.

How to eliminate wrong answers

Option B (AWS KMS) is wrong because it is a key management service for creating and controlling encryption keys, not a secret storage service; it cannot store or rotate database credentials. Option C (IAM) is wrong because it manages users, groups, roles, and permissions for AWS API access, not database credentials; it has no mechanism to store or rotate secrets. Option D (AWS Systems Manager Parameter Store) is wrong because while it can store secrets as SecureString parameters, it does not natively support automatic rotation of credentials; you would need to build a custom rotation solution using Lambda, whereas Secrets Manager provides built-in rotation.

Full explanation →

968

MCQmedium

A developer is using AWS Lambda with an Amazon RDS MySQL database. The Lambda function frequently times out when connecting to the database. What is the MOST likely cause?

A.The Lambda function is not configured with enough memory

B.The Lambda function is not using a reserved concurrency limit

C.The Lambda function is not attached to the same VPC as the RDS instance

D.The Lambda function's execution role lacks RDS permissions

AnswerC

An Amazon RDS MySQL instance is deployed within a private Virtual Private Cloud (VPC) and is not publicly accessible by default, requiring private network access. For a Lambda function to connect to this private RDS instance, it must be configured to operate within the same VPC as the database, or a peered VPC, with appropriate security group rules allowing outbound traffic. Without this explicit VPC configuration, the Lambda function executes in the AWS managed network, lacking the necessary private network interface to reach the RDS endpoint directly, resulting in connection failures.

Why this answer

Lambda functions must be attached to the same VPC as the RDS instance to connect via a private IP address. Without VPC attachment, the Lambda function attempts to connect over the public internet, which can cause timeouts due to network latency, security group restrictions, or the RDS instance being configured as publicly inaccessible.

Exam trap

The trap here is that candidates often assume timeout issues are due to insufficient memory or IAM permissions, but the real cause is almost always a network connectivity problem when Lambda cannot reach the RDS instance inside a VPC.

How to eliminate wrong answers

Option A is wrong because increasing memory allocates more CPU and network bandwidth, but it does not resolve network connectivity issues like VPC misconfiguration. Option B is wrong because reserved concurrency limits the number of concurrent executions but does not affect individual function connection timeouts. Option D is wrong because IAM permissions control authorization to perform RDS API actions (e.g., creating snapshots), not network-level connectivity to the database; connection timeouts are a network issue, not an authorization issue.

Full explanation →

969

MCQhard

A team is using AWS CodePipeline with multiple stages: Source, Build, Test, and Deploy. The Deploy stage uses AWS CodeDeploy to deploy to an EC2 Auto Scaling group. The pipeline runs successfully, but the application still serves the old version. What is the most likely cause?

A.The CodeDeploy deployment group is associated with a different Auto Scaling group than the one serving traffic.

B.The load balancer's target group is not pointing to the correct instances.

C.The build artifact in the Source stage is corrupted.

D.The CodeBuild stage failed silently and did not produce a new artifact.

AnswerA

This scenario directly explains why the old version is served. If the CodeDeploy deployment group targets an Auto Scaling group that is *not* currently registered with the load balancer or is an old, inactive group, the deployment will succeed on those instances. However, the load balancer will continue routing traffic to the *active* Auto Scaling group, which still hosts the previous application version, making the new deployment invisible to users.

Why this answer

The most likely cause is that the CodeDeploy deployment group is associated with a different Auto Scaling group than the one actually serving traffic. Even though the pipeline runs successfully, CodeDeploy deploys the new application revision only to instances in the Auto Scaling group linked to its deployment group. If the deployment group targets a different Auto Scaling group (e.g., a staging group) while the live traffic is served by another group (e.g., production), the old version remains on the production instances.

Exam trap

The trap here is that candidates assume a successful pipeline run guarantees the new version is live, overlooking that CodeDeploy's deployment group configuration determines which Auto Scaling group receives the update.

How to eliminate wrong answers

Option B is wrong because if the load balancer's target group were not pointing to the correct instances, the application would likely be unreachable or return errors, not serve an old version. Option C is wrong because a corrupted build artifact in the Source stage would typically cause the pipeline to fail at the Build or Deploy stage, not complete successfully. Option D is wrong because if the CodeBuild stage failed silently, the pipeline would not proceed to the Deploy stage, and the deployment would not run at all.

Full explanation →

970

MCQhard

A company is using AWS CloudFormation to manage infrastructure. The developer wants to update a stack but needs to prevent specific resources from being replaced. What CloudFormation feature should the developer use?

A.Use a custom resource to manage the update logic.

B.Apply a stack policy that denies updates to the specific resources.

C.Create a change set to review the changes before execution.

D.Use a deletion policy attribute on the resources to protect them.

AnswerB

A stack policy is a JSON document that defines permissions for update actions on resources within a CloudFormation stack. By applying a stack policy with an explicit "Deny" statement for the "Update" action on specific logical resource IDs or resource types, you can effectively prevent CloudFormation from performing any modifications to those protected resources, ensuring their immutability.

Why this answer

A stack policy is a JSON-based policy that defines which resources in a CloudFormation stack can be updated, replaced, or deleted. By applying a stack policy that denies updates to specific resources, the developer can prevent those resources from being replaced during a stack update, even if the template change would normally trigger a replacement.

Exam trap

The trap here is confusing a deletion policy (which only protects against stack deletion) with a stack policy (which controls update-time replacement), leading candidates to incorrectly choose Option D.

How to eliminate wrong answers

Option A is wrong because custom resources are used to implement custom provisioning logic (e.g., calling an external API) during stack operations, not to prevent resource replacement. Option C is wrong because a change set only allows you to preview the changes that will be made; it does not prevent specific resources from being replaced. Option D is wrong because a deletion policy (e.g., Retain, Snapshot) only controls what happens when a resource is deleted from the stack; it does not prevent the resource from being replaced during an update.

Full explanation →

971

MCQeasy

A developer is building a serverless application that needs to process messages from an Amazon SQS queue and store the results in an Amazon DynamoDB table. Which AWS service should the developer use to orchestrate the processing logic without managing servers?

A.Amazon Elastic Container Service (ECS) with Fargate

B.Amazon EC2 instances with a custom application

C.AWS Lambda

D.AWS Step Functions

AnswerC

AWS Lambda is the ideal serverless compute service for processing messages in an event-driven architecture. It automatically executes code in response to triggers, such as messages arriving in an SQS queue, without requiring any server provisioning or management. Lambda scales seamlessly with demand, offers a cost-effective pay-per-execution model, and integrates natively with other AWS services, making it perfectly suited for building highly scalable and resilient message processing components.

Why this answer

AWS Lambda is the correct choice because it is a serverless compute service that can be triggered by SQS messages via event source mappings, process each message, and write results to DynamoDB without provisioning or managing any servers. The developer simply uploads the processing code, and Lambda handles scaling, concurrency, and execution, making it ideal for this event-driven, serverless workflow.

Exam trap

The trap here is that candidates often confuse AWS Step Functions as a serverless orchestrator for simple tasks, but Step Functions is designed for coordinating multi-step workflows and state machines, not for directly processing individual SQS messages, which is a core Lambda use case.

How to eliminate wrong answers

Option A is wrong because Amazon ECS with Fargate, while serverless in terms of infrastructure management, still requires defining a container image, task definitions, and cluster configuration, which adds unnecessary overhead for a simple message-processing task that can be handled by a single function. Option B is wrong because Amazon EC2 instances require manual server provisioning, patching, scaling, and management, which violates the 'without managing servers' requirement of the question. Option D is wrong because AWS Step Functions is a state machine orchestration service designed to coordinate multiple AWS services and handle complex workflows, not to directly process individual SQS messages; using it here would introduce unnecessary complexity and cost compared to a direct Lambda trigger.

Full explanation →

972

MCQeasy

A developer is writing a Lambda function that needs to access an Amazon RDS MySQL database. The function will be invoked frequently. What is the BEST practice for managing the database connection?

A.Close the database connection at the end of each invocation.

B.Open a new database connection inside the handler for each invocation.

C.Open the database connection outside the handler function and reuse it.

D.Use Amazon RDS Proxy to manage the connection pool.

AnswerD

While Amazon RDS Proxy is an excellent service for managing database connection pooling, multiplexing, and resilience for serverless applications, it is not the most direct or fundamental solution for how a developer should structure their Lambda function's code for efficient connection handling. RDS Proxy operates as an intermediary layer, abstracting connection management from the Lambda function itself. The question specifically asks about the developer's approach within the function, and reusing connections within the execution context is a more direct and immediate code-level optimization.

Why this answer

For Lambda functions accessing relational databases like Amazon RDS, the best practice is to use Amazon RDS Proxy. Because Lambda functions can scale rapidly to hundreds or thousands of concurrent executions, they can quickly exhaust the database's connection pool. RDS Proxy pools and shares these connections, improving scalability and application resilience.

While opening connections outside the handler (Option C) is a good general practice, it does not solve the connection exhaustion problem under high concurrency and frequent invocations.

Exam trap

Candidates often choose Option C because they remember the general Lambda rule of 'reusing connections outside the handler.' However, for relational databases (RDS), this approach still leads to connection exhaustion when Lambda scales. RDS Proxy (Option D) is the correct AWS-recommended architectural pattern for this scenario.

How to eliminate wrong answers

Option A is wrong because closing the database connection at the end of each invocation forces the next invocation to re-establish the connection, negating the benefit of connection reuse and increasing latency and database load. Option B is wrong because opening a new connection inside the handler for each invocation repeats the expensive connection setup (TCP handshake, SSL/TLS negotiation, MySQL authentication) on every call, which is inefficient for high-frequency invocations. Option D is wrong because while Amazon RDS Proxy can help manage connection pooling and reduce database load, it is not the best practice for the Lambda function itself; the question asks for managing the connection within the function, and RDS Proxy is an external service that adds complexity and cost, whereas reusing the connection outside the handler is simpler and more direct.

Full explanation →

973

MCQmedium

A developer is troubleshooting an application that uses Amazon ElastiCache for Redis to cache database query results. The application experiences high latency during cache misses. The developer notices that frequently accessed keys (hot keys) are often missing from the cache, suggesting they are being evicted. Which action should the developer take to reduce cache misses for hot keys?

A.Increase the number of cache nodes.

B.Switch to the 'allkeys-lru' eviction policy.

C.Disable the TTL on all cached keys.

D.Increase the size of the cache cluster.

AnswerB

allkeys-lru evicts the least recently used keys from all keys, which tends to retain frequently used hot keys.

Why this answer

ElastiCache for Redis defaults to the 'volatile-lru' eviction policy, which considers only keys that have a TTL for eviction. Under memory pressure, Redis may evict frequently accessed TTL-bearing keys while cold keys without TTL cannot be evicted. Switching to 'allkeys-lru' expands the candidate set to include keys without TTL, allowing Redis to evict less-recently-used non-TTL keys first and reducing the likelihood that hot TTL-bearing keys are evicted.

Exam trap

The trap here is that candidates assume scaling up or out is the only solution for cache misses, overlooking that the eviction policy directly controls which keys are removed under memory pressure, and 'volatile-lru' by default excludes keys without TTL from eviction consideration.

How to eliminate wrong answers

Option A is wrong because increasing the number of cache nodes (scaling out) distributes data across shards but does not change the eviction policy; hot keys can still be evicted under memory pressure if the policy does not protect them. Option C is wrong because disabling TTL on all cached keys would prevent expiration-based eviction but does not address eviction due to memory limits; Redis would still evict keys under the 'volatile-lru' policy, and without TTL, those keys become ineligible for eviction, potentially causing out-of-memory errors. Option D is wrong because increasing the size of the cache cluster (scaling up) adds more memory, which delays eviction but does not change the eviction policy; hot keys without TTL remain vulnerable to eviction once memory is exhausted.

Full explanation →

974

MCQhard

A developer needs to ensure that every cryptographic operation performed on an AWS KMS customer master key (CMK) used for server-side encryption in Amazon S3 is recorded in AWS CloudTrail for auditing. The developer has already enabled CloudTrail and is logging management events. However, the security team wants to see all calls to the KMS Decrypt and Encrypt APIs for this specific key. What must the developer do?

A.Enable CloudTrail data events for the S3 bucket containing the encrypted objects.

B.Create an additional CloudTrail trail that logs all management events for the KMS key.

C.Enable CloudTrail data events for the specific KMS key ARN.

D.Enable CloudTrail Insights events on the existing trail.

AnswerC

CloudTrail data events for KMS record every call to Decrypt, Encrypt, GenerateDataKey, etc. By specifying the key ARN in the data event selector, only operations on that key are logged, meeting the audit requirement without excessive logging.

Why this answer

CloudTrail data events can be configured to log individual API operations (such as Decrypt and Encrypt) on specific KMS keys. By default, CloudTrail management events do not include these data-plane operations; enabling data events for the specific KMS key ARN ensures every cryptographic call is recorded for auditing.

Exam trap

The trap here is that candidates confuse S3 server-side encryption with KMS data events, assuming that logging S3 bucket data events will capture KMS calls, when in fact KMS data-plane operations require explicit data event logging on the KMS key itself.

How to eliminate wrong answers

Option A is wrong because enabling CloudTrail data events for the S3 bucket captures S3 object-level operations (e.g., GetObject, PutObject), not the KMS Decrypt and Encrypt API calls themselves. Option B is wrong because management events already include KMS key management actions (e.g., CreateKey, DisableKey) but not data-plane cryptographic operations; creating another trail with management events does not capture Decrypt/Encrypt. Option D is wrong because CloudTrail Insights events detect unusual API activity patterns but do not log individual Decrypt/Encrypt calls; they are an analysis feature, not a logging configuration for specific API operations.

Full explanation →

975

MCQhard

A company runs a web application on EC2 instances behind an Application Load Balancer. The security team discovers that the application is vulnerable to SQL injection attacks. The team wants to implement a web application firewall (WAF) to block these attacks. The architecture includes an ALB, EC2 instances in an Auto Scaling group, and an RDS database. The ALB currently has a listener on port 443 with an SSL certificate. The developer must integrate AWS WAF with minimal changes to the existing infrastructure. Which action should the developer take?

A.Subscribe to AWS Shield Advanced and enable automatic mitigation.

B.Install a WAF agent on each EC2 instance in the Auto Scaling group.

C.Place a CloudFront distribution in front of the ALB and associate WAF with CloudFront.

D.Associate AWS WAF directly with the Application Load Balancer.

AnswerD

AWS WAF supports direct association with an Application Load Balancer through a web ACL, letting the developer attach managed rule groups such as the SQL injection rule set (AWSManagedRulesSQLiRuleSet) to the existing ALB with no new services, no DNS changes, and no modification to the SSL listener, satisfying the requirement for minimal-change integration.

Why this answer

AWS WAF can be directly associated with an Application Load Balancer (ALB) to filter HTTP/HTTPS requests and block SQL injection attacks. This requires minimal changes to the existing infrastructure because no additional components like CloudFront or agents are needed. Option A is incorrect because AWS Shield Advanced is a DDoS protection service, not a WAF, and does not include SQL injection rules.

Option B is incorrect because WAF is a managed service that operates at the edge or load balancer level, not as an agent on EC2 instances. Option C is incorrect because while you could place CloudFront in front of the ALB and attach WAF to CloudFront, it adds unnecessary complexity and cost when the ALB already supports direct WAF association.

Full explanation →

AWS Certified Developer Associate DVA-C02 (DVA-C02) — Questions 901–975