Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in understanding Lambda’s default networking behavior and how it affects connectivity to resources in private subnets. In production, this is about knowing exactly how to configure Lambda networking and security groups to enable secure database access without exposing RDS publicly. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
BrightTech Solutions is building a serverless data processing system. The team has provisioned a VPC named BrightVPC which includes both public and private subnets. Inside the private subnet, they deployed an Amazon RDS MySQL database to store sensitive customer data.
The lead developer also created a Lambda function, but this Lambda function was deployed using the default Lambda VPC (which is outside BrightVPC).
When the Lambda function tries to execute queries against the RDS database, it consistently throws errors indicating it cannot establish a network connection.
The Requirement: #
You need to modify the architecture or configuration so that the Lambda function can successfully connect to the RDS database in the private subnet while maintaining network security best practices.
The Options #
-
A) Modify the RDS security group to allow inbound traffic from all ports originating from the entire VPC CIDR block.
-
B) Redeploy the Lambda function inside the same private subnet as the RDS instance and ensure the RDS security group allows inbound connections from the Lambda function’s security group.
-
C) Create a dedicated security group for the Lambda function, then add an inbound rule to the RDS security group that allows traffic from this Lambda security group.
-
D) Create an IAM role with a policy that grants access to the RDS database, then attach this role to the Lambda function.
Google adsense #
leave a comment:
Correct Answer #
C
Quick Insight: The Developer Imperative #
The key is network connectivity and security group configuration, not IAM policy for network access. Lambda functions outside the VPC cannot reach private subnet resources without VPC configuration. Assigning Lambda a dedicated security group and allowing it in the RDS SG is the secure and modern pattern.
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 #
The Lambda function by default runs in an isolated AWS-managed VPC (the “default Lambda VPC”) which has no direct route to your private VPC subnets. To allow your Lambda to access RDS inside your private subnet:
-
You must configure the Lambda function to run inside your VPC (
BrightVPC) by assigning it at least one subnet ID insubnetIdswhen configuring the function. -
When operating inside the VPC, the Lambda function is assigned one or more Elastic Network Interfaces (ENIs) with associated security groups.
-
The RDS security group must explicitly allow ingress from the Lambda’s ENIs—thus, creating a dedicated Lambda SG and adding it as a source CIDR or SG in RDS SG inbound rules is best practice. This avoids opening broad CIDR ranges and improves security posture.
IAM roles and policies (Option D) control authorization to AWS API actions and resources but do not impact TCP/IP network connectivity, so that alone cannot fix network reachability.
Simply redeploying Lambda in “the same subnet” (Option B) is incomplete without proper SG rules, and opening all ports from the VPC CIDR (Option A) is an overly broad and insecure approach.
The Trap (Distractor Analysis): #
-
Why not A? Opening all ports from the entire VPC CIDR exposes your database broadly, violating the principle of least privilege and increasing attack surface.
-
Why not B? While deploying Lambda inside the VPC is required, without appropriate security group rules that allow inbound from Lambda’s group, connectivity will fail.
-
Why not D? IAM policies do not control network traffic. You need networking and security group configuration, not permissions for RDS API calls.
The Technical Blueprint #
# CLI snippet to update Lambda config to run in your VPC with security group attached
aws lambda update-function-configuration \
--function-name MyLambdaFunction \
--vpc-config SubnetIds=subnet-0123456789abcdef0,SecurityGroupIds=sg-0abc123def456ghij
# Example security group rule allowing access from Lambda SG to RDS SG
aws ec2 authorize-security-group-ingress \
--group-id sg-0123456789abcdef0 \
--protocol tcp --port 3306 \
--source-group sg-0abc123def456ghij
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case / Notes |
|---|---|---|---|
| A | Low | Potentially insecure | Overly broad inbound rule, violates least privilege |
| B | Medium | Partial solution | Needs SG rules; “same subnet” alone insufficient |
| C | Medium | Optimal | Correct pattern: VPC connectivity + SG permissions |
| D | Low | No effect | IAM policy irrelevant for network connectivity |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick VPC configuration + security group rules when you see Lambdas needing database access inside private subnets.
Real World #
We often attach a Lambda-specific security group to isolate network access and precisely control traffic via SG inbound rules. Simply “giving permissions” with IAM has no effect on TCP-level connection.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.