Pass the Amazon Web Services AWS Certified Associate DVA-C02 Questions and answers with CertsForce

When a Lambda function is configured to run inside a VPC, it receives ENIs in the selected subnets and uses those subnets’ routing to reach other networks. If the function is placed in private subnets (common when it needs to access an RDS database in private subnets), it typically does not have a direct route to the internet. As a result, outbound calls to public external APIs will fail unless the VPC provides a controlled egress path.

The standard AWS networking pattern for private-subnet internet access is a NAT gateway (or NAT instance) deployed in a public subnet , with a route from the private subnet(s) to the NAT gateway (0.0.0.0/0 → NAT). The NAT gateway then uses an internet gateway attached to the VPC to reach the public internet while keeping the Lambda function (and the RDS database) in private address space. This resolves the connectivity issue while maintaining the security posture of private subnets.

Option A is not the solution: Lambda automatically provisions ENIs for VPC-enabled functions; manually provisioning an ENI does not provide internet access. Option C (security group outbound rules) is necessary but not sufficient—security groups control allowed traffic, but without a proper route to the internet (via NAT), the packets still cannot reach external endpoints. Option D (gateway VPC endpoint) is for AWS services like S3 and DynamoDB (gateway endpoints), not for arbitrary public internet APIs, and “in a public subnet” is not how gateway endpoints are used; they are associated with route tables.

Therefore, the correct solution is B : add a NAT gateway in a public subnet and update private subnet route tables so the new Lambda function can reach external public APIs while still accessing the private RDS database.

The key constraint is no changes to the Lambda code, while still fanning out notifications so that each department receives only its relevant file locations in its existing SQS queue. The cleanest “plumbing-only” pattern is S3 → SNS → SQS with SNS subscription filter policies.

Amazon S3 event notifications can publish events to an SNS topic. SNS then delivers messages to multiple subscribers, including SQS queues. By subscribing each department’s SQS queue to the SNS topic, the system can fan out the event to all queues. To ensure each department receives only its relevant events, the developer can configure SNS subscription filter policies (for example, based on object key prefixes like /deptA/, /deptB/). This routes messages without requiring any change to the Lambda function.

Option D is not ideal because S3 event notifications do not provide the same flexible filtering/routing to multiple SQS queues as SNS filter policies do (and configuring many direct notifications becomes harder to manage).

Options B and C require Lambda code changes, which violates the requirement.

Therefore, use S3 event notifications to SNS, subscribe each department SQS queue, and use filter policies for routing.

AWS Secrets Manager is a service that helps securely store, rotate, and manage secrets such as API keys, passwords, and tokens. The developer can store the API credentials in AWS Secrets Manager and retrieve them at runtime by using the AWS SDK. This solution will meet the requirements of security, code management, and performance. Storing the API credentials in a local code variable or an S3 object is not secure, as it exposes the credentials to unauthorized access or leakage. Storing the API credentials in a DynamoDB table is also not secure, as it requires additional encryption and access control measures. Moreover, retrieving the credentials from S3 or DynamoDB may affect application performance due to network latency.

This solution meets the requirements in the most operationally efficient manner because it does not require any infrastructure provisioning or management. The developer can create a Lambda function that makes the API call and configure an EventBridge rule that triggers the function once a day at a designated time. This is a serverless solution that scales automatically and only charges for the execution time of the function.

When using AWS SAM local (sam local invoke, sam local start-api), the Lambda code runs in a local container on the developer’s machine. If that code uses the AWS SDK to call AWS services, it needs AWS credentials available in the local environment. The recommended way is to rely on the AWS SDK’s standard credential provider chain, which includes credentials stored by the AWS CLI in ~/.aws/credentials and selected via a named profile .

By running aws configure --profile < profileName > , the developer creates a dedicated set of access keys (and optionally a session token/region) for the test account. Then, running SAM with sam local invoke --profile < profileName > causes SAM to supply those credentials to the local container so the function can authenticate to AWS and make real API calls in the intended test account. This approach is clean, repeatable, and avoids hardcoding secrets into templates or source code.

Option A is insecure and not the intended use of SAM templates; templates are infrastructure definitions, not secret stores. Option C sets the Lambda execution role for deployed functions in AWS, but it does not automatically grant credentials to code running locally on a laptop. Option D misuses --parameter-overrides, which is meant for overriding template parameters at deployment/build time, not for securely injecting AWS access keys into local execution.

Therefore, the correct approach is B : configure an AWS CLI profile and run SAM local with the --profile option so the Lambda code can call AWS APIs in the test account using standard credential handling.

This solution will meet the requirements by ensuring that all traffic between users and CloudFront, and all traffic between CloudFront and the web application, are encrypted using HTTPS protocol. The Origin Protocol Policy determines how CloudFront communicates with the origin server (the web application), and setting it to “HTTPS Only” will force CloudFront to use HTTPS for every request to the origin server. The Viewer Protocol Policy determines how CloudFront responds to HTTP or HTTPS requests from users, and setting it to “HTTPS Only” or “Redirect HTTP to HTTPS” will force CloudFront to use HTTPS for every response to users. Option A is not optimal because it will use AWS KMS to encrypt traffic between CloudFront and the web application, which is not necessary or supported by CloudFront. Option C is not optimal because it will set the origin’s HTTP port to 443, which is incorrect as port 443 is used for HTTPS protocol, not HTTP protocol. Option E is not optimal because it will enable the CloudFront option Restrict Viewer Access, which is used for controlling access to private content using signed URLs or signed cookies, not for encrypting traffic.

The requirements call for (1) standardized templates to define serverless infrastructure, (2) the ability to test locally before deployment, and (3) integrating deployment and infrastructure changes into an existing AWS CodePipeline workflow. AWS Serverless Application Model (AWS SAM) is designed specifically for serverless applications and extends CloudFormation with serverless-specific resources (such as AWS::Serverless::Function, APIs, event sources). SAM also provides the SAM CLI , which includes local testing capabilities (for example, sam local invoke and sam local start-api) that emulate Lambda and API Gateway behavior for rapid iteration before deployment.

Option A fits all requirements: create an AWS SAM template as the infrastructure definition and add pipeline stages that execute the necessary SAM CLI commands (commonly sam build and sam deploy, and optionally test commands) as part of the CI/CD process. This makes deployments repeatable and automated, ensures infrastructure changes are deployed in lockstep with application changes, and keeps everything governed by the existing CodePipeline.

Option D uses SAM but relies on a standalone script outside the pipeline, which conflicts with the requirement to incorporate infrastructure changes into the existing pipeline. Option C (plain CloudFormation) can define infrastructure, but it does not inherently provide the same streamlined local testing workflow that SAM CLI provides for serverless event sources and APIs. Option B is unrelated: Step Functions is an orchestration service and its definition language is not a general infrastructure templating and local-testing solution for serverless deployments.

Therefore, A is the correct strategy: use AWS SAM templates and integrate SAM CLI build/deploy steps into CodePipeline to automate deployments and support local testing while managing infrastructure as code.

This solution will meet the requirements by using AWS Config to monitor and evaluate whether Secrets Manager secrets are unused or have been deleted, based on specified time periods. The secrets manager-secret-unused managed rule is a predefined rule that checks whether Secrets Manager secrets have been rotated within a specified number of days or have been deleted within a specified number of days after last accessed date. The Amazon EventBridge rule will trigger a notification when the AWS Config managed rule is met, alerting the developer about unused secrets that can be removed without causing application downtime. Option A is not optimal because it will use AWS CloudTrail log file delivery to an Amazon S3 bucket, which will incur additional costs and complexity for storing and analyzing log files that may not contain relevant information about secret usage. Option C is not optimal because it will deactivate the application secrets and monitor the application error logs temporarily, which will cause application downtime and potential data loss. Option D is not optimal because it will use AWS X-Ray to trace secret usage, which will introduce additional overhead and latency for instrumenting and sampling requests that may not be related to secret usage.

Amazon API Gateway allows you to create, deploy, and manage a RESTful API to expose backend HTTP endpoints, AWS Lambda functions, or other AWS services1. You can use API Gateway to perform basic validation of an API request before proceeding with the integration request1. When the validation fails, API Gateway immediately fails the request, returns a 400 error response to the caller, and publishes the validation results in CloudWatch Logs1.

To test changes before deploying to a production environment, you can modify the existing API to add request validation and deploy the updated API to a new API Gateway stage1. This allows you to perform tests without affecting the production environment. Once testing is complete and successful, you can then deploy the updated API to the API Gateway production stage1.

This approach has the least operational overhead as it avoids unnecessary creation of new APIs or exporting and importing of APIs. It leverages the existing infrastructure and only requires changes in the configuration of the existing API1.

Requirement Summary:

Store customer orders in DynamoDB

Must encrypt data at rest

Company wants to use a key it generates (i.e., customer managed key)

Evaluate Options:

A. Set encryption to None, manually encrypt/decrypt in code

Overhead and error-prone

Also non-compliant with AWS encryption best practices

B. Use customer managed KMS key

Exactly meets the requirement: customer generates and controls the key

During table creation, you can specify a KMS CMK ARN

C. Default encryption + kms:Encrypt in SDK

Misunderstanding: DynamoDB handles encryption automatically

You don’t need to call kms:Encrypt manually in SDK

D. Use AWS managed key

Does not meet the requirement of using custom company-generated key

DynamoDB encryption: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html

KMS customer managed keys: https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk

The correct answer is C because Amazon SNS subscription filter policies are the native AWS feature for ensuring that only messages with matching attributes are delivered to a specific subscription. In this scenario, the Lambda function should process only refund messages from an SNS topic that contains multiple payment activity message types. By applying a subscription filter policy to the Lambda subscription, SNS delivers only the refund-related notifications to the function.

This is the most operationally efficient solution because filtering happens before invocation of the Lambda function. That means the Lambda function is not triggered for irrelevant payment events, which reduces unnecessary invocations, lowers compute cost, and simplifies the function code. AWS documentation recommends using subscription filter policies with SNS when subscribers should receive only a subset of messages based on message attributes.

Option A is incorrect because Lambda event filtering is available for some event sources, but for SNS-to-Lambda integration , the AWS-native filtering point is the SNS subscription itself. Option B is less efficient because it still invokes the Lambda function for every message and then discards non-refund messages in code. That increases operational overhead and cost. Option D is unrelated to the requirement because batching changes invocation behavior but does not filter by message type.

Therefore, the best design is to publish all payment activity events to SNS with appropriate message attributes and configure an SNS subscription filter policy so that only refund messages invoke the Lambda function. This approach is simple, scalable, and aligns with AWS event-driven architecture best practices.

Amazon Q Developer (formerly part of CodeWhisperer) is an AI-powered assistant integrated into IDEs (like VS Code or JetBrains). It can generate unit tests, explain code, and suggest improvements. Highlighting a specific function and asking the agent to generate a unit test is the fastest, lowest-effort way for a developer to test a function before committing code, as it happens directly within the development workflow.