Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For AWS DVA-C02 candidates, the confusion often lies in when and how to configure Lambda networking inside a VPC. In production, this is about knowing exactly how to properly attach security groups and subnet settings so Lambda can securely connect to Aurora without breaking isolation or connectivity. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
InnoTech Solutions is developing a serverless microservice that queries user profile data stored in an Amazon Aurora MySQL database. The Aurora database is deployed within a private subnet of InnoTech’s main VPC, named ProdVPC. The development team is tasked with creating an AWS Lambda function that must securely access the Aurora database to retrieve user information. The data is relational and sensitive, so security is paramount.
The Requirement: #
Design a Lambda function configuration that ensures secure, direct connectivity to the Aurora database residing in a private subnet within ProdVPC.
The Options #
- A) Create the Lambda function. Configure it for network access within ProdVPC. Attach a security group called SG-Lambda to both the Lambda and the Aurora DB instance. Set inbound and outbound rules on SG-Lambda to allow TCP traffic on port 3306 (MySQL).
- B) Create the Lambda function in a new public subnet inside a completely separate VPC named DevVPC. Establish a VPC peering connection between ProdVPC and DevVPC for connectivity to the Aurora DB.
- C) Create the Lambda function configured for ProdVPC access. Assign security group SG-Lambda to the Lambda function and a different security group SG-DB to the Aurora database. Add an inbound rule on SG-DB to accept TCP traffic from SG-Lambda on port 3306.
- D) Export Aurora data periodically to Amazon S3. Create the Lambda function within ProdVPC and have the function query the user data from S3 instead.
Google adsense #
leave a comment:
Correct Answer #
C
Quick Insight: The Lambda VPC Integration Imperative #
- For a Lead Developer: Understanding Lambda’s ENI attachment to the VPC subnets and careful security group design is critical to maintaining secure and reliable DB connectivity without exposing resources.
- Lambda must reside in the same VPC (ProdVPC) and security groups must explicitly allow database access — sharing a security group (option A) oversimplifies and can reduce least privilege, whereas separate SGs with inbound rules (option C) follow best practice.
- Peering to a different VPC with Lambda in a public subnet (option B) adds unnecessary complexity and latency.
- Exporting data to S3 (option D) changes the architecture and loses real-time access, violating the requirement.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option C
The Winning Logic #
- Assigning the Lambda function to the same VPC (ProdVPC) enables network-level access to Aurora.
- Applying separate security groups (SG-Lambda and SG-DB) allows fine-grained control.
- An inbound rule on SG-DB referencing SG-Lambda’s security group on port 3306 enforces principle of least privilege, allowing only Lambda’s ENIs to connect.
- This separation aids maintainability and security audits while avoiding over-permissive policies.
- Lambda’s ENIs will be created in the private subnet, enabling low-latency, secure access to Aurora without impacting public exposure.
The Trap (Distractor Analysis): #
- Why not Option A? Attaching the same security group to both Lambda and Aurora is functional but less secure. It grants broad access within that group, violating least privilege principles.
- Why not Option B? Creating Lambda in a separate VPC (DevVPC) adds complexity (VPC peering), network latency, and potential routing issues. Lambda accessing a private Aurora instance over peering is unnecessary complexity and poor design.
- Why not Option D? Exporting data to S3 and having Lambda query S3 is a fundamentally different architecture. It loses real-time data access, which goes against the scenario’s requirement for direct Aurora queries.
The Technical Blueprint #
# Example CLI snippet to assign Lambda to VPC and security groups (simplified)
aws lambda update-function-configuration \
--function-name user-profile-query \
--vpc-config SubnetIds=subnet-0abc12345def67890,SecurityGroupIds=sg-lambda123456
// Example SG-DB inbound rule allowing MySQL from Lambda SG
{
"IpProtocol": "tcp",
"FromPort": 3306,
"ToPort": 3306,
"UserIdGroupPairs": [
{
"GroupId": "sg-lambda123456"
}
]
}
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Low | High | Simple, but less secure SG setup |
| B | High (VPC Peering) | Moderate | Complex architecture, avoidable |
| C | Moderate | High | Best practice for VPC Lambda DB access |
| D | Low | Low | Indirect read-only access via S3 |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, always place Lambda inside the same VPC as the private database for direct access and use security groups with least privilege referencing.”
Real World #
“In production, we monitor Lambda ENI creation limits and cold start latencies when functions are VPC-enabled, and weigh that against connectivity and security needs.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.