DVA-C02 Exam Results

This solution will meet the requirements by allowing the Lambda functions to access the DB cluster securely within the same VPC without crossing the public internet. The developer can configure a VPC endpoint for RDS in a private subnet and assign it to the Lambda functions. The developer can also configure a security group for the Lambda functions that allows inbound traffic from the DB cluster on port 3306 (MySQL). Option A is not optimal because it will expose the DB cluster to public access, which may compromise its security and data integrity. Option B is not optimal because it will introduce additional latency and complexity to use an RDS database proxy for accessing the DB cluster from Lambda functions within the same VPC. Option C is not optimal because it will require additional costs and configuration to use a NAT gateway for accessing resources in private subnets from Lambda functions.

The company already has SSM Agent deployed on all servers, which enables centralized, scalable fleet operations without logging in to each instance. The most operationally efficient solution is to automate key distribution using Systems Manager Run Command, executing a script across the entire fleet (or a targeted subset) in one action.

Option B uses S3 as a simple distribution source and Run Command to perform the update at scale. The developer can store the required key material in a controlled S3 location and write a script that places the key in the correct filesystem path (with correct permissions/ownership), updates authorized_keys if needed, and restarts any services if required. Run Command can target instances by tags, resource groups, or instance IDs and provides execution logging and status.

Option A is not operationally efficient because it requires logging into each server manually.

Option C and D push the distribution burden to humans (“grant team members permissions to download”), which is error-prone, slow, and not scalable. Also, distributing private keys broadly to individuals increases risk.

AWS SAM provides built-in tooling to generate realistic event payloads that match the structure of events produced by AWS services (such as S3, SNS, SQS, API Gateway, EventBridge, and others). The command designed specifically for this purpose is sam local generate-event. It produces sample event JSON that mirrors the format AWS services deliver to Lambda, which meets the requirement that payload structures match real service events.

This approach also requires the least development effort because the developer does not need to manually craft and maintain JSON payload files. Instead, the developer can generate the appropriate event type with SAM, optionally tweak values (bucket name, object key, request parameters), and then run sam local invoke using the generated payload. This significantly reduces mistakes and saves time, especially when testing multiple event sources.

Why other options are less suitable:

A (shareable test events) is vague and typically still requires manual creation/maintenance.

B requires manually creating payloads, which is error-prone and higher effort.

C adds unnecessary operational overhead (S3 storage) and still relies on manual payload creation.

Therefore, using sam local generate-event is the quickest and lowest-effort way to generate accurate AWS-service-like test payloads for local Lambda testing.

The solution that will meet the requirements is to create an Amazon EventBridge rule that runs on a regular schedule to invoke the Lambda function. This way, the developer can use an automated and serverless way to invoke the function every 10 minutes. The developer can also use a cron expression or a rate expression to specify the schedule for the rule. The other options either involve using an Amazon EC2 instance, which is not serverless, or using environment variables or query parameters, which do not trigger the function.