1135 questions total · 16pages · All types, answers revealed
Page 1 of 16
Page 2Match each AWS service to its port number (if applicable).
Drag a concept onto its matching description — or click a concept then click the description.
3306
6379
5432
11211
1521
Why these pairings
Default ports are important for configuring security groups and connecting to databases.
A developer is building an application that uses Amazon Cognito for user authentication. The application needs to allow users to sign in with their existing Google accounts. Which action should the developer take to enable this?
Amazon Cognito user pools support federation with social identity providers like Google. By configuring Google as an identity provider in the user pool, users can sign in with their Google accounts. The developer must supply the Google app's client ID and client secret, which Cognito uses to validate tokens during the federation process.
Why this answer
Cognito user pools natively support federation with Google. Configuring Google as an identity provider in the user pool allows users to sign in with their Google credentials. Cognito handles the OAuth flow, token validation, and user profile creation, simplifying the integration.
Exam trap
The trap here is mixing up user pools and identity pools; identity pools are for AWS credentials, while user pools handle authentication and federation.
A company uses AWS Elastic Beanstalk to deploy a web application. The deployment is successful, but the application health checks fail. The application runs on a single EC2 instance. What should a developer do to troubleshoot this issue?
The Elastic Beanstalk console aggregates application, web server, and deployment logs (full or tail) in one place, letting the developer see stack traces, startup errors, or misconfigured health check paths that are the actual root cause of a failing health check.
Why this answer
Viewing the application logs in the Elastic Beanstalk console helps identify why the application is not responding to health checks. Logs can reveal application errors, missing dependencies, or configuration issues. Option D is wrong because SSH may not be configured for the instance, and restarting the web server without understanding the root cause may not resolve the issue.
Option B is incorrect because modifying the CloudFormation template to increase instance size does not address health check failures. Option C is incorrect because adding an Application Load Balancer does not fix underlying application problems.
A developer is using Amazon S3 to store application logs. The logs are generated every hour and must be retained for 90 days. After 90 days, the logs should be deleted automatically. Which S3 lifecycle policy should the developer configure?
Implementing an S3 Lifecycle rule to Expire objects after 90 days directly addresses the requirement for automatic deletion of application logs. This action permanently removes the objects from the S3 bucket 90 days after their creation, ensuring that old logs are automatically purged. This approach optimizes storage costs and maintains data hygiene without requiring manual intervention, aligning perfectly with a deletion mandate.
Why this answer
The requirement is to delete logs after 90 days, and the S3 lifecycle 'Expire' action permanently removes objects once they reach the specified age. No transitions are needed since the logs are not required to be stored in a different storage class before deletion.
Exam trap
The trap here is that candidates often overcomplicate the solution by adding unnecessary transitions (like Option D) or confuse 'transition' with 'expiration', thinking moving to Glacier after 90 days automatically deletes the data, which it does not.
How to eliminate wrong answers
Option A is wrong because expiring objects after 30 days would delete them far earlier than the required 90-day retention period. Option B is wrong because transitioning objects to S3 Glacier after 90 days does not delete them; it only moves them to a colder storage class, and they would continue to incur storage costs indefinitely unless an expiration action is also configured. Option D is wrong because while it includes an expiration after 90 days, the transition to S3 Standard-IA after 30 days is unnecessary and adds cost; the requirement only specifies deletion after 90 days, not tiering.
A developer is designing a serverless application using AWS Lambda, Amazon API Gateway, and Amazon DynamoDB. The application must authenticate users using a third-party OIDC identity provider and authorize each request. Which THREE steps should the developer take? (Choose THREE.)
Amazon Cognito User Pools are designed to manage user identities and provide authentication for web and mobile applications. By configuring an OIDC identity provider within a Cognito User Pool, developers can enable users to authenticate through an external OIDC-compliant service. Cognito then issues its own JWTs (ID, Access, Refresh tokens) to the application, abstracting the external OIDC provider and simplifying integration for the serverless backend. This is a standard and secure pattern for federated authentication.
Why this answer
Amazon Cognito user pools can be configured to federate with third-party OIDC identity providers. This allows the user pool to act as an intermediary that handles the OIDC token exchange, issuing its own JWT tokens after successful authentication. This is the standard approach for integrating external OIDC providers with AWS serverless applications.
Exam trap
The trap here is confusing the role of API Gateway authorizers: candidates often pick IAM authorizer (Option C) thinking it can validate JWTs, but IAM authorizers require AWS SigV4 signing and are not designed for OIDC token validation, while the Cognito user pool authorizer is the correct choice for JWT-based federated authentication.
A developer is building a serverless application using AWS Lambda to process images uploaded to an S3 bucket. The Lambda function needs to resize the image and store the result in another S3 bucket. The developer notices that the Lambda function fails intermittently with timeout errors for large images. What is the MOST efficient solution to resolve this issue?
Increasing the Lambda function's memory allocation directly scales its CPU power proportionally, providing more computational resources to process larger and more complex images efficiently. Concurrently, extending the timeout allows the function sufficient time to complete computationally intensive tasks like high-resolution image resizing or complex transformations without premature termination. This direct adjustment of allocated resources and execution duration is the most straightforward solution for handling larger image files within a single Lambda invocation.
Why this answer
Increasing the Lambda function timeout and memory allocation directly addresses the root cause of the failure: large images require more processing time and memory. Lambda's CPU and I/O throughput scale proportionally with allocated memory, so raising both parameters provides the necessary resources to complete the resize operation within the function's execution environment.
Exam trap
The trap here is that candidates often overcomplicate the solution by considering orchestration or parallel processing (Options C and D), when the simplest and most efficient fix is to adjust the Lambda function's resource limits, which directly control execution time and processing capacity.
How to eliminate wrong answers
Option B is wrong because limiting S3 event notifications to images smaller than 5 MB does not resolve the issue for larger images; it merely avoids processing them, which is not a solution for handling large images as required. Option C is wrong because Lambda functions run in a single-threaded execution environment by default, and multi-threading for image chunks is not supported; even with provisioned concurrency, image processing libraries like Pillow are not designed for parallel chunk processing within a single invocation. Option D is wrong because AWS Step Functions adds orchestration overhead and does not increase the per-invocation timeout or memory limits of the Lambda function; the underlying timeout error would still occur when a single step processes a large image.
An application in ECS Fargate needs to read a secret and decrypt it with KMS. Which two permissions/configurations are needed?
Assigning an IAM Task Role to the ECS Fargate task and granting it `secretsmanager:GetSecretValue` permissions is the secure and recommended approach. This allows the application running within the container to programmatically retrieve the necessary secret from AWS Secrets Manager at runtime. This method ensures secrets are never hardcoded, facilitates centralized management and rotation, and adheres to the principle of least privilege by granting only the necessary access.
Why this answer
The ECS task role is an IAM role that the Fargate task assumes to make AWS API calls. To read a secret from AWS Secrets Manager, the task role must have an IAM policy granting `secretsmanager:GetSecretValue` permission. Option D is correct because the secret is encrypted with a KMS key, so the task role also needs a KMS key policy or IAM permission that allows `kms:Decrypt` on that specific key.
Exam trap
The trap here is that candidates often confuse EC2 instance profiles with ECS task roles, forgetting that Fargate is serverless and has no underlying EC2 host to attach an instance profile to.
A developer needs to allow users from another AWS account (account ID: 123456789012) to read objects in an S3 bucket owned by the developer's account. The developer wants to use a bucket policy and does not want to create IAM users in the other account. Which bucket policy statement achieves this securely?
The root ARN of the trusted account (arn:aws:iam::123456789012:root) is used as the Principal. This delegates control to the other account's administrator, who can then grant read access to specific IAM users or roles in their account.
Why this answer
It uses the AWS account root principal ARN (arn:aws:iam::123456789012:root) to grant cross-account access to the S3 bucket. This allows any IAM user or role in the external account to read objects, provided the external account's administrator delegates permissions via IAM policies. The bucket policy does not require creating IAM users in the other account, aligning with the requirement.
Exam trap
The trap here is that candidates often confuse the root principal ARN with a specific IAM entity, leading them to choose options that require pre-existing users or roles in the external account, or they misuse conditions like aws:SourceAccount with a wildcard principal, which does not securely restrict access.
How to eliminate wrong answers
Option A is wrong because the aws:SourceAccount condition is used for ensuring the request originates from a specific AWS account in resource-based policies, but it is typically paired with aws:SourceArn to prevent confused deputy issues; here, it is used alone with a wildcard principal, which is insecure and does not restrict to the intended account. Option C is wrong because it specifies a specific IAM user ARN, which requires that user to exist in the external account, contradicting the requirement not to create IAM users. Option D is wrong because it specifies a specific IAM role ARN, which requires that role to exist in the external account, also contradicting the requirement not to create IAM users or roles.
A developer is building a serverless application using AWS Lambda and Amazon API Gateway. The API must support different HTTP methods (GET, POST, PUT, DELETE) for the same resource path. The developer wants to define the API in a single Lambda function that can handle all methods without additional mapping configuration. Which Lambda integration type should the developer use?
Lambda proxy integration is the correct choice because it forwards the complete client request, including HTTP method, headers, query string parameters, and body, directly to the integrated Lambda function as a single input event. This allows the Lambda function to act as a unified handler, inspecting the 'httpMethod' property within the event object to implement distinct logic for different operations (e.g., GET, POST, PUT, DELETE) on the same resource path. This approach significantly simplifies API Gateway configuration by eliminating the need for separate integration request mappings per method.
Why this answer
Lambda proxy integration (option A) is correct because it allows a single Lambda function to handle all HTTP methods (GET, POST, PUT, DELETE) for the same resource path without additional mapping configuration. In this integration type, API Gateway passes the entire client request (method, headers, query parameters, body) as a JSON event to the Lambda function, and the function must return a response in a specific format that includes status code, headers, and body. This eliminates the need for manual mapping templates or method-specific configurations.
Exam trap
The trap here is that candidates often confuse Lambda custom integration with Lambda proxy integration, thinking that custom integration provides more control, but they overlook that proxy integration is specifically designed to handle multiple HTTP methods without additional mapping configuration.
How to eliminate wrong answers
Option B (Lambda custom integration) is wrong because it requires explicit mapping templates to transform the client request into the Lambda function's input format and to transform the Lambda response back to the HTTP response, which adds configuration overhead and does not support handling all methods in a single function without additional mapping. Option C (AWS service integration) is wrong because it is designed to integrate API Gateway directly with other AWS services (e.g., DynamoDB, SQS) without invoking a Lambda function, and it does not support routing multiple HTTP methods to a single Lambda function. Option D (HTTP integration) is wrong because it is used to proxy requests to an external HTTP endpoint, not to a Lambda function, and it requires mapping templates or VPC link configurations, making it unsuitable for a serverless Lambda-based API.
A company has a centralized logging solution where all EC2 instances send logs to a CloudWatch Logs group in a central account. The EC2 instances are in a different account (App Account). The developer configures the CloudWatch agent on the instances with the necessary IAM role. However, logs are not appearing in the central account's log group. The IAM role in the App Account has permissions to put logs to the central account's log group. What is the most likely missing configuration?
For successful cross-account logging, the destination CloudWatch Logs log group in the central account absolutely requires a resource-based policy. This policy must explicitly grant the `logs:PutLogEvents` permission to the specific IAM role or user from the application account that will be sending the logs. Without this explicit permission defined directly on the log group resource, the application account's IAM principal, even with local `logs:PutLogEvents` permissions, will be denied access to write to a log group owned by a different AWS account, establishing the necessary trust boundary.
Why this answer
For cross-account CloudWatch Logs, the central account's log group must have a resource-based policy that grants the App Account's IAM role permission to put logs. Even if the IAM role in the App Account has permissions, the destination log group must also allow the source. This is a common missing configuration.
Exam trap
DVA-C02 often tests cross-account access where both identity-based and resource-based policies are needed. Candidates may focus only on the IAM role permissions and forget the resource-based policy on the destination log group.
How to eliminate wrong answers
Option A is wrong because KMS encryption keys do not need to be the same across accounts; the role needs permission to use the key, but that is not the primary missing configuration for log delivery. Option C is wrong because CloudWatch Logs are regional, but the EC2 instances and log group can be in different regions if configured, though typically they are in the same region; however, the error is about permissions, not region. Option D is wrong because a VPC endpoint is not required for CloudWatch Logs if the instances have internet access or NAT, and the issue is permissions, not network connectivity.
A developer is using AWS CodeDeploy to deploy an application to an Auto Scaling group. The deployment must be as fast as possible while ensuring that at least 50% of instances remain healthy throughout. Which deployment configuration should be used?
The CodeDeployDefault.HalfAtATime configuration updates half of the instances in the Auto Scaling group at a time, ensuring that at least 50% of the instances remain healthy and available throughout the deployment process. This default strikes an optimal balance between deployment speed and application availability, making it a robust choice for production environments where some temporary capacity reduction is acceptable. It is significantly faster than `OneAtATime` while still providing strong resilience.
Why this answer
CodeDeployDefault.HalfAtATime is the correct choice because it deploys to half of the instances in the Auto Scaling group at a time, ensuring that at least 50% of instances remain healthy throughout the deployment. This configuration balances speed (by deploying to multiple instances concurrently) with the required availability constraint, making it the fastest option that satisfies the 'at least 50% healthy' requirement.
Exam trap
The trap here is that candidates may confuse 'HalfAtATime' with 'OneAtATime' thinking slower is safer, or incorrectly assume 'AllAtOnce' is fastest without considering the health constraint, or invent a configuration name like 'MinHealthyPercent' that does not exist in CodeDeploy.
How to eliminate wrong answers
Option A (CodeDeployDefault.OneAtATime) is wrong because it deploys to only one instance at a time, which is the slowest deployment configuration and does not meet the requirement for maximum speed. Option C (CodeDeployDefault.AllAtOnce) is wrong because it deploys to all instances simultaneously, which can cause all instances to become unhealthy at once, violating the 'at least 50% healthy' requirement. Option D (CodeDeployDefault.MinHealthyPercent) is wrong because it is not a valid deployment configuration name in CodeDeploy; the correct parameter is 'minimumHealthyHosts' which can be set to a percentage, but 'MinHealthyPercent' is not a predefined configuration.
The above IAM policy is attached to an IAM role used by a Lambda function. The function tries to scan the table 'MyTable' but receives an AccessDenied error. What is the MOST likely cause?
The `AccessDeniedException` from DynamoDB is the definitive indicator that the IAM principal (the Lambda function's execution role) attempted an API action for which it lacks explicit authorization within its attached IAM policies. If the Lambda function's code is attempting to execute the `Scan` operation, but the IAM policy only permits actions like `GetItem` or `PutItem`, then the `dynamodb:Scan` request will be implicitly denied. IAM operates on an 'explicit allow' model, meaning any action not explicitly allowed is implicitly denied.
Why this answer
The IAM policy shown in the question does not include the 'dynamodb:Scan' action. Without this action explicitly allowed, the Lambda function's role lacks permission to perform a Scan operation on the DynamoDB table, resulting in an AccessDenied error. The policy must grant the specific action required by the API call.
Exam trap
The trap here is that candidates often focus on resource ARN or table existence, overlooking that the policy must explicitly include the specific DynamoDB action (e.g., 'dynamodb:Scan') being called by the Lambda function.
How to eliminate wrong answers
Option A is wrong because if the DynamoDB table did not exist, the error would be a ResourceNotFoundException, not AccessDenied. Option B is wrong because the question states the policy is attached to an IAM role used by the Lambda function, so the role is attached; the error is due to missing permissions, not missing attachment. Option C is wrong because an incorrect resource ARN would cause an error when evaluating the policy, but the error message would typically be AccessDenied only if the ARN does not match; however, the most likely cause given the policy's missing action is the lack of 'dynamodb:Scan'.
A company wants to ensure that no Amazon S3 buckets in the AWS account can be made publicly accessible, even if a bucket policy or ACL is later configured to allow public access. Which AWS feature should the developer enable to enforce this at the account level?
S3 Block Public Access, when configured at the account level, provides a comprehensive safeguard against unintended public exposure of S3 buckets and objects. It enforces four distinct settings (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) that collectively override any bucket policies, ACLs, or object configurations that might otherwise grant public access. This powerful feature ensures that no S3 bucket within the AWS account can be made public, regardless of individual bucket settings.
Why this answer
S3 Block Public Access is the correct choice because it provides account-level settings that override any bucket-level policies or ACLs that would grant public access. When enabled at the account level, these settings apply to all current and future S3 buckets, effectively preventing any bucket from becoming publicly accessible regardless of subsequent configuration changes.
Exam trap
The trap here is that candidates often choose a bucket policy with a Deny clause (Option D) thinking it can enforce account-wide restrictions, but they overlook that such policies are bucket-specific and can be removed or modified by users with appropriate IAM permissions, whereas S3 Block Public Access provides a centralized, immutable account-level control.
How to eliminate wrong answers
Option B is wrong because S3 Object Lock is designed to prevent objects from being deleted or overwritten for a fixed period, not to control public access permissions. Option C is wrong because S3 Transfer Acceleration is a feature that speeds up uploads over long distances using AWS edge locations, and it has no effect on access control or public accessibility. Option D is wrong because a bucket policy with a Deny clause is applied at the individual bucket level, not at the account level, and it can be overridden or removed by anyone with sufficient permissions; it does not provide the centralized, enforceable control that Block Public Access offers.
A developer is deploying an AWS Lambda function that needs to access an Amazon RDS for MySQL database. The function runs in a private subnet and must connect without exposing credentials in code. The database credentials are stored in AWS Secrets Manager and rotate automatically. Which approach should the developer use to retrieve the credentials securely?
Attaching an IAM policy that allows secretsmanager:GetSecretValue to the Lambda execution role lets the function retrieve the current secret with temporary credentials. This avoids hardcoded credentials, respects rotation, and follows least-privilege access, so it is the secure and recommended approach.
Why this answer
Granting the Lambda execution role secretsmanager:GetSecretValue and retrieving the secret at runtime with the AWS SDK is the secure way to use rotating credentials without embedding them. The function always reads the current secret value, and access is controlled through IAM rather than static configuration.
Exam trap
The trap here is thinking that KMS-encrypted environment variables are equivalent to Secrets Manager, when environment variables cannot follow automatic rotation and remain static.
A company's S3 bucket policy includes a condition that uses 'aws:SourceIp' to restrict access to a specific IP range. However, requests from that IP range are still denied. What is a possible reason?
When requests to S3 originate from within a VPC and are routed through a VPC endpoint for S3, the 'aws:SourceIp' condition key in the S3 bucket policy evaluates the private IP address of the VPC endpoint, not the original client's public IP address. Consequently, if the bucket policy's allowed IP range does not include the VPC endpoint's private IP, the request will be denied. To correctly permit access from a VPC endpoint, the 'aws:SourceVpce' condition key, specifying the VPC endpoint ID, should be used instead.
Why this answer
When a request is made through a VPC endpoint (specifically a Gateway Endpoint for S3), the source IP address seen by S3 is the private IP of the VPC endpoint, not the client's original public IP. The 'aws:SourceIp' condition key evaluates the IP address from which the request originates at the network layer, but VPC endpoints use private IPs from the VPC CIDR range, which will not match the public IP range specified in the policy. This causes the condition to fail and the request to be denied, even though the client is within the intended IP range.
How to eliminate wrong answers
Option A is wrong because CloudFront does not change the source IP for S3 bucket policy evaluation; CloudFront uses its own IP addresses when forwarding requests to the origin, but the 'aws:SourceIp' condition in a bucket policy would see CloudFront's IP, not the client's IP, so this could also cause denial, but the question specifies the request is from the correct IP range and still denied, making VPC endpoint the more precise reason. Option B is wrong because IAM user policies do not override bucket policies; if both exist, the request must be allowed by at least one policy, but an explicit deny in the bucket policy would still block the request, and an IAM policy cannot override a bucket policy deny. Option D is wrong because if 'aws:SourceIp' were misspelled, the condition would be ignored (not evaluated), and the policy would likely allow the request (assuming other conditions are met), not deny it.
A company uses AWS KMS to encrypt data in Amazon S3. They have a Customer Master Key (CMK) with key rotation enabled. The S3 bucket has default encryption using SSE-KMS with this CMK. An application writes objects to the bucket. Which statement about the encryption is correct?
This statement accurately describes AWS KMS envelope encryption, which is the standard mechanism for encrypting data in Amazon S3 using KMS. The Customer Master Key (CMK) never directly encrypts the large object data; instead, it is used to generate and encrypt a unique data key. This data key then performs the actual encryption of the S3 object, and its encrypted form is securely stored alongside the object within its metadata, enabling decryption later.
Why this answer
AWS KMS uses envelope encryption: when an object is written to S3 with SSE-KMS, KMS generates a unique data key from the CMK, encrypts the object with that data key, and then stores the encrypted data key alongside the object in S3. The CMK itself never directly encrypts the object data; it only encrypts the data key. This ensures that the CMK can be rotated without affecting the encrypted objects, as the encrypted data key remains decryptable by the new key material if the key ID is the same.
Exam trap
The trap here is that candidates often confuse the role of the CMK and the data key, mistakenly thinking the CMK directly encrypts the object (Option B), or they assume key rotation triggers re-encryption of existing data (Option C), when in fact envelope encryption decouples the key rotation from the stored ciphertext.
How to eliminate wrong answers
Option B is wrong because the CMK never directly encrypts the object data; AWS KMS uses envelope encryption where the CMK encrypts a data key, and that data key encrypts the object. Option C is wrong because key rotation creates new backing key material for the CMK but does not re-encrypt existing objects; the old backing key remains available for decryption, and objects encrypted before rotation are not automatically re-encrypted. Option D is wrong because while each object is encrypted with a unique data key, that data key is not stored alongside the object in plaintext; it is stored encrypted under the CMK, and the statement omits the critical detail that the data key is encrypted.
Refer to the exhibit. An IAM policy allows s3:GetObject for a bucket only from a specific IP range. A developer accesses the bucket from a laptop with IP address 192.0.2.55, but access is denied. What is the most likely reason?
This is the correct explanation. When a user interacts with AWS services through the AWS Management Console, the actual API requests to services like S3 are proxied through AWS's own infrastructure. Consequently, the `aws:SourceIp` condition in the IAM policy evaluates against the public IP address of the AWS service endpoint or proxy making the call, not the end-user's laptop IP address. If this AWS-owned IP falls outside the `192.0.2.0/24` range, the condition fails, and access is denied, even if the user's laptop IP is within the allowed range.
Why this answer
When a request is made via the AWS Management Console, the console itself acts as an intermediary. The console's requests originate from AWS service IPs, not the user's laptop public IP. Therefore, the `aws:SourceIp` condition in the IAM policy evaluates against the console's IP, which is not in the allowed range, causing the denial even though the laptop's IP is valid.
Exam trap
The trap here is that candidates assume the laptop's public IP is always used for the request, forgetting that the AWS Management Console acts as a proxy, so the `aws:SourceIp` condition evaluates the console's IP, not the user's.
How to eliminate wrong answers
Option A is wrong because the question states the policy allows s3:GetObject from a specific IP range, and there is no mention or evidence of an explicit deny statement elsewhere; the most likely reason is the IP mismatch due to the console proxy. Option B is wrong because the `IpAddress` wrapper is the correct syntax for the `aws:SourceIp` condition key in an IAM policy; omitting it would cause a syntax error, not a logical denial. Option C is wrong because the laptop's IP address (192.0.2.55) is within the allowed range as described in the scenario, so the denial must stem from the request not using that IP.
Refer to the exhibit. An IAM policy is attached to an IAM user. The user tries to upload a file to s3://my-bucket/confidential/report.pdf. What will happen?
AWS IAM policy evaluation logic dictates that an explicit Deny statement always takes precedence over any Allow statement, even if the Allow statement would otherwise grant the requested permission. In this scenario, despite an Allow for s3:PutObject, the presence of a Deny for the same action on the bucket ensures the upload operation is blocked. This fundamental rule prioritizes security by preventing unintended access, making the upload fail.
Why this answer
IAM policy evaluation logic dictates that an explicit Deny always overrides any Allow. In this scenario, the Deny statement denies `s3:PutObject` on the path `arn:aws:s3:::my-bucket/confidential/*`, which matches the user's upload target `s3://my-bucket/confidential/report.pdf`. Even though the Allow statement grants `s3:PutObject` on `arn:aws:s3:::my-bucket/*`, the explicit Deny takes precedence, causing the upload to fail.
Exam trap
The trap here is that candidates often assume an Allow statement alone determines access, forgetting that an explicit Deny in the same policy overrides any Allow, regardless of the order in which the statements appear.
How to eliminate wrong answers
Option B is wrong because the Deny statement applies to the user via the attached IAM policy, not to the bucket; IAM policies are resource-based and affect the user's permissions directly, so the Deny blocks the user's action. Option C is wrong because the policy does allow PutObject on that path via the Allow statement (`my-bucket/*` includes `my-bucket/confidential/report.pdf`), but the Deny overrides it. Option D is wrong because while the Allow statement grants PutObject, the explicit Deny on the same action and path overrides it, preventing the upload from succeeding.
Refer to the exhibit. A developer attached the IAM policy to a Lambda function's execution role. The function reads items from a DynamoDB table that uses AWS KMS customer managed key (CMK) for encryption at rest. When the function tries to read an item, it receives an access denied error. What is the cause?
AWS KMS employs a two-layer authorization model for Customer Managed Keys (CMKs), requiring both an IAM policy and the KMS key policy to grant access. While the provided IAM policy explicitly allows `kms:Decrypt` on all resources (`*`), the specific CMK's key policy might not include the calling principal or its account in its statement, thereby denying the final decryption permission required to access the DynamoDB data.
Why this answer
The IAM policy grants kms:Decrypt on all resources, but DynamoDB uses AWS KMS customer managed keys (CMKs) for encryption at rest. Even if the IAM policy allows the action, the CMK's key policy must also grant the Lambda execution role access to use the key. If the key policy does not include a statement allowing the Lambda role to perform kms:Decrypt, the request fails with an access denied error, regardless of the IAM policy.
Exam trap
The trap here is that candidates assume an IAM policy allowing kms:Decrypt on all resources is sufficient, forgetting that KMS customer managed keys have their own key policies that must also grant access.
How to eliminate wrong answers
Option A is wrong because the question explicitly states the table uses a KMS CMK for encryption at rest, so the table is encrypted. Option C is wrong because the IAM policy includes dynamodb:GetItem on the specific table ARN, so the action is allowed by IAM. Option D is wrong because the error is access denied, not resource not found (HTTP 404), and the question implies the table exists.
A Lambda function receives events from EventBridge. The developer wants failed invocations to be retried and then stored for later analysis if retries are exhausted. Which configuration should be used?
Configuring an EventBridge retry policy ensures that events are re-attempted if the initial Lambda invocation fails, improving resilience. Pairing this with a dead-letter queue (DLQ) for the EventBridge target is crucial. If all retries are exhausted and the Lambda function still fails to process an event, EventBridge will send that event to the specified DLQ, preventing data loss and allowing for subsequent investigation and reprocessing of failed events.
Why this answer
EventBridge supports a configurable retry policy (with a maximum event age up to 24 hours and up to 185 retries by default) and can route events that exceed the retry limit to an Amazon SQS dead-letter queue (DLQ). This ensures failed invocations are retried automatically and, if all retries are exhausted, the event is stored durably in the DLQ for later analysis or reprocessing.
Exam trap
The trap here is that candidates may confuse the Lambda function's own DLQ configuration (which applies to synchronous and asynchronous invocations) with EventBridge's rule-level retry policy and DLQ, but EventBridge manages retries and DLQ delivery independently of the Lambda service's built-in retry mechanism.
How to eliminate wrong answers
Option A is wrong because API Gateway access logging captures HTTP request/response data for REST or HTTP APIs, not Lambda invocation failures from EventBridge, and it does not provide retry or dead-letter storage. Option C is wrong because setting reserved concurrency to zero would prevent the Lambda function from executing at all, causing every invocation to fail immediately without retries or storage. Option D is wrong because CloudFormation outputs are used to export stack resource information (e.g., ARNs, endpoints) for cross-stack references, not for storing event data or handling failed invocations.
A CloudFormation update may replace an RDS database. The developer wants to preview replacement risk before executing. What should be created?
A CloudFormation change set provides a comprehensive preview of the proposed modifications that CloudFormation will make to your stack's resources before you execute an update. It explicitly lists which resources will be added, modified, or replaced, including critical resources like an RDS database. This allows you to review the exact impact, such as a potential database replacement, and confirm it aligns with your intentions before applying the update to your infrastructure.
Why this answer
A change set in AWS CloudFormation allows you to preview how proposed changes to a stack will be executed, including whether any resources will be replaced (e.g., an RDS database). By reviewing the change set, you can see if the update will cause replacement (indicated by 'Replacement: True') before you actually apply the changes, enabling risk assessment without modification.
Exam trap
The trap here is that candidates confuse a stack policy (which controls update permissions) with a change set (which provides a preview of changes), or they think monitoring tools like CloudWatch can predict infrastructure changes.
How to eliminate wrong answers
Option A is wrong because a stack policy only protects specified resources from being updated or deleted during a stack update; it does not provide a preview of replacement risk. Option C is wrong because a nested stack output is used to return values from a nested stack to the parent stack, not to preview update impacts. Option D is wrong because a CloudWatch dashboard is a monitoring tool for metrics and logs, not a mechanism to preview CloudFormation stack update behavior.
A developer is deploying a microservices application on Amazon ECS using Fargate. The application uses an Application Load Balancer (ALB) to distribute traffic. The developer needs to perform a blue/green deployment with automatic rollback if health checks fail. What should the developer use?
AWS CodeDeploy, when configured for blue/green deployments with Amazon ECS, provides a robust and automated solution for deploying new application versions. It creates a new 'green' environment with the updated tasks alongside the existing 'blue' environment, allowing for thorough testing before traffic is shifted. CodeDeploy manages the traffic routing via a load balancer and can automatically roll back to the stable 'blue' version if deployment health checks fail, ensuring minimal downtime and risk.
Why this answer
AWS CodeDeploy natively supports blue/green deployments for Amazon ECS, allowing you to specify a blue/green configuration that automatically shifts traffic from the old (blue) task set to the new (green) task set. It integrates with the ALB to perform health checks and can automatically roll back the deployment if the health checks fail, meeting the requirement without manual intervention.
Exam trap
The trap here is that candidates often confuse ECS service auto scaling or CloudFormation updates with deployment strategies, but neither provides the built-in blue/green traffic shifting and automatic health-check-based rollback that CodeDeploy offers.
How to eliminate wrong answers
Option A is wrong because ECS service auto scaling adjusts the number of tasks based on load, not the deployment strategy; it does not perform blue/green deployments or automatic rollback on health check failures. Option B is wrong because manually updating the ECS service via the AWS Management Console does not provide a built-in blue/green deployment mechanism or automatic rollback; it would require manual monitoring and intervention. Option C is wrong because AWS CloudFormation can update an ECS service with a new task definition, but it does not natively support blue/green deployments or automatic rollback based on health checks; it would require custom logic or additional resources to achieve this.
A company is using Amazon DynamoDB with on-demand capacity. A developer notices that write requests are being throttled during peak hours. What is the MOST effective way to resolve this issue?
Reviewing the partition key design and considering adding a suffix to distribute writes is the correct approach because even with On-Demand capacity, Amazon DynamoDB enforces per-partition throughput limits. A 'hot partition' occurs when a single partition key value receives a disproportionately high volume of write requests, exceeding its individual throughput capacity and leading to throttling for operations targeting that specific key. By adding a random or time-based suffix to the partition key, writes are effectively spread across multiple logical partitions, thereby distributing the load more evenly and mitigating the impact of hot spots.
Why this answer
DynamoDB on-demand mode automatically scales to accommodate traffic, so throttling during peak hours usually indicates a hot partition caused by an unevenly distributed partition key. Adding a suffix (write sharding) distributes writes across more partitions, eliminating the hot partition and resolving throttling without changing capacity mode.
Exam trap
DVA-C02 often tests the misconception that on-demand mode eliminates all throttling, when in fact hot partitions can still throttle and require partition key redesign or write sharding.
How to eliminate wrong answers
Option A is wrong because switching to provisioned mode with auto-scaling does not fix a hot partition; auto-scaling reacts to overall table capacity, not per-partition skew. Option B is wrong because on-demand mode does not have write capacity units to increase, and even in provisioned mode, increasing WCU would not help if a single partition key is throttled. Option D is wrong because the issue is write throttling, not read throttling, so increasing read capacity units is irrelevant.
Which TWO AWS services can be used to decouple components of a microservices architecture?
Amazon EventBridge is a serverless event bus service that enables event-driven architectures, significantly decoupling service components. It allows services to publish events to a central bus, which then routes them to various targets based on defined rules, without direct knowledge of the consumers. This pattern ensures producers and consumers operate independently, enhancing scalability, fault tolerance, and maintainability by eliminating direct point-to-point integrations.
Why this answer
Amazon EventBridge (Option B) is correct because it provides a serverless event bus that decouples microservices by allowing them to communicate asynchronously via events. Services publish events to EventBridge, and other services consume them without direct coupling, enabling loose coupling and scalability.
Exam trap
The trap here is that candidates often confuse Elastic Load Balancing (a synchronous traffic distributor) with asynchronous decoupling services, or mistakenly think Route 53's routing capabilities can decouple services, when in fact only message/event-based services like SQS and EventBridge achieve true decoupling.
A company uses AWS KMS to encrypt S3 objects. A developer needs to allow an IAM user to decrypt objects but not encrypt them. Which IAM policy action should be allowed?
The `kms:Decrypt` permission is essential for retrieving and accessing S3 objects that have been encrypted using AWS KMS. When an application attempts to download an S3 object encrypted with a KMS key, S3 internally requests the KMS service to decrypt the data key associated with that object. This action allows the S3 service, on behalf of the requesting principal, to decrypt the object's content and return it in plaintext.
Why this answer
The correct action is `kms:Decrypt` because the developer's requirement is to allow an IAM user to decrypt S3 objects but not encrypt them. AWS KMS uses separate permissions for encryption and decryption operations; `kms:Decrypt` specifically grants the ability to decrypt ciphertext without granting any encryption capabilities. By allowing only this action, the user can decrypt objects encrypted with the KMS key but cannot encrypt new data or perform any key management operations.
Exam trap
The trap here is that candidates often confuse `kms:Decrypt` with `kms:GenerateDataKey` or `kms:ReEncrypt`, mistakenly thinking those actions are required for decryption, when in fact they also enable encryption capabilities that violate the requirement.
How to eliminate wrong answers
Option B is wrong because `kms:GenerateDataKey` is used to generate a data key for client-side encryption, which involves creating both a plaintext key and an encrypted key; allowing this would enable the user to encrypt new data, violating the requirement to prevent encryption. Option C is wrong because `kms:Encrypt` directly allows the user to encrypt plaintext into ciphertext using the KMS key, which is explicitly prohibited. Option D is wrong because `kms:ReEncrypt` allows decrypting ciphertext and re-encrypting it under a different KMS key, which includes decryption capability but also introduces encryption operations, violating the restriction against encryption.
A developer is building a serverless application using AWS SAM. The application includes an Amazon API Gateway endpoint with a Lambda function that processes user uploads. The developer wants to enable API caching in the development stage to speed up repeated requests, but disable caching in the production stage. What is the most efficient way to achieve this?
This is the most robust and automated approach. The AWS::Serverless::Api resource in a SAM template can define Stage properties, including CacheClusterEnabled. By integrating a CloudFormation Condition that evaluates a StageName parameter, caching can be enabled specifically for the dev stage while remaining disabled for prod, all within a single, version-controlled template. This ensures consistent, environment-specific deployments via CI/CD pipelines.
Why this answer
AWS SAM extends AWS CloudFormation, allowing you to use CloudFormation conditions to conditionally enable the `CacheClusterEnabled` property on the `AWS::ApiGateway::Stage` resource. By defining a condition that evaluates to true only for the dev stage (e.g., based on a parameter like `StageName`), you can enable caching in dev and disable it in prod within a single SAM template, avoiding duplication and manual steps.
Exam trap
The trap here is that candidates may think caching must be configured per-deployment manually (Option C) or that separate templates are required (Option B), missing the power of CloudFormation conditions to conditionally enable features within a single SAM template.
How to eliminate wrong answers
Option B is wrong because creating two separate SAM templates introduces unnecessary duplication and maintenance overhead; the same effect can be achieved with a single template using CloudFormation conditions, which is more efficient. Option C is wrong because manually enabling caching in the API Gateway console after each deployment is error-prone, not repeatable, and violates infrastructure-as-code best practices; it also requires post-deployment steps that can be forgotten. Option D is wrong because using a custom CloudFormation resource to toggle caching is overly complex and introduces additional Lambda functions or custom logic when the native `CacheClusterEnabled` property combined with conditions already provides a straightforward, built-in solution.
A company runs an application on Amazon EC2 instances that need to read files from an Amazon S3 bucket. The developer must grant access to the S3 bucket without storing long-term credentials on the instances. Which approach should the developer use?
Attaching an IAM role to the EC2 instance profile lets the instance obtain temporary credentials automatically from the instance metadata service, which rotate regularly. This satisfies the stem's constraint of granting S3 read access without storing long-term credentials on the instances, unlike embedding access keys.
Why this answer
Using an IAM role attached to an EC2 instance profile allows the application to obtain temporary security credentials from the AWS Security Token Service (STS) via the instance metadata service. This eliminates the need to store long-term credentials on the instance, adhering to the principle of least privilege and improving security posture.
Exam trap
The trap here is that candidates may think storing credentials in environment variables or Secrets Manager is acceptable, but the question explicitly requires no long-term credentials on the instance, making the IAM role the only correct answer that leverages temporary credentials via the instance metadata service.
How to eliminate wrong answers
Option A is wrong because storing access key ID and secret access key in environment variables on the EC2 instance exposes long-term credentials that could be compromised if the instance is accessed or the environment is leaked, violating the requirement to avoid storing long-term credentials. Option C is wrong because an S3 bucket policy that grants access based on the EC2 instance's public IP address is not a secure or reliable method; public IPs can change (unless using an Elastic IP) and do not authenticate the instance's identity, plus S3 bucket policies support principal-based access, not IP-based for EC2 instances in this context. Option D is wrong because while AWS Secrets Manager securely stores credentials, the application would still need to retrieve and use long-term credentials at startup, which contradicts the requirement to avoid storing long-term credentials on the instance; using an IAM role is the preferred approach for EC2 instances.
A company wants to allow cross-account access to an S3 bucket in Account A from a role in Account B. The S3 bucket policy in Account A allows the role's ARN. However, access is denied. What is the most likely missing step?
For successful cross-account access, both the resource-based policy (S3 bucket policy) and the identity-based policy (IAM policy attached to the role in Account B) must explicitly grant the necessary permissions. While the bucket policy grants the Account B role permission to *assume* access to the bucket, the role itself must possess an IAM policy allowing it to perform specific S3 actions like `s3:GetObject` or `s3:PutObject`. This dual authorization model ensures granular control and adherence to the principle of least privilege.
Why this answer
Cross-account S3 access requires both a resource-based policy (the bucket policy in Account A) that grants access to the role ARN, and an identity-based policy (an IAM policy attached to the role in Account B) that explicitly allows the S3 actions. Without the IAM policy in Account B, the role lacks permission to perform the S3 operations, even though the bucket policy permits the access. This is a fundamental principle of AWS cross-account authorization: both the resource side and the principal side must grant the necessary permissions.
Exam trap
The trap here is that candidates often assume a bucket policy alone is sufficient for cross-account access, overlooking the requirement for an IAM policy on the requesting role to explicitly allow the S3 actions.
How to eliminate wrong answers
Option A is wrong because adding a bucket policy that denies access to all principals would explicitly block all access, including the intended cross-account access, making the problem worse. Option C is wrong because block public access settings are irrelevant to cross-account access via IAM roles; they only affect public access from the internet, not authenticated cross-account requests. Option D is wrong because enabling ACLs on the S3 bucket is not required for cross-account access; ACLs are a legacy access control mechanism and are not needed when using IAM policies and bucket policies, and they would not resolve the missing IAM policy issue.
A developer uses AWS SAM (Serverless Application Model) to define a serverless application. The developer wants to run the application locally for testing. Which AWS SAM CLI command should be used?
This command is specifically designed for local development and testing of serverless applications defined by AWS SAM. It emulates the API Gateway service on your local machine, creating HTTP endpoints that route requests to your Lambda functions running in a Docker container. This allows developers to test their API endpoints and Lambda logic without deploying to the AWS cloud, significantly accelerating the development cycle.
Why this answer
`sam local start-api` starts a local HTTP server that emulates the API Gateway endpoint and invokes your Lambda functions defined in the SAM template. This allows you to test API requests and responses locally without deploying to AWS, making it the appropriate command for local testing of a serverless application.
Exam trap
The trap here is that candidates confuse `sam build` or `sam package` as commands that also run the application locally, but these commands are solely for packaging and deployment preparation, not for local execution.
How to eliminate wrong answers
Option B is wrong because `sam build` is used to prepare the application for deployment by resolving dependencies and creating build artifacts, but it does not run the application locally. Option C is wrong because `sam deploy` deploys the application to the AWS cloud using CloudFormation, which is not a local testing command. Option D is wrong because `sam package` uploads the deployment artifacts to an S3 bucket and generates a packaged template, but it does not execute or test the application locally.
A company runs a web application on Amazon EC2 instances behind an Application Load Balancer (ALB). The application stores user session data in an Amazon ElastiCache for Redis cluster. Recently, users have been experiencing intermittent session timeouts and data loss. The developer examines the application logs and finds errors indicating that the Redis cluster is returning 'READONLY You can't write against a read-only replica.' The ElastiCache cluster is configured as a Redis replication group with one primary and two replicas. The application's connection code uses the primary endpoint. What is the most likely cause of this issue?
During a failover event in an ElastiCache for Redis replication group, one of the replicas is promoted to become the new primary, and the original primary node is demoted to a replica role. Redis replicas are configured by default to reject write operations, returning a READONLY error. If the application's client-side connection or cached endpoint still points to the old primary node, it will attempt to write to what is now a replica, resulting in the observed READONLY error.
Why this answer
The READONLY error occurs when attempting to write to a Redis replica node. In a replication group with one primary and two replicas, a failover event can promote a replica to become the new primary while the old primary becomes a replica. If the application's connection code uses the primary endpoint (which is a DNS name), DNS caching or a long TTL may cause the application to continue resolving to the old primary's IP address, now a replica.
Subsequent write requests to this replica will fail with the READONLY error, causing intermittent session timeouts and data loss. Option B correctly identifies this scenario. Option A is incorrect because scaling down to a single node would not produce this specific error.
Option C is incorrect because security groups would block all traffic, not just writes. Option D is incorrect because cluster mode (sharding) is unrelated to the primary-replica configuration causing the error.
A developer uses AWS CodePipeline to deploy a serverless application defined with AWS SAM. The pipeline consists of Source (S3), Build (CodeBuild), and Deploy (CloudFormation) stages. The developer wants to run integration tests after the stack is deployed but before the pipeline completes. Which approach should the developer use?
AWS CodePipeline is designed for continuous delivery, allowing developers to define multiple stages, including a dedicated 'Test' stage. Within this stage, an 'Invoke' action can be configured to execute an AWS Lambda function. This Lambda function can then contain the logic to perform various integration or end-to-end tests against the newly deployed serverless application, ensuring automated validation post-deployment. This approach fully automates the testing process within the pipeline.
Why this answer
AWS CodePipeline allows you to add a test stage after the Deploy stage, and you can configure an action that invokes an AWS Lambda function to run integration tests. This ensures tests run automatically after the CloudFormation stack is deployed but before the pipeline completes, meeting the requirement without manual intervention.
Exam trap
The trap here is that candidates may confuse CloudFormation Outputs with event-driven triggers or assume SAM has built-in post-deployment hooks, when in fact CodePipeline's custom action with Lambda is the correct mechanism for running automated tests after deployment.
How to eliminate wrong answers
Option B is wrong because CloudFormation stack Outputs are used to export values for cross-stack references, not to trigger Lambda functions; triggering Lambda from CloudFormation requires custom resources or event subscriptions, not Outputs. Option C is wrong because AWS SAM does not support post-deployment hooks in the SAM template; SAM uses lifecycle hooks (e.g., PreTraffic, PostTraffic) only for Lambda canary deployments, not for general integration testing. Option D is wrong because a manual approval step requires human intervention to run tests, which contradicts the requirement to run tests automatically before the pipeline completes.
A developer is deploying a serverless application using the AWS Serverless Application Model (SAM). The application consists of an API Gateway, a Lambda function, and a DynamoDB table. The developer wants to enable canary deployments for the Lambda function. What should the developer do?
This is the correct and most efficient method for enabling canary deployments with SAM. The AutoPublishAlias property in a SAM Lambda function resource automatically creates a new Lambda version and an alias pointing to it upon deployment, facilitating robust version management. The DeploymentPreference property then configures the traffic shifting strategy, including options for canary or linear deployments, automated rollback alarms, and pre/post-traffic hooks, all orchestrated by AWS CodeDeploy under the hood, enabling fully automated canary deployments.
Why this answer
The AWS SAM template supports canary deployments for Lambda functions by adding the `AutoPublishAlias` property (which automatically creates and publishes a new version to a Lambda alias) and the `DeploymentPreference` property (which defines the traffic-shifting strategy, such as `Canary10Percent5Minutes`). This enables CodeDeploy to gradually shift traffic from the current version to the new version without manual intervention.
Exam trap
The trap here is that candidates may think they need to manually create a Lambda alias or use CodePipeline for canary deployments, when in fact SAM's `AutoPublishAlias` and `DeploymentPreference` properties automate the entire canary deployment workflow via CodeDeploy.
How to eliminate wrong answers
Option A is wrong because CodeDeploy deployment groups are not directly configured in a SAM template; SAM abstracts this by generating the necessary CodeDeploy resources automatically when you use `DeploymentPreference`. Option B is wrong because manually creating a Lambda alias and configuring traffic shifting defeats the purpose of using SAM's built-in canary deployment support, which automates the entire process and integrates with CodeDeploy. Option D is wrong because AWS CodePipeline can orchestrate the overall CI/CD pipeline but is not required for canary deployments; SAM's `DeploymentPreference` property alone enables canary deployments without needing CodePipeline.
A developer is building a serverless application using AWS Lambda that processes messages from an Amazon SQS queue. The queue receives about 100 messages per second, and each message takes about 30 seconds to process. The Lambda function is configured with a reserved concurrency of 10. The developer notices that messages are frequently being sent to the dead-letter queue (DLQ) after three failed processing attempts. The Lambda function's execution role has the necessary permissions to read from the SQS queue and write to the DLQ. The SQS queue's visibility timeout is set to 60 seconds, and the Lambda function's timeout is set to 60 seconds. What is the most likely cause of the messages being sent to the DLQ?
A reserved concurrency of 10 means the Lambda function can only process 10 messages concurrently at any given time. If the incoming message rate from SQS significantly exceeds this limit, new Lambda invocations will be throttled. Messages that cannot be processed immediately will remain in the SQS queue, their visibility timeout will expire, and they will become visible again for another processing attempt. This cycle of retries continues, incrementing the ReceiveCount for each message, until the maxReceiveCount defined in the SQS queue's redrive policy is exceeded, at which point the message is moved to the Dead-Letter Queue.
Why this answer
With a reserved concurrency of 10, the Lambda function can process at most 10 messages concurrently. Since each message takes 30 seconds, the maximum throughput is about 10 messages per 30 seconds = ~0.33 messages per second, far below the incoming rate of 100 messages per second. Messages that are not processed will become visible again after the visibility timeout (60 seconds).
They will be retried, but due to the low concurrency, they will likely fail again, eventually exceeding the maxReceiveCount (default 3) and being sent to the DLQ. Option A is incorrect because long polling reduces empty responses but does not address the throughput limitation. Option C is incorrect because the 60-second timeout is sufficient for 30-second processing.
Option D is incorrect because the DLQ triggers after the maxReceiveCount, not after the first attempt.
An application running on Amazon ECS Fargate is experiencing intermittent connection timeouts when calling an external API. The task has a public IP and a security group that allows outbound HTTPS. What is the most likely cause?
ECS Fargate tasks deployed into a private subnet require a NAT Gateway to establish outbound connections to the internet. Private subnets are intentionally isolated from direct internet routing, meaning tasks within them cannot directly access external services or pull container images without an intermediary. A NAT Gateway, placed in a public subnet and configured with a route table entry for the private subnet, translates private IP addresses to its public IP, enabling secure and managed outbound internet access. This is the standard and necessary architecture for internet connectivity from private subnets.
Why this answer
ECS Fargate tasks running in a private subnet do not have direct internet access. Without a NAT gateway, outbound traffic to the external API is routed to the subnet’s route table, which lacks an internet gateway target, causing connection timeouts. The task’s public IP assignment is irrelevant in a private subnet, as the subnet itself has no route to the internet.
Exam trap
The trap here is that candidates assume a public IP on the task guarantees internet access, overlooking that the subnet’s route table determines whether traffic can reach the internet, and a private subnet without a NAT gateway blocks all outbound internet traffic regardless of the task’s public IP assignment.
How to eliminate wrong answers
Option A is wrong because the task already has a public IP assigned (as stated in the question), so the ECS service configuration for auto-assigning public IP is not the issue. Option B is wrong because inbound traffic rules are irrelevant for outbound HTTPS connections; the security group only needs to allow outbound traffic, which it does. Option C is wrong because the security group outbound rules are correctly configured to allow HTTPS (port 443), so misconfiguration is not the cause.
A developer is troubleshooting an AWS Lambda function that times out when processing large files from Amazon S3. The function has a 15-minute timeout and 512 MB memory. What should the developer do to resolve this issue?
Increasing the Lambda function memory to 3008 MB is a highly effective strategy for resolving timeout issues. In the AWS Lambda execution environment, the amount of allocated memory directly correlates with the proportional share of CPU power and network bandwidth provided to the function. By increasing memory, the function gains access to more computational resources, enabling it to process data faster, complete its tasks within the allowed timeout period, and improve overall performance for compute- or I/O-intensive workloads.
Why this answer
Increasing the Lambda function memory to 3008 MB is correct because Lambda allocates CPU proportionally to memory, and more CPU reduces processing time for CPU-bound tasks like file parsing. The 15-minute timeout is already the maximum, so the issue is insufficient compute resources, not timeout duration. With 512 MB, the function lacks the CPU throughput to process large files within the timeout, so boosting memory (and thus CPU) directly addresses the root cause.
Exam trap
The trap here is that candidates assume the 15-minute timeout is the problem and try to reduce it (Option C) or change invocation patterns (Option B), when the real issue is that Lambda's CPU allocation scales with memory, and insufficient memory leads to insufficient CPU for large file processing.
How to eliminate wrong answers
Option A is wrong because Amazon S3 Batch Operations are designed for bulk actions on existing objects (e.g., tagging, copying) and cannot split files before processing; splitting would require a separate preprocessing step, not a batch operation. Option B is wrong because adding an S3 Event Notification to trigger the function asynchronously does not change the function's execution environment or resource limits; it only changes invocation mode, and the function will still time out if it cannot process the file within the timeout. Option C is wrong because reducing the Lambda timeout to 5 minutes would make the problem worse—it would force the function to fail even faster, as it already times out at 15 minutes due to insufficient CPU.
A developer is building a serverless application that uses Amazon DynamoDB. The application needs to retrieve an item by its primary key frequently. Which DynamoDB API call should the developer use to achieve the lowest latency?
The GetItem operation is the most efficient and recommended method for retrieving a single item from a DynamoDB table. It directly accesses the item using its complete primary key (partition key, and sort key if applicable), resulting in minimal latency and consuming the fewest provisioned read capacity units (RCUs). This direct lookup mechanism makes it ideal for precise, single-item data retrieval.
Why this answer
The GetItem API call is the most efficient way to retrieve a single item by its primary key in DynamoDB, as it directly accesses the item using the hash key (and optionally the sort key) with consistent, single-digit millisecond latency. Unlike Scan or Query, GetItem does not need to evaluate any conditions or filter through other items, making it the lowest-latency option for this specific use case.
Exam trap
The trap here is that candidates often confuse Query with GetItem, assuming Query is always faster because it uses a key condition, but Query still requires evaluating the sort key and can return multiple items, whereas GetItem is the only API optimized for a single-item primary key lookup.
How to eliminate wrong answers
Option A is wrong because Scan reads every item in the table or index and then filters out the results, which incurs high latency and consumes significant read capacity, especially on large tables. Option B is wrong because Query retrieves all items with a given partition key value and can return multiple items, requiring additional processing and potentially higher latency than a direct key-based lookup. Option D is wrong because BatchGetItem is designed for retrieving multiple items in a single operation, but it adds overhead for batching and may return partial results, making it slower than GetItem for a single item retrieval.
A company has an S3 bucket that stores sensitive data. They want to ensure that any object uploaded to the bucket is automatically encrypted with server-side encryption using AWS KMS (SSE-KMS). They also want to deny any uploads that do not specify the correct encryption. Which bucket policy condition should be used to enforce this requirement?
This condition key directly inspects the `x-amz-server-side-encryption` request header, which clients must include to specify the desired server-side encryption method. By setting `aws:kms` as the required value, a bucket policy with a Deny effect ensures that any object uploaded to the S3 bucket *must* explicitly request Server-Side Encryption with AWS Key Management Service (SSE-KMS). This effectively enforces the use of KMS-managed keys for sensitive data at rest, preventing uploads that do not comply with this encryption standard.
Why this answer
The condition `s3:x-amz-server-side-encryption equals aws:kms` enforces that any PUT request to the S3 bucket must include the `x-amz-server-side-encryption` header set to `aws:kms`, which triggers SSE-KMS encryption. This policy condition ensures that objects uploaded without specifying SSE-KMS are denied, meeting the requirement to automatically encrypt all uploaded objects with AWS KMS.
Exam trap
The trap here is that candidates confuse the condition for specifying a particular KMS key ARN (Option C) with the condition for simply requiring SSE-KMS encryption, leading them to pick an overly restrictive policy that would break uploads using the default KMS key.
How to eliminate wrong answers
Option B is wrong because `AES256` corresponds to SSE-S3 (S3-managed keys), not SSE-KMS, so it would enforce the wrong encryption type. Option C is wrong because `s3:x-amz-server-side-encryption-aws-kms-key-id` enforces a specific KMS key ARN, but the question only requires SSE-KMS encryption, not a particular key; using this condition would be overly restrictive and could deny valid uploads using the default KMS key. Option D is wrong because `aws:SecureTransport` enforces HTTPS (TLS) for all requests, which is a transport-layer security requirement, not an encryption-at-rest requirement for object uploads.
The above CLI output shows the versioning status of an S3 bucket. A developer wants to enable MFA Delete on the bucket. What should the developer do?
Using `aws s3api put-bucket-versioning` with `--mfa` supplies the required authentication code alongside the versioning configuration, satisfying S3's rule that MFA Delete can only be enabled by the bucket owner via a signed request including both the MFA device serial and a valid code.
Why this answer
The `aws s3api put-bucket-versioning` command with the `--mfa` parameter is the correct way to enable MFA Delete on an S3 bucket. The `--mfa` parameter supplies the MFA token (serial number + code) required for this high-security operation, as MFA Delete can only be toggled by the bucket owner using multi-factor authentication.
Exam trap
The trap here is that candidates confuse MFA Delete with requiring MFA for access (via bucket policy) or assume Object Lock automatically enables MFA Delete, but MFA Delete is a distinct versioning setting that must be explicitly enabled using the `put-bucket-versioning` API with the `--mfa` parameter.
How to eliminate wrong answers
Option A is wrong because `put-bucket-acl` manages Access Control Lists (ACLs), not versioning or MFA Delete; MFA Delete is a versioning sub-feature, not an ACL property. Option C is wrong because Object Lock does not automatically enable MFA Delete; they are independent features — Object Lock provides write-once-read-many (WORM) protection, while MFA Delete requires explicit versioning configuration with an MFA token. Option D is wrong because `put-bucket-policy` sets resource-based IAM policies, not versioning or MFA settings; requiring MFA in a bucket policy controls access but does not enable the MFA Delete feature on the bucket itself.
A company uses AWS CodeDeploy to deploy a web application to an Auto Scaling group. The deployment fails with the error 'The overall deployment failed because too many individual instances failed deployment'. The deployment configuration is set to CodeDeployDefault.OneAtATime. What is the most likely cause of this failure?
CodeDeploy deployment configurations, such as `CodeDeployDefault.OneAtATime`, often specify a minimum healthy host threshold, which can be 100%. If a deployment fails on even a single instance due to issues like a failed lifecycle hook or an application startup problem, it immediately violates this strict healthy host requirement. This single failure is sufficient to cause the entire deployment to stop or roll back, triggering an error that indicates the minimum number of healthy hosts could not be maintained.
Why this answer
CodeDeployDefault.OneAtATime deploys to one instance at a time. The deployment stops immediately if a single instance fails, because the deployment configuration expects no failures. The error 'too many individual instances failed' is triggered by that single failure, since the deployment cannot proceed to the next instance without violating the minimum healthy hosts requirement, which is set to maintain availability.
Exam trap
The trap here is that candidates assume 'too many individual instances failed' means multiple instances failed independently, when in fact with OneAtATime a single instance failure is enough to fail the entire deployment because the minimum healthy hosts requirement is not maintained.
How to eliminate wrong answers
Option A is wrong because an unsupported operating system would cause a different error (e.g., 'Unsupported OS') and would affect all instances uniformly, not trigger a per-instance failure that cascades due to the OneAtATime configuration. Option B is wrong because changing to AllAtOnce would increase risk by deploying to all instances simultaneously, potentially causing a full outage; the error is not about the deployment speed but about the minimum healthy hosts requirement being violated. Option C is wrong because insufficient IAM permissions would typically result in an authorization error (e.g., 'AccessDenied') during the deployment setup or agent communication, not a per-instance failure that triggers the 'too many individual instances failed' message.
A company is using AWS CloudFormation to deploy infrastructure. The developer wants to create a custom resource that runs a Lambda function during stack creation and update. What must the developer do to ensure the custom resource works correctly?
When a CloudFormation custom resource invokes a Lambda function, CloudFormation provides a unique, time-limited S3 pre-signed URL within the event data. The Lambda function is absolutely required to send a JSON response to this specific URL, indicating the success or failure of the custom resource operation. This response mechanism allows CloudFormation to asynchronously track the status and retrieve any output attributes from the custom resource's execution, which is crucial for stack progression.
Why this answer
AWS CloudFormation custom resources require the Lambda function to send a response to an S3 pre-signed URL to signal completion. CloudFormation waits for this response to proceed with stack operations; without it, the stack creation or update will time out and fail.
Exam trap
The trap here is that candidates assume the Lambda function's return value is automatically captured by CloudFormation, but in reality, the function must explicitly send a response to the pre-signed URL to signal completion.
How to eliminate wrong answers
Option B is wrong because the Lambda function does not need to be defined in the same CloudFormation template; it can be referenced via an ARN from another stack or account. Option C is wrong because the Lambda function must send a response to the pre-signed URL using an HTTPS PUT request, not simply return a JSON object from the function invocation. Option D is wrong because the Lambda function can be written in any supported runtime (e.g., Node.js, Python, Java, Go), not exclusively Python.
A company uses AWS Elastic Beanstalk to run a web application. They want to deploy a new version with zero downtime and roll forward if successful. They have two environments: a production environment (current version) and a staging environment (new version). After verifying the staging environment, they want to swap the URLs so that production now points to the new version. Which deployment strategy should they use?
Blue/green deployment with environment CNAME swap is the most robust strategy for zero-downtime deployments and easy rollback. It involves creating a completely new, separate Elastic Beanstalk environment (the "green" environment) running the new application version, while the existing "blue" environment continues to serve traffic. After thorough testing of the green environment, the CNAME record of the load balancer is atomically swapped, redirecting all traffic to the new environment instantly. This approach ensures the new version is fully validated before going live and allows for immediate rollback by swapping the CNAME back.
Why this answer
Blue/green deployment with an environment CNAME swap allows you to run two separate Elastic Beanstalk environments (production and staging) simultaneously. After verifying the new version in the staging environment, you swap the CNAME records so that the production URL points to the staging environment, achieving zero downtime and a roll-forward strategy. This approach decouples the deployment from the existing environment, ensuring no disruption to live traffic during the swap.
Exam trap
The trap here is that candidates confuse immutable deployments (which also launch new instances) with blue/green deployments, but immutable deployments do not create a separate environment with its own URL for a CNAME swap, making them unsuitable for the described two-environment swap requirement.
How to eliminate wrong answers
Option B (All at once deployment) is wrong because it deploys the new version to all instances simultaneously, causing downtime during the deployment process and not allowing a roll-forward strategy with separate environments. Option C (Rolling deployment with additional batch) is wrong because it updates instances in batches while keeping the same environment, which can cause temporary capacity reduction and does not provide a separate staging environment for verification before swapping URLs. Option D (Immutable deployment) is wrong because it launches a new set of instances in the same environment and then swaps them in, but it does not create a separate environment with its own URL for a CNAME swap; it still operates within a single environment, making it unsuitable for the described two-environment swap scenario.
Amazon API Gateway's request validation feature allows developers to define a JSON schema for the request body, as well as specify required headers, query string parameters, and path parameters. This mechanism ensures that incoming requests conform to the API's expected structure and data types before they reach the backend integration. By rejecting malformed requests early, it enhances API security and reduces unnecessary processing by downstream services.
Why this answer
API Gateway's request validation feature allows you to define a JSON schema (using JSON Schema Draft 4) for the request body and automatically reject requests that do not conform before they reach the backend. This offloads validation from the Lambda function, reducing cold start overhead and ensuring only valid payloads are processed. The developer can configure this in the API Gateway console or via the OpenAPI specification.
Exam trap
The trap here is that candidates often confuse request validation with mapping templates, assuming that mapping templates can validate the request body, but mapping templates only transform data and do not enforce schema constraints.
How to eliminate wrong answers
Option B is wrong because mapping templates transform the request body or parameters into a different format (e.g., from JSON to XML) for the backend, but they do not perform schema-based validation. Option C is wrong because the integration request defines how API Gateway passes the request to the backend (e.g., HTTP method, headers, query strings) and can include mapping templates, but it does not natively validate the request body against a JSON schema. Option D is wrong because stage variables are key-value pairs used to configure deployment stages (e.g., Lambda function aliases, endpoint URLs) and have no role in request body validation.
A company uses AWS CodePipeline to deploy a static website to Amazon S3. The pipeline includes a deploy action that uses AWS CloudFormation to create the S3 bucket and upload files. The developer notices that the deploy action fails intermittently with a 'BucketAlreadyExists' error. What is the most likely cause?
S3 bucket names are globally unique across all AWS accounts and regions, acting as a universal namespace. Therefore, if any other AWS account, anywhere in the world, has already registered a bucket with the exact name specified in the CloudFormation template, the creation attempt will fail. The `BucketAlreadyExists` error precisely indicates this global naming conflict, preventing the new bucket from being provisioned.
Why this answer
The 'BucketAlreadyExists' error occurs when an S3 bucket name is globally unique across all AWS accounts. If the bucket name specified in the CloudFormation template has already been claimed by another AWS account, the deployment will fail intermittently if the bucket is deleted and recreated or if the pipeline runs in a different region where the name is taken. This is a common issue when using hardcoded or non-unique bucket names.
Exam trap
The trap here is that candidates often confuse 'BucketAlreadyExists' with permission or policy errors, but AWS specifically tests the global uniqueness constraint of S3 bucket names as a distinct failure mode in deployment pipelines.
How to eliminate wrong answers
Option A is wrong because enabling versioning on an S3 bucket does not cause a 'BucketAlreadyExists' error; versioning affects object version management, not bucket creation. Option B is wrong because incorrect IAM permissions would result in an 'AccessDenied' error, not a 'BucketAlreadyExists' error, as the CloudFormation service would fail to call the S3 CreateBucket API due to lack of authorization. Option D is wrong because a restrictive bucket policy would cause errors during object uploads or access, not during bucket creation; the 'BucketAlreadyExists' error occurs at the bucket creation step, before any policy is evaluated.
A developer is writing a Lambda function in Node.js that reads a secret from AWS Secrets Manager on every invocation. The function runs frequently, and the developer wants to minimize both latency and the number of Secrets Manager API calls. Which approach should the developer take?
Variables declared outside the handler persist across warm invocations of the same execution environment. Fetching the secret once and reusing the cached value reduces Secrets Manager calls and avoids repeated network latency on subsequent warm invocations while still working correctly on cold starts.
Why this answer
Declaring the secret variable in the global scope and populating it inside the handler lets warm Lambda execution environments reuse the value across invocations. This minimizes Secrets Manager GetSecretValue calls and latency while preserving correct behavior on cold starts, when the variable is repopulated.
Exam trap
The trap here is assuming that any code inside the Lambda handler runs only once per function, when in fact the handler runs on every invocation while global scope persists across warm starts.
Drag and drop the steps to create a Lambda function that processes S3 events in the correct order.
Drag or tap steps into the slots.
Why this order
First set up permissions, then code, create function, configure trigger, and test.
A company wants to encrypt data in transit between an EC2 instance and an S3 bucket. What should they do?
S3's HTTPS endpoints wrap every API call in TLS, encrypting the request and response payloads end-to-end between the EC2 instance and S3, which directly and completely satisfies the requirement to encrypt data in transit with no additional configuration needed.
Why this answer
Data in transit between EC2 and S3 is encrypted by using the S3 HTTPS endpoint for all API calls, which uses TLS/SSL to encrypt the connection. Option A is incorrect because S3 does not support SSH transfers; SSH is used for secure shell access, not for S3 API calls. Option B is incorrect because S3 does not support VPN connections; VPN is used for network-level encryption between on-premises networks and AWS, not directly between EC2 and S3.
Option C is incorrect because client-side encryption encrypts data before sending, but it does not address encryption in transit; HTTPS is the standard for in-transit encryption, and client-side encryption is for data at rest on the client side.
A developer needs to grant an IAM role in Account B read-only access to objects in an S3 bucket in Account A. The bucket is encrypted with server-side encryption using AWS KMS (SSE-KMS) with a customer managed key (CMK) in Account A. Which combination of policies is required for the cross-account access to succeed?
All three policies are required: bucket policy and key policy in Account A grant the necessary permissions, and the IAM role in Account B must have the corresponding IAM policy to authorize the use of those grants.
Why this answer
Cross-account access to an SSE-KMS encrypted S3 bucket requires three layers of permissions: the bucket policy in Account A must grant s3:GetObject to the IAM role in Account B, the KMS key policy must grant kms:Decrypt to the same role, and the role's IAM policy in Account B must allow both s3:GetObject and kms:Decrypt. Without any one of these, the request will fail due to either an S3 authorization error or a KMS decryption failure.
Exam trap
The trap here is that candidates assume bucket and key policies alone are sufficient for cross-account access, forgetting that the requesting principal (the IAM role) must also have an IAM policy that explicitly allows the required actions.
How to eliminate wrong answers
Option B is wrong because SSE-KMS with a customer managed key (CMK) requires explicit kms:Decrypt permissions; AWS managed keys are not used here, and omitting KMS permissions will cause a 'KMS.AccessDeniedException' when the role tries to read encrypted objects. Option C is wrong because the role in Account B must have an IAM policy that allows s3:GetObject and kms:Decrypt; bucket and key policies alone cannot grant permissions to a principal in another account—the role's trust policy and IAM permissions are necessary to authorize the action. Option D is wrong because KMS is always involved when SSE-KMS is used; the bucket is encrypted with a CMK, not the default KMS key, and the role must have kms:Decrypt permissions to decrypt the objects.
A developer runs the AWS CLI command to decrypt a file using a KMS key. What is the most likely cause of the error?
An AccessDeniedException from KMS Decrypt specifically means the calling principal's IAM policy or the KMS key's resource policy (key policy) does not grant kms:Decrypt on that key — KMS enforces both the identity-based policy and the key policy, and either one missing the grant results in exactly this authorization failure.
Why this answer
The IAM user DevUser does not have kms:Decrypt permission on the specified KMS key.
An IAM policy is attached to an EC2 instance role. The instance is part of a CodeDeploy deployment group. The deployment fails because the CodeDeploy agent cannot download the revision. What is the most likely reason?
This policy statement correctly identifies a common issue: the CodeDeploy agent needs explicit `s3:GetObject` permissions for the *exact* S3 bucket and path where the application revision is stored. If the IAM policy only grants access to a generic bucket like 'my-bucket', but the actual deployment package resides in a different bucket, such as 'another-bucket', the agent will be unable to download the necessary files, causing the deployment to fail due to an access denied error.
Why this answer
The CodeDeploy agent on the EC2 instance downloads the application revision from an S3 bucket. For this to succeed, the IAM role attached to the instance must include an s3:GetObject permission on the specific bucket and object. Without it, the agent cannot retrieve the revision file, causing the deployment to fail.
Options A and B are irrelevant because the agent does not call CodeDeploy API actions like GetDeployment or CreateDeployment; those are used by the user or CI/CD pipeline initiating the deployment. Option C is incorrect because IAM policies for S3 actions do not require a region in the resource ARN.
Exam trap
The trap here is that candidates confuse the permissions needed by the CodeDeploy agent (S3 read access) with the permissions needed by the user or pipeline (CodeDeploy API actions), leading them to select a CodeDeploy action instead of the correct S3 action.
How to eliminate wrong answers
Option A is wrong because the CodeDeploy agent does not call the codedeploy:GetDeployment action; that action is used by the AWS CLI, SDK, or console to retrieve deployment details. Option B is wrong because the codedeploy:CreateDeployment action is performed by the user or automation tool initiating the deployment, not by the CodeDeploy agent on the instance. Option C is wrong because S3 is a global service and its resource ARNs do not include a region element; specifying a region in an S3 ARN would be syntactically invalid.
A developer is troubleshooting an issue where an EC2 instance cannot access an S3 bucket. The instance has an IAM role with a policy that allows s3:GetObject on the bucket. Which TWO additional checks should the developer perform to resolve the issue?
An explicit deny statement within an S3 bucket policy takes precedence over any allow statements, including those granted by an IAM role attached to the EC2 instance. Even if the EC2 instance's IAM role has `s3:GetObject` permissions, a bucket policy explicitly denying access to that specific principal or IP range will override it, effectively blocking access to the S3 bucket. This is a critical aspect of AWS's authorization evaluation logic.
Why this answer
S3 bucket policies can explicitly deny access even if the IAM role attached to the EC2 instance grants s3:GetObject. An explicit deny in a bucket policy overrides any allow, so checking for such a deny statement is essential. Option E is correct because if the S3 bucket uses SSE-KMS encryption, the EC2 instance's IAM role must have kms:Decrypt permissions to decrypt the object; without it, GetObject requests will fail.
Exam trap
The trap here is that candidates often focus only on IAM policies or network controls (NACLs/security groups) and overlook the combination of bucket policies with explicit denies and KMS encryption permissions, which are common real-world blockers.
A developer is deploying a new version of an AWS Lambda function using the AWS CLI. The developer wants to ensure that the new version is stable before routing all traffic to it. The developer has already published version 1 and version 2 of the function. The developer wants to send 10% of the traffic to version 2 and 90% to version 1. The developer then plans to gradually increase the traffic to version 2. Which approach should the developer use?
A Lambda alias with routing configuration splits invocation traffic between two published versions by percentage, so 10% to version 2 and 90% to version 1 is achieved, then adjusted gradually. Aliases provide the weighted shifting that the scenario requires.
Why this answer
AWS Lambda aliases allow you to create a named reference to a specific function version and configure weighted routing between two versions. By creating an alias (e.g., 'prod') and setting its routing configuration to send 10% of traffic to version 2 and 90% to version 1, the developer can gradually shift traffic. This is the standard approach for canary deployments with Lambda.
The alias can be updated to adjust weights as confidence in the new version grows.
Exam trap
DVA-C02 often tests the confusion between Lambda versions and aliases, where candidates might think traffic weights can be set on versions directly, or that API Gateway is required for weighted routing.
How to eliminate wrong answers
Option A is wrong because Lambda versioning alone does not support traffic weights; weights are configured on aliases, not directly on versions. Option C is wrong because API Gateway can route traffic to different Lambda versions, but it requires more complex configuration and does not provide the native weighted alias feature; it is also not the simplest approach. Option D is wrong because it is essentially the same as option B but less specific; however, the key is that the alias must be created and then its routing configuration set.
Option D is not incorrect per se, but it is vague and does not specify the alias name or the exact configuration, whereas option B is precise and correct. In the context of the exam, option B is the best answer.
A company runs a web application on EC2 instances behind an Application Load Balancer (ALB). The application stores session data in an RDS MySQL database. Recently, users have reported that they are being logged out unexpectedly and their session data is lost. The developer investigates and finds that the RDS instance's CPU utilization spikes periodically, coinciding with the logout events. The application uses connection pooling via an RDS Proxy. The developer suspects that the session table is being dropped or truncated. After checking the application logs, the developer finds no evidence of truncation commands. The RDS instance has automated backups enabled, and the binary logs are retained for 24 hours. The developer wants to identify the root cause and prevent future occurrences. Which course of action should the developer take?
The MEMORY storage engine in MySQL stores all table data in RAM, providing extremely fast access but making the data volatile; any database restart, instance reboot, or crash will result in the complete loss of all data within these tables. Conversely, the InnoDB storage engine is ACID-compliant, writes data to disk, and includes robust crash recovery mechanisms, ensuring data persistence even after unexpected shutdowns. Changing the session table's engine to InnoDB directly addresses the problem of data loss upon restarts by making the data durable.
Why this answer
The MEMORY storage engine in MySQL stores table data in RAM and loses all rows when the MySQL server restarts (e.g., during a crash, failover, or maintenance). The periodic CPU spikes and session loss without any TRUNCATE/DROP in the logs strongly indicate the session table is using MEMORY and being wiped on restart. Converting the table to InnoDB persists data to disk and survives restarts, resolving the issue.
Exam trap
DVA-C02 often tests the MEMORY storage engine's volatility — candidates focus on CPU spikes and failover, missing that the real issue is a non-persistent storage engine losing data on restart.
How to eliminate wrong answers
Option A is wrong because Multi-AZ improves availability during failover but does not prevent data loss if the table uses a non-persistent storage engine — the data would still be lost on the standby. Option B is wrong because increasing instance size addresses CPU spikes but does not fix the root cause of session data loss; the MEMORY engine would still lose data on restart. Option C is wrong because RDS Proxy is not the cause of session loss; disabling it would not prevent the MEMORY table from being cleared on restart and would remove a useful connection-pooling feature.
A developer is configuring a load balancer in front of an EC2 instance running a web application. The application needs to authenticate users via an identity provider. Which AWS service should the developer use to handle authentication and authorization?
Amazon Cognito provides user pools that handle sign-up, sign-in, and access control for web and mobile application users, including integration with third-party identity providers and social logins, and it issues JSON Web Tokens that a load balancer's built-in authentication action can validate before forwarding requests to the EC2 target, making it the purpose-built service for this use case.
Why this answer
Amazon Cognito is designed to handle user authentication and authorization for web and mobile applications. It provides user pools for sign-up/sign-in and identity pools for federated identities, allowing integration with external identity providers (IdPs) like Google, Facebook, and SAML. Since the application needs to authenticate users via an identity provider, Cognito is the correct choice.
Exam trap
DVA-C02 often tests the distinction between IAM (for AWS service access) and Cognito (for application user authentication), so candidates may incorrectly choose IAM when the question involves end-user authentication.
How to eliminate wrong answers
Option A is wrong because AWS IAM is used for managing access to AWS resources and services, not for authenticating end-users of an application. Option C is wrong because Amazon Route 53 is a DNS web service that routes end-users to internet applications, not an authentication service. Option D is wrong because Amazon CloudFront is a content delivery network (CDN) that speeds up distribution of static and dynamic web content, not an identity provider.
A company uses AWS CloudFormation to manage its infrastructure. The developer wants to update a stack but only if the update does not cause any resource replacement. Which CloudFormation stack update option should be used?
Creating a change set allows you to preview the exact modifications CloudFormation will perform on your stack before applying them. The change set details which resources will be added, modified, or, critically, replaced, along with the specific properties that trigger these actions. By reviewing this detailed summary, administrators can identify and adjust the template to avoid unintended resource replacements, ensuring a controlled and predictable update process.
Why this answer
A change set allows you to preview the changes that CloudFormation will make to your stack, including whether any resources will be replaced. By reviewing the change set, you can see if any resource replacement is listed and choose not to execute it if you want to avoid replacements. This gives you full control to update the stack only when no replacements are required.
Exam trap
The trap here is that candidates may confuse change sets with direct updates, thinking that direct updates also provide a preview, or they may invent fictional options like 'Force rollback' or 'Preserve stack settings' that sound plausible but are not part of the CloudFormation service.
How to eliminate wrong answers
Option A is wrong because the direct update option immediately applies the template changes without any preview, so you cannot know in advance whether resource replacement will occur. Option C is wrong because the 'Force rollback' option is not a standard CloudFormation feature; rollback is triggered automatically on update failure, not used to prevent replacement. Option D is wrong because there is no 'Preserve stack settings' option in CloudFormation; this is a fictional option that does not exist in the AWS API.
A developer is building a serverless application using AWS Lambda functions that need to read and write to an Amazon DynamoDB table. What is the best practice for granting the Lambda function access to DynamoDB?
The standard and most secure method for a Lambda function to interact with other AWS services, such as DynamoDB, is by assuming an IAM execution role. This role requires a trust policy allowing `lambda.amazonaws.com` to assume it, and an attached permissions policy explicitly granting the necessary DynamoDB actions. This mechanism provides temporary, scoped credentials, adhering to the principle of least privilege and ensuring secure access.
Why this answer
AWS Lambda functions require an IAM role (execution role) with a trust policy that allows Lambda to assume it, and a permissions policy that grants the necessary DynamoDB actions (e.g., GetItem, PutItem). This is the standard and secure method for granting permissions to Lambda, as it avoids hardcoding credentials and follows the principle of least privilege.
Exam trap
The trap here is that candidates confuse resource-based policies (used for Lambda function invocation permissions) with execution roles (used for granting the Lambda function access to other AWS services), leading them to incorrectly choose Option C.
How to eliminate wrong answers
Option B is wrong because storing IAM user access keys in Lambda environment variables is insecure and violates best practices; keys can be exposed in logs or through the console, and they do not automatically rotate. Option C is wrong because Lambda functions do not support resource-based policies for granting access to other AWS services like DynamoDB; resource-based policies are used for cross-account access to the Lambda function itself, not for the function to access external resources. Option D is wrong because a VPC role or VPC endpoint does not grant IAM permissions; VPC endpoints enable private network connectivity but do not replace the need for an IAM role with DynamoDB access policies.
A developer needs to securely store database credentials for a serverless application. Which service should be used?
Secrets Manager is purpose-built for credentials like database usernames and passwords: it encrypts secrets at rest with KMS, supports automatic rotation via built-in Lambda rotation functions for RDS/Aurora/DocumentDB, and integrates natively with Lambda through the SDK or a caching layer extension for fast, secure retrieval.
Why this answer
AWS Secrets Manager is purpose-built for storing, rotating, and retrieving secrets such as database credentials, with native integration to RDS rotation Lambdas and fine-grained IAM access. It encrypts secrets with KMS and supports automatic rotation, which is the key differentiator for credential storage.
Exam trap
DVA-C02 often tests the overlap between Parameter Store SecureString and Secrets Manager, baiting candidates who do not realize that automatic credential rotation is the decisive requirement that only Secrets Manager satisfies.
How to eliminate wrong answers
Option B is wrong because Systems Manager Parameter Store can store SecureString values but lacks built-in automatic rotation for database credentials and is better suited to configuration data than lifecycle-managed secrets. Option C is wrong because S3 is object storage with no native secret rotation, versioning of credentials, or fine-grained secret retrieval API, making it inappropriate and insecure for credentials. Option D is wrong because KMS is a key management service that encrypts data but does not store secrets itself; it is a building block used by Secrets Manager, not a credential store.
A developer must locally test a SAM-based Lambda function with an API event before deployment. Which tool command family is designed for this?
The AWS SAM CLI `local invoke` and `local start-api` commands are specifically designed for testing serverless applications locally. `sam local invoke` allows developers to execute a single Lambda function with a provided event payload, simulating a direct invocation. `sam local start-api` launches a local HTTP server that emulates Amazon API Gateway, enabling testing of Lambda functions integrated with API Gateway by making actual HTTP requests to the local endpoint, providing a comprehensive local testing environment for SAM-based applications.
Why this answer
The AWS SAM CLI provides the `local invoke` and `local start-api` commands specifically for testing Lambda functions locally with simulated API Gateway events before deployment. `sam local start-api` creates a local HTTP server that mimics API Gateway, allowing developers to send requests to their Lambda functions as if they were deployed, while `sam local invoke` directly invokes the function with a specified event payload. This is the only tool family designed for local testing of SAM-based Lambda functions with API events.
Exam trap
The trap here is that candidates may confuse the AWS SAM CLI with other AWS CLI tools or services, mistakenly thinking that general-purpose CLI commands or unrelated security tools can perform local Lambda testing with API events.
How to eliminate wrong answers
Option B is wrong because AWS Shield Advanced CLI is a tool for managing DDoS protection services, not for testing Lambda functions or API events locally. Option C is wrong because AWS Organizations policy simulator is used to test IAM and SCP policies for multi-account environments, not for local Lambda or API Gateway testing. Option D is wrong because Amazon Inspector SBOM export is used to generate a software bill of materials for vulnerability assessment, not for testing Lambda functions or API events.
A company has an Amazon S3 bucket that stores sensitive documents. The security team wants to ensure that all GET requests to the bucket are authenticated and that the requester does not have public access. Which combination of S3 features should the developer implement?
This combination directly addresses the security of sensitive documents by preventing any public exposure. S3 Block Public Access is a critical account-level or bucket-level setting that overrides all other permissions, ensuring no object can be publicly accessed, regardless of bucket policies or ACLs. S3 Access Points, when configured with a network origin policy, allow granular control, restricting access to specific VPCs or IP ranges, further enhancing security by limiting the network attack surface while still enabling authenticated access for authorized users or applications within the defined network boundaries.
Why this answer
Blocking public access at the bucket level ensures that no anonymous or public requests can reach the bucket, while S3 Access Points with a network origin policy restrict access to requests originating from a specific VPC or on-premises network. This combination enforces that all GET requests must be authenticated (via the Access Point's IAM policies) and cannot come from public internet sources, meeting the security team's requirements.
Exam trap
The trap here is that candidates often confuse MFA Delete or encryption with authentication controls, not realizing that only explicit public access blocking combined with network-level restrictions (like Access Points) can prevent unauthenticated GET requests.
How to eliminate wrong answers
Option B is wrong because S3 Object Lock and versioning prevent object deletion or overwrite and maintain object history, but they do not control authentication or public access for GET requests. Option C is wrong because S3 Transfer Acceleration speeds up uploads over long distances and server-side encryption protects data at rest, neither of which authenticates requests or blocks public access. Option D is wrong because a bucket policy allowing only specific IAM users can restrict access, but MFA Delete only adds multi-factor authentication to delete operations, not to GET requests, and this combination does not inherently block public access from unauthenticated sources.
In a Lambda proxy integration, API Gateway expects the Lambda function's response to adhere to a specific JSON structure, including `statusCode`, `headers`, and a `body` field (which must be a string). If the Lambda function returns a response that deviates from this required format—for example, missing the `statusCode` or `body` fields, or if the `body` is not a string—API Gateway cannot properly parse it. Consequently, API Gateway will fail to construct a valid HTTP response for the client and will return a 500 Internal Server Error.
Why this answer
Lambda proxy integration requires the response to be in a specific JSON format: `{"statusCode": ..., "headers": ..., "body": ...}`. If the Lambda function returns a plain string or an object missing these keys, API Gateway cannot map it to an HTTP response, resulting in a 502 Internal Server Error. The successful business operation in logs confirms the Lambda code ran correctly, but the malformed response format causes the gateway error.
Exam trap
The trap here is that candidates see 'successful business operation' in logs and assume the Lambda is fine, overlooking that API Gateway proxy integration enforces a strict response contract, not just any valid return value.
How to eliminate wrong answers
Option A is wrong because a missing `dynamodb:PutItem` permission would cause a 403 Forbidden or 500 error from Lambda, not a 502, and the logs would show an access denied exception, not a successful operation. Option C is wrong because API cache TTL affects cached responses and latency, not the response format or 502 errors; a short TTL would cause more frequent cache misses, not gateway errors. Option D is wrong because enabling X-Ray tracing adds tracing headers and logs but does not alter the response format or cause 502 errors; it is purely a monitoring feature.
A developer is optimizing an AWS Lambda function that processes streaming data from Amazon Kinesis. The function is CPU-bound. Which TWO actions should the developer take to improve performance?
Rewriting the function in a compiled language such as Go can significantly improve performance due to its direct compilation into machine code, eliminating the need for a runtime interpreter during execution. This results in faster execution speeds, lower CPU utilization per task, and often reduced cold start times compared to interpreted languages like Python or Node.js. Go's efficient concurrency model further aids in optimizing resource-intensive operations.
Why this answer
Option A is correct because rewriting a CPU-bound Lambda function in a compiled language such as Go reduces execution time: Go compiles to native machine code, avoids the JIT warm-up and higher memory overhead of interpreted runtimes like Python or Node.js, and typically delivers significantly faster CPU throughput for the same work. Option C is correct because in AWS Lambda, CPU power scales proportionally with the configured memory allocation; increasing memory from, say, 512 MB to 1769 MB grants roughly one full vCPU, which directly speeds up CPU-bound processing. Option B is wrong because reserved concurrency only caps or guarantees the number of simultaneous invocations; it does not make any single invocation faster and can even throttle throughput if set too low.
Option D is wrong because increasing Kinesis shard count raises stream throughput and parallelism across records, but it does not accelerate the CPU-bound work inside one function invocation. Option E is wrong because AWS Lambda does not support GPU acceleration; GPU-backed compute requires services like Amazon EC2, ECS, or SageMaker.
Exam trap
DVA-C02 often tests the misconception that reserved concurrency or shard count improves per-invocation performance, when in fact only memory allocation (and runtime choice) affects CPU available to a single Lambda invocation.
A developer needs to store configuration parameters securely for a Lambda function. The parameters include database credentials and API keys. Which AWS service should be used?
AWS Secrets Manager stores database credentials and API keys as encrypted secrets, with native rotation via Lambda and fine-grained IAM access control. This directly satisfies the stem's requirement to store configuration parameters securely, unlike plaintext environment variables or unencrypted Parameter Store strings.
Why this answer
AWS Secrets Manager is the correct choice because it is purpose-built for securely storing, rotating, and managing sensitive configuration parameters such as database credentials and API keys throughout their lifecycle. It offers automatic rotation of secrets with built-in integration for Amazon RDS, Redshift, and DocumentDB, and enforces fine-grained access control via IAM policies. This makes it the most suitable service for the developer's requirement of securely storing and managing database credentials and API keys for a Lambda function.
Exam trap
The trap here is that candidates often confuse AWS Systems Manager Parameter Store (Option A) with Secrets Manager because both can store strings, but Parameter Store lacks automatic rotation and secret-specific lifecycle management, making it unsuitable for credentials that require regular rotation as per security best practices.
How to eliminate wrong answers
Option A is wrong because AWS Systems Manager Parameter Store is a general-purpose parameter store for configuration data like instance IDs or AMI IDs, but it lacks native automatic rotation of secrets and does not provide the same level of secret-specific features (e.g., cross-account access, versioning with staging labels) that Secrets Manager offers for sensitive credentials. Option C is wrong because Amazon DynamoDB with encryption is a NoSQL database service designed for storing application data, not for managing secrets; it requires custom code to handle secret rotation, access auditing, and lifecycle management, adding unnecessary complexity and security risk. Option D is wrong because Amazon S3 with server-side encryption is an object storage service that can store encrypted files, but it does not provide native secret rotation, automatic credential generation, or integration with AWS services like RDS for password management, making it a poor fit for dynamic secrets like database credentials and API keys.
Refer to the exhibit. A developer has the above IAM policy attached. The developer is trying to push code to a CodeCommit repository and trigger a CodePipeline. The push succeeds but the pipeline does not start. What is the most likely reason?
While the developer has permissions to push code, the automated trigger mechanism relies on a CloudWatch Events rule. This rule, when detecting a code push event, attempts to invoke CodePipeline. For this invocation to succeed, the CloudWatch Events rule itself must be associated with an IAM role that possesses "codepipeline:StartPipelineExecution" permissions on the target pipeline. Without this specific service-level permission, the rule cannot initiate the pipeline, even if the developer has their own permissions.
Why this answer
The pipeline is triggered by a CloudWatch Events rule that monitors code push events. For the rule to invoke the pipeline, it must have an IAM role with permission to start the pipeline. If that role is missing or lacks permissions, the pipeline won't start even though the developer has push permissions.
Option A is incorrect because the developer's policy allows GitPush, so push succeeds. Option C is incorrect because the developer has StartPipelineExecution permission, but that's not how the pipeline is triggered—it's an event-driven trigger. Option D is incorrect because CodeCommit does not require a trigger to be configured; the CloudWatch Events rule handles the event.
A company is using AWS CodePipeline to automate their CI/CD pipeline. The pipeline includes a stage that runs a set of integration tests using AWS CodeBuild. The tests require access to a database running on a private subnet in a VPC. The CodeBuild project is configured to use a managed compute image. How can the CodeBuild project access the database?
Configuring the CodeBuild project to use a custom VPC with the appropriate subnet and security group is the correct solution. This allows CodeBuild to launch its build environments directly within your specified Amazon VPC, enabling it to access private resources like an Amazon RDS database using their private IP addresses. By placing the CodeBuild environment in a private subnet and associating it with a security group that permits outbound traffic to the database's security group, secure and private network communication is established.
Why this answer
CodeBuild projects using managed compute images run in an AWS-managed VPC by default, which cannot access resources in a customer VPC. By configuring the CodeBuild project to use a custom VPC with the appropriate subnet and security group, the build environment is launched directly into that VPC, enabling it to reach the database on the private subnet without needing a NAT gateway or internet access.
Exam trap
The trap here is that candidates assume a NAT gateway or VPC peering is required to bridge network boundaries, but they overlook that CodeBuild's default environment is isolated from the customer VPC, and the correct solution is to launch the build directly into the customer VPC using a custom VPC configuration.
How to eliminate wrong answers
Option A is wrong because placing a CodeBuild project in a public subnet is not a valid configuration; CodeBuild projects are not assigned to subnets directly—they run in an AWS-managed environment unless a custom VPC is specified, and using a NAT gateway would not grant access to a private subnet from the managed VPC. Option C is wrong because VPC peering connects two VPCs, but the CodeBuild project's default environment is not in a customer VPC, so there is no VPC to peer with; even if a custom VPC were used, peering would be unnecessary since the database is already in the same VPC. Option D is wrong because VPC endpoints are used to privately connect to AWS services (e.g., S3, DynamoDB) via the AWS network, not to access a customer-managed database running on an EC2 instance or RDS in a private subnet.
A company is using AWS KMS to encrypt sensitive data stored in S3. The security team wants to ensure that only a specific IAM role can decrypt the data. What is the most secure way to achieve this?
A KMS key policy is the primary authorization mechanism for a Customer Managed Key (CMK), explicitly defining which IAM principals can perform cryptographic operations. Granting the `kms:Decrypt` permission to a specific role within the key policy directly enables that role to decrypt data encrypted by the CMK. This direct control over key usage is fundamental for fine-grained access management, ensuring only authorized entities can access sensitive data.
Why this answer
KMS key policies are the most direct and secure way to control who can perform cryptographic operations like kms:Decrypt on a specific CMK. By granting only the specific IAM role the kms:Decrypt permission in the key policy, you ensure that no other principal (including the root user or other roles) can decrypt the data, even if they have S3 access. This follows the principle of least privilege and decouples data access from infrastructure access.
Exam trap
The trap here is that candidates often confuse S3 bucket policies with KMS key policies, assuming that restricting S3 access is sufficient to prevent decryption, when in fact the KMS key policy is the only way to enforce decryption restrictions at the cryptographic level.
How to eliminate wrong answers
Option A is wrong because SSE-S3 uses S3-managed keys, which do not allow you to restrict decryption to a specific IAM role; any principal with S3 GetObject permission can decrypt the data. Option C is wrong because automatic key rotation only changes the backing key material over time for security hygiene, but does not restrict who can decrypt; it does not address access control. Option D is wrong because an S3 bucket policy can control access to the S3 object itself, but it cannot prevent decryption of the underlying KMS-encrypted data if the caller has both S3 GetObject and KMS Decrypt permissions; the KMS key policy is the authoritative control for decryption.
A development team is using AWS Elastic Beanstalk to deploy a web application. The team wants to perform a blue/green deployment. Which THREE steps are required to complete the blue/green deployment?
Elastic Beanstalk assigns each environment a CNAME (e.g., myapp-env.eba-123.us-east-1.elasticbeanstalk.com), and the 'Swap environment CNAMEs' action atomically exchanges the DNS names of the blue and green environments. This makes the new environment assume the old environment's URL, instantly redirecting all traffic to the green stack with zero downtime. It is the core traffic-shifting mechanism for blue/green on Elastic Beanstalk, and you can roll back by swapping the CNAMEs again.
Why this answer
Elastic Beanstalk blue/green deployment requires creating a completely new environment rather than updating the existing one, so option E (deploy the new application version to a separate Elastic Beanstalk environment) is correct because the new version must run in its own environment alongside the original. Option B (swap the CNAMEs of the two environments) is correct because Elastic Beanstalk's Swap Environment URLs feature exchanges the CNAMEs so that the environment URL users already use now resolves to the new environment, redirecting traffic without DNS changes. Option C (terminate the old environment after verifying the new environment) is correct because once the swap is validated and the new environment is healthy, the original environment is no longer needed and should be terminated to avoid unnecessary resource charges.
Option A is incorrect because updating the existing environment in place is a rolling/all-at-once deployment, not blue/green, and would not provide an instant rollback path. Option D is incorrect because Elastic Beanstalk blue/green uses the built-in CNAME swap rather than manually editing a Route 53 DNS record.
Exam trap
DVA-C02 often tests the confusion between in-place deployments and blue/green, or the misconception that you need to manually update Route 53 records instead of using the Elastic Beanstalk CNAME swap feature.
A developer needs to securely store database credentials for a Lambda function. The credentials must be automatically rotated every 30 days. Which service should be used?
AWS Secrets Manager is purpose-built for securely storing, managing, and retrieving sensitive information such as database credentials, API keys, and other secrets. Its primary advantage for database credentials is the automatic rotation capability, which integrates directly with various AWS services and databases to periodically change credentials without requiring application downtime. This service also provides fine-grained access control, auditing, and automatic encryption of stored secrets, making it the ideal solution for this requirement.
Why this answer
AWS Secrets Manager is the correct choice because it is specifically designed to securely store, manage, and automatically rotate database credentials and other secrets. It supports built-in rotation with AWS Lambda, allowing you to set a rotation schedule (e.g., every 30 days) without custom infrastructure. This service integrates directly with Amazon RDS, Redshift, and DocumentDB for seamless credential rotation.
Exam trap
The trap here is that candidates often confuse AWS Systems Manager Parameter Store (which can store secrets with encryption) with AWS Secrets Manager, but Parameter Store lacks native automatic rotation, making it unsuitable for the 30-day rotation requirement.
How to eliminate wrong answers
Option A is wrong because AWS KMS is a key management service for creating and controlling encryption keys, not for storing or rotating secrets like database credentials. Option C is wrong because AWS Systems Manager Parameter Store can store secrets but does not natively support automatic rotation of credentials; it requires custom Lambda functions and manual setup for rotation. Option D is wrong because AWS CloudHSM provides dedicated hardware security modules for cryptographic operations, not a service for storing or rotating application secrets.
A developer is building a microservices architecture using Amazon ECS with Fargate. The services need to communicate with each other. Which TWO AWS services can be used for service discovery?
AWS Cloud Map is a fully managed service discovery solution specifically designed for cloud-native applications, including microservices. It allows developers to register any application resource, such as containers, EC2 instances, or serverless functions, with custom names. Services can then discover the network locations of these registered resources using either API calls or standard DNS queries, making it highly flexible for dynamic environments.
Why this answer
AWS Cloud Map is a cloud resource discovery service that allows you to define custom names for your application resources and maintain the updated location of these dynamically changing resources. For Amazon ECS with Fargate, you can register each service instance with Cloud Map, and other services can then discover them via DNS queries or API calls, enabling seamless inter-service communication in a microservices architecture.
Exam trap
The trap here is that candidates often confuse Elastic Load Balancing (which handles traffic distribution) with service discovery, or they assume that any AWS service with 'registry' or 'store' in its name (like ECR or Parameter Store) can be used for discovering running services, when in fact only Cloud Map and Route 53 provide the necessary DNS and API-based discovery capabilities.
A company requires that all objects uploaded to an Amazon S3 bucket are encrypted at rest using server-side encryption with Amazon S3 managed keys (SSE-S3). The developer wants to enforce this with a bucket policy. Which condition key and value should be used in the policy to deny uploads that do not meet this requirement?
This condition key, "s3:x-amz-server-side-encryption", directly evaluates the "x-amz-server-side-encryption" header included in an S3 PUT request. Specifying "AES256" mandates the use of Server-Side Encryption with Amazon S3-managed keys (SSE-S3), ensuring that S3 automatically encrypts objects using the AES-256 algorithm before storing them. This is the precise and correct method within a bucket policy to enforce encryption at rest for all uploaded objects without requiring AWS KMS.
Why this answer
The condition key `s3:x-amz-server-side-encryption` with value `AES256` directly checks that the request header `x-amz-server-side-encryption` is set to `AES256`, which is the required value for SSE-S3. By using this condition in a bucket policy with a Deny effect, any upload that does not include this header or includes a different value (e.g., `aws:kms`) will be rejected, enforcing server-side encryption with Amazon S3 managed keys.
Exam trap
The trap here is that candidates often confuse the condition key for SSE-S3 (`s3:x-amz-server-side-encryption` with value `AES256`) with the condition key for SSE-KMS (`s3:x-amz-server-side-encryption-aws-kms-key-id`), or mistakenly think `aws:SecureTransport` enforces encryption at rest instead of in transit.
How to eliminate wrong answers
Option B is wrong because `s3:x-amz-server-side-encryption-aws-kms-key-id` is used to enforce a specific KMS key ID for SSE-KMS, not for SSE-S3; using `alias/aws/s3` would require SSE-KMS, not SSE-S3. Option C is wrong because `aws:SecureTransport` checks whether the request uses HTTPS (TLS), which enforces encryption in transit, not encryption at rest. Option D is wrong because `s3:object-lock-mode` is used to enforce S3 Object Lock governance mode, which prevents object deletion or overwrite, and has nothing to do with encryption at rest.
A developer needs to allow an Amazon EC2 instance to send messages to an Amazon SQS queue. What is the most secure way to grant this access?
Assigning an IAM role to the EC2 instance with appropriate SQS permissions is the recommended and most secure approach. When an IAM role is associated with an EC2 instance, applications running on that instance can automatically obtain temporary, frequently rotated security credentials via the instance metadata service. This eliminates the need to hardcode or store long-term credentials, significantly enhancing security and simplifying credential management.
Why this answer
The most secure way to grant an EC2 instance access to SQS is to attach an IAM role to the instance with a policy allowing sqs:SendMessage on the specific queue. IAM roles provide temporary credentials via the instance metadata service (IMDS), eliminating the need to store long-lived access keys on the instance.
Exam trap
DVA-C02 often tests the misconception that security groups or S3 bucket policies can be used as IAM principals — candidates must remember that only IAM identities (users, roles, accounts) can be principals in resource policies.
How to eliminate wrong answers
Option A is wrong because S3 bucket policies apply to S3 resources, not SQS, and cannot grant EC2 permissions to send messages to a queue. Option B is wrong because SQS resource-based policies can reference IAM principals (users, roles, accounts) but cannot reference a security group as a principal; security groups are network constructs, not IAM identities. Option D is wrong because creating an IAM user and embedding credentials in a configuration file exposes long-lived secrets that can be leaked, rotated poorly, and are not automatically rotated — this is an anti-pattern.
A developer is using Amazon DynamoDB for a new application. The developer wants to reduce read latency. Which design pattern should the developer use?
DynamoDB Accelerator (DAX) is a fully managed, in-memory cache specifically designed to sit in front of DynamoDB tables, providing microsecond read latency for frequently accessed items. By caching read-heavy workloads, DAX significantly reduces the response time for repeated requests, offloading the DynamoDB table and improving application performance for read-intensive operations.
Why this answer
DynamoDB Accelerator (DAX) is an in-memory cache designed specifically for DynamoDB, providing microsecond read latency for frequently accessed items. By caching read-heavy workloads, DAX offloads requests from the DynamoDB table, reducing read latency without requiring application-level caching logic. This directly addresses the developer's goal of reducing read latency.
Exam trap
The trap here is that candidates often confuse increasing provisioned capacity (Option B) with reducing latency, when in fact it only increases throughput, while DAX (Option D) directly addresses latency by caching reads in memory.
How to eliminate wrong answers
Option A is wrong because a Global Secondary Index (GSI) provides an alternative query pattern or sort key, but does not inherently reduce read latency; it may even add latency due to asynchronous replication. Option B is wrong because increasing provisioned read capacity units (RCUs) improves throughput (handling more requests per second) but does not reduce per-request latency, as DynamoDB's read latency is already low and consistent regardless of RCU level. Option C is wrong because DynamoDB Global Tables replicate data across regions for disaster recovery and low-latency reads in remote regions, but for a single-region application, it adds complexity and cost without reducing local read latency.
A company is running a monolithic application on an EC2 instance. The application currently stores session state in local memory on the instance. The company plans to scale the application horizontally by adding more instances behind a load balancer. What change is required to ensure that session state is preserved across requests?
Amazon ElastiCache provides a highly performant, in-memory data store, making it an ideal solution for externalizing session state. By storing session data in ElastiCache (e.g., Redis or Memcached), all EC2 instances can access a centralized, low-latency session store, enabling seamless horizontal scaling and high availability. This approach ensures that user sessions persist even if individual application instances are added, removed, or fail, promoting a truly stateless application design.
Why this answer
Amazon ElastiCache provides a managed, in-memory caching service (e.g., Redis or Memcached) that can store session state externally. By moving session data out of the EC2 instance's local memory and into a shared, low-latency data store, all instances behind the load balancer can access the same session state, ensuring persistence across requests regardless of which instance handles the request.
Exam trap
The trap here is that candidates often choose Option D (RDS) because they think a database is the only reliable external store, overlooking that ElastiCache is purpose-built for high-speed, ephemeral data like session state, while RDS introduces unnecessary latency and overhead for this use case.
How to eliminate wrong answers
Option A is wrong because Amazon S3 is an object storage service with high latency per request (typically 100-200 ms) and is not designed for frequent, sub-millisecond read/write operations required for session state; it would introduce unacceptable performance degradation. Option B is wrong because increasing the EC2 instance size only addresses vertical scaling (more sessions per instance) but does not solve the fundamental problem of session state being lost when a request is routed to a different instance in a horizontally scaled environment. Option D is wrong because Amazon RDS is a relational database with higher latency and connection overhead compared to in-memory caches; while it could technically store session state, it is not optimized for the high-throughput, low-latency access patterns of session management and would introduce unnecessary cost and complexity.
An application uses an Amazon SQS queue to decouple microservices. The producer is sending messages, but the consumer is not processing them. The consumer is an Auto Scaling group of EC2 instances. The SQS queue's ApproximateNumberOfMessagesVisible metric is increasing. What is the MOST likely cause?
If consumer instances are not actively making ReceiveMessage API calls to the SQS queue, messages sent by producers will accumulate indefinitely. The ApproximateNumberOfMessagesVisible metric will continuously increase because no consumers are retrieving messages, thereby preventing them from being moved to the in-flight state or deleted. This scenario directly and most likely explains a sustained increasing trend of visible messages.
Why this answer
If the ApproximateNumberOfMessagesVisible metric keeps rising while the consumer Auto Scaling group is running, the most likely cause is that the consumer instances are not polling the queue at all. Without active long-polling ReceiveMessage calls, messages accumulate and are never processed, even though the queue and permissions may be fine. This is the most direct explanation for a growing visible-message count with no consumption.
Exam trap
DVA-C02 often tests the distinction between a growing message backlog caused by consumers not polling versus one caused by visibility timeout or DLQ settings, and candidates frequently blame queue configuration instead of the consumer's polling behavior.
How to eliminate wrong answers
Option A is wrong because a queue policy denying access would cause the consumer to receive AccessDenied errors, which would typically surface in logs and could still show messages accumulating, but the question asks for the MOST likely cause and a policy denial is less common than a polling misconfiguration. Option C is wrong because a low visibility timeout causes duplicate processing, not a growing backlog with no processing. Option D is wrong because a DLQ only receives messages after maxReceiveCount failures; it does not prevent normal consumption and would not by itself cause a growing visible count.
A company uses AWS Elastic Beanstalk to deploy a web application. The developer wants to perform a blue/green deployment to minimize downtime. The developer creates a new environment and deploys the new version. After verifying the new environment is healthy, the developer needs to swap the URLs so that traffic is routed to the new environment. Which AWS Elastic Beanstalk feature should the developer use?
The 'Swap environment URLs' feature in Elastic Beanstalk is specifically designed for zero-downtime blue/green deployments. It atomically exchanges the CNAME records of two distinct environments, typically a 'blue' production environment and a 'green' new version. This ensures that traffic is seamlessly redirected to the new application version without any service interruption, making it ideal for deploying updates.
Why this answer
Use the 'Swap environment URLs' feature in the Elastic Beanstalk console. This feature swaps the CNAME records between two environments, allowing you to route traffic to the new, healthy environment with minimal downtime. Option B is not recommended because deleting the old environment before fully verifying the new one is risky.
Option C involves Route 53 weighted routing, which is not an Elastic Beanstalk feature and requires manual DNS management outside of Elastic Beanstalk. Option D is incorrect because environment CNAMEs are managed by Elastic Beanstalk and cannot be changed manually.
An organization has a Lambda function that processes messages from an Amazon SQS queue. The function is configured with a reserved concurrency of 5. The SQS queue has a visibility timeout of 30 seconds. The Lambda function takes an average of 45 seconds to process each message. What is the likely behavior of this setup?
This option correctly identifies the problem: if the SQS visibility timeout is configured to be shorter than the time required for the Lambda function to fully process a message, the message will become visible again in the queue. Consequently, another Lambda invocation, or even the same one after completing its current task, can retrieve and process the identical message. This leads to duplicate processing, which can cause data inconsistencies, increased costs, and unexpected application behavior.
Why this answer
The Lambda function takes 45 seconds to process a message, but the SQS queue's visibility timeout is only 30 seconds. Because the processing time exceeds the visibility timeout, the message will become visible again in the queue after 30 seconds and can be received by another Lambda invocation before the first one finishes. This leads to duplicate processing.
To prevent this, the SQS visibility timeout should be configured to be at least 6 times the Lambda function's timeout.
Exam trap
Candidates often mistakenly believe that AWS Lambda automatically manages or extends the SQS visibility timeout during execution. In reality, Lambda does not extend the timeout; it only deletes the message from the queue after the function successfully completes. If the function is still running when the visibility timeout expires, the message becomes visible to other consumers.
How to eliminate wrong answers
Option A is wrong because reserved concurrency of 5 limits the number of concurrent invocations, but it does not cause throttling here; the function is not being invoked beyond that limit. Option B is wrong because the mismatch between visibility timeout (30s) and processing time (45s) will cause messages to become visible again, leading to duplicate processing, not successful processing with no issues. Option D is wrong because Lambda does not automatically increase its processing speed; processing time is determined by the function's code and runtime, not by the invocation configuration.
A developer is using AWS CodePipeline with multiple actions in a stage. The pipeline has a build action that produces artifacts, followed by a deploy action. The developer wants to ensure that if the deploy action fails, the pipeline stops and does not continue to the next stage. How can they achieve this?
AWS CodePipeline is designed to inherently stop the entire pipeline execution immediately upon the failure of any action within any stage. This default behavior is crucial for maintaining the integrity of the CI/CD process, preventing the deployment of potentially faulty code or artifacts to subsequent environments. No explicit configuration is required to enable this safety mechanism, as it is a fundamental aspect of CodePipeline's operational design.
Why this answer
AWS CodePipeline stages are sequential by default: if any action within a stage fails, the entire stage fails and the pipeline stops, preventing execution of subsequent stages. No additional configuration is needed to halt the pipeline on a deploy action failure, as this is the inherent behavior of a pipeline stage with multiple actions.
Exam trap
The trap here is that candidates may overthink and assume they need to configure a special failure behavior, when in fact the default sequential pipeline execution already stops on any action failure.
How to eliminate wrong answers
Option A is wrong because CodePipeline does not support an 'Abort' action configuration; the only failure behaviors are 'Fail' (default) and 'Succeed' (to ignore the failure). Option B is wrong because 'runOrder' controls the execution order of actions within a stage, not a blocking mechanism on failure; setting it to 'Blocked' is not a valid value. Option D is wrong because setting the execution mode to 'PARALLEL' would cause actions in the stage to run concurrently, which does not affect the pipeline's stopping behavior on failure and could even allow other actions to continue after a failure.
Page 1 of 16
Page 2Practice DVA-C02 by domain
Target a specific domain to shore up weak areas.
See all domains with question counts →