Lambda RDS Private Connectivity Least Overhead

Answer Correct answer: C, D — Configure the Lambda function to run in the same subnet as the DB instance and attach the same security group to both resources.

A company uses Amazon RDS to store transactional data. The company runs an RDS DB instance in a private subnet. A developer wrote an AWS Lambda function with default settings to insert, update, or delete data in the DB instance. The developer needs to give the Lambda function the ability to connect to the DB instance privately without using the public internet. Which combination of steps will meet this requirement with the LEAST operational overhead? (Choose two.)

  1. Turn on the public access setting for the DB instance.
  2. Update the security group of the DB instance to allow only Lambda function invocations on the database port.
  3. Configure the Lambda function to run in the same subnet that the DB instance uses. Correct Answer
  4. Attach the same security group to the Lambda function and the DB instance. Include a self-referencing rule that allows access through the database port. Correct Answer
  5. Update the network ACL of the private subnet to include a self-referencing rule that allows access through the database port.

Community Votes

CD
72%
BD
28%

72% of anonymous learners picked answer CD. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

This question tests VPC networking integration for serverless functions, where the common trap is over-engineering network paths instead of leveraging shared security group attributes.

Learn how to connect AWS Lambda functions to Amazon RDS privately with minimal operational overhead using shared security groups and subnet configuration.

Many learners choose B because it explicitly allows traffic, but failing to place the Lambda in the same subnet (C) leaves it isolated from the DB's private IP space, requiring NAT or public access.

Community Discussion (18 comments)

Alagong 👍 6 Selected: CD
This solution only modifies the inbound rules of the security group of the DB instance, but it does not modify the outbound rules of the security group of the Lambda function. Additionally, this solution does not facilitate a private connection from the Lambda function to the DB instance, hence, the Lambda function would still need to use the public internet to access the DB instance. Therefore, this option does not fulfill the requirements.
rr01 👍 1 Selected: BD
I would go with B & D. As C would have operational overhead in my opinion.
altonh 👍 1 Selected: BC
D is wrong. It is a bad security practice for a DB to share SG with the client. C is correct compared to the other opinions (A & E).
proserv 👍 1 Selected: BD
B & D C is wrong While you want the Lambda function to access the RDS instance privately, it does not need to run in the same subnet. As long as both are in the same VPC, the Lambda function can connect.
tgv 👍 2 Selected: CD
I will go with C and D on this one, because in my opinion B is not correctly phrased. The correct way to phrase it would be something like: Update the security group of the RDS instance to allow inbound traffic on the database port (3306) only from the security group associated with the Lambda function.
sdas1 👍 2
While placing the Lambda function in the same subnet as the DB instance would technically allow them to communicate privately within the same network, it introduces additional complexity and operational overhead. Lambda functions typically run in AWS-managed VPCs, and configuring them to run in a specific subnet might require manual intervention and ongoing maintenance.
Snape 👍 3 Selected: BD
bbb ddd
lucas_rfsb 👍 1 Selected: CD
I would go with CD, since it's less operational effort, in my opinion
arvehisa 👍 4 Selected: CD
B: need update security group. and there there may be other application need to access db except for lambda function D: it works and reuse security group which has less operational overhead
harrura 👍 2
A is not an option as it exposes the data to public B is not an option as we don't want the lambda to be the only entity accessing the db, there can be many other apps. doing this is not scalable
certplan 👍 1
B. - While updating the security group of the DB instance to allow only Lambda function invocations on the database port may seem like a viable solution, it's not the most efficient approach. This option overlooks the need for the Lambda function to be able to communicate securely with the DB instance within the same VPC/subnet. - Reference: [Amazon RDS documentation on security groups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithSecurityGroups.html)
certplan 👍 1
  • AWS Lambda supports VPC configurations, allowing you to run Lambda functions within your own VPC. This enables private connectivity between Lambda functions and resources within the VPC, such as RDS DB instances. Reference AWS Lambda documentation on VPC configurations: [AWS Lambda VPC Settings]https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html - AWS security groups provide a flexible and scalable way to control traffic to your instances or resources. By attaching the same security group to both the Lambda function and the RDS DB instance, you can ensure they share the same set of rules for inbound and outbound traffic. - Self-referencing rules within security groups enable instances within the same security group to communicate with each other over specified ports. - Reference AWS documentation on security groups and self-referencing rules: [Security Groups for Your VPC]https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
certplan 👍 4
So, there coudl be a justified argument for the following: C. Configure the Lambda function to run in the same subnet that the DB instance uses: By running the Lambda function in the same subnet as the RDS DB instance, you enable them to communicate privately within the same network, eliminating the need for public internet access and reducing operational overhead. D. Attach the same security group to the Lambda function and the DB instance. Include a self-referencing rule that allows access through the database port: By attaching the same security group to both the Lambda function and the RDS DB instance, and including a self-referencing rule that allows access through the database port, you ensure secure communication between them within the same VPC without exposing the database to the public internet. This approach minimizes operational overhead by centralizing security management and simplifying access control.
certplan 👍 1
Here's how you would implement this: 1. Attach the same security group to both the Lambda function and the RDS DB instance: Ensure that both resources are associated with the same security group. 2. Create an inbound rule in the security group: Configure the security group to allow inbound traffic on the database port (e.g., 3306 for MySQL) from the security group itself. For example, if the security group ID is sg-1234567890 and the database port is 3306, the inbound rule would look something like this: Type: Custom TCP Rule Protocol: TCP Port Range: 3306 (or the port your database uses) Source: sg-1234567890 (the security group ID itself) This rule allows the Lambda function, which is also part of the same security group, to communicate with the RDS DB instance through the specified port. It effectively creates a loopback or self-referencing rule within the security group, allowing internal communication between resources while maintaining security boundaries.
certplan 👍 2
The phrase "Include a self-referencing rule that allows access through the database port" refers to configuring the security group associated with the resources (in this case, the Lambda function and the RDS DB instance) to allow inbound traffic from the resources themselves on a specific port, typically the port used for database communication. In AWS security groups, a self-referencing rule means allowing traffic from the security group itself. This setup is often used to facilitate communication between resources within the same security group or VPC without needing to specify individual IP addresses.
GiorgioGss 👍 1 Selected: BC
When you want Lambda to "privately" connect to a resource (RDS in this case) that sits inside a VPC, then you deploy Lambda inside VPC. = C Then you attach a proper IAM role to lambda. Then, to be more secure you open the RDS security group only on the specific port: MySQL/Aurora MySQL: 3306 SQL Server: 1433 PostgreSQL: 5432 Oracle: 1521
BartoszGolebiowski24 👍 1
what does "Include a self-referencing rule that allows access through the database port." mean?
rralucard_ 👍 1 Selected: BC
B. Update the security group of the DB instance to allow only Lambda function invocations on the database port: Modifying the security group of the RDS instance to allow incoming connections on the database port (e.g., port 3306 for MySQL, 5432 for PostgreSQL) from the Lambda function is a crucial step. This ensures that the RDS instance can accept connections from the Lambda function. C. Configure the Lambda function to run in the same subnet that the DB instance uses: Placing the Lambda function in the same VPC and subnet as the RDS instance ensures private connectivity. AWS Lambda needs to be configured with a VPC configuration that includes the subnet(s) and security group(s) that allow access to the RDS instance.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

To connect a Lambda function to an RDS instance privately, both resources must reside within the same VPC and be able to reach each other via their private IPs. Option C places the Lambda in the same subnet as the DB, ensuring direct Layer 3 connectivity without needing a NAT Gateway or Public Internet. Option D attaches the same Security Group to both, using a self-referencing rule to allow inbound database port traffic from the Lambda. This combination provides the LEAST operational overhead because it avoids complex route table modifications, NAT gateways, or managing separate SGs.

Why the Other Options Are Wrong

Option A exposes the DB to the internet, violating the "privately" requirement. Option B updates the DB's SG but doesn't ensure the Lambda can reach the DB's private IP if they are in different subnets/VPCs; without Option C, the connection fails. Option E modifies Network ACLs, which are stateless and less granular than SGs, adding unnecessary complexity. Sharing SGs (D) is acceptable for this specific exam scenario to minimize overhead, despite general best practices suggesting distinct SGs.

Community Comment Notes

Several users noted that Option B alone is insufficient because it doesn't address the network path. As user Alagong pointed out, "this solution only modifies the inbound rules... does not facilitate a private connection." Others debated whether sharing SGs (D) is bad practice, but for "least operational overhead," it is the intended answer in this context. User certplan highlighted that C enables communication within the same network, eliminating public internet need.

Exam Strategy

When asked for 'least operational overhead' in AWS networking questions, look for solutions that leverage existing infrastructure attributes (like shared Security Groups or same-subnet placement) rather than adding new components like NAT Gateways or Transit Gateways.

Frequently Asked Questions

Why is Option B incorrect for private connectivity?

Option B only opens the DB port but doesn't ensure the Lambda function is in the same VPC/subnet to reach the private IP. Without C, the Lambda might still need public routing.

Is sharing Security Groups between Lambda and RDS safe?

While distinct SGs are better for strict isolation, the exam prioritizes 'least operational overhead'. Sharing an SG with a self-referencing rule is the simplest way to meet the connectivity requirement here.

More DEA-C01 FAQ →

Related Analysis

Practice All DEA-C01 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DEA-C01 Practice Test →

← Back to DEA-C01 Study Guide