SOA-C02 Deployment, Provisioning, and Automation Practice Question

A company uses AWS CloudFormation to manage infrastructure. They have a stack that creates an Amazon RDS DB instance. The database is in a VPC with public and private subnets. The DB instance is in a private subnet. When the stack is created, the DB instance is not accessible from an EC2 instance in the same VPC. What is the most likely cause?

⚠ Common exam trap

SOA-C02 often tests the misconception that an internet gateway or public IP is required for internal VPC communication, when in fact security group rules are the typical culprit for connectivity failures between EC2 and RDS.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The security group for the DB instance does not allow inbound traffic from the EC2 instance.

The most likely cause is that the security group attached to the RDS DB instance does not permit inbound traffic from the EC2 instance's security group or IP address on the database port. In a VPC, security groups act as virtual firewalls, and even if the DB is in the same VPC, traffic is blocked unless explicitly allowed. CloudFormation stack creation would succeed, but connectivity would fail.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The DB subnet group does not include the correct subnets.
Why it's wrong here
A DB subnet group determines which subnets and Availability Zones RDS can place the DB instance in. If the subnet group did not include the correct subnets, the DB instance would fail to launch or be provisioned in a different AZ, not simply reject connections. The fact that the CloudFormation stack reached a running state means the subnet group is valid, so connectivity failure is not a placement issue.
✓
The security group for the DB instance does not allow inbound traffic from the EC2 instance.
Why this is correct
RDS security groups are stateful firewalls that deny all inbound traffic by default. The DB instance's security group must have a custom inbound rule for the database port (e.g., TCP 3306 for MySQL) with a source referencing the EC2 instance's security group ID, not a CIDR from memory. Without this explicit allow, the EC2 instance cannot reach the DB even when both are in the same VPC and subnet, making this the classic cause of 'same VPC, still can't connect'.
✗
The VPC does not have an internet gateway attached.
Why it's wrong here
An internet gateway (IGW) is only needed for direct communication with the public internet. EC2 and RDS instances in a private subnet communicate over private IPv4 addresses within the VPC, and that traffic never traverses an IGW. A missing IGW would prevent outbound internet access from the EC2 instance (e.g., patching or downloading packages), but it does not affect private traffic between an EC2 instance and an RDS database.
✗
The DB instance does not have a public IP address.
Why it's wrong here
A public IP address is only used for reaching a resource from outside the VPC, and an RDS DB instance in a private subnet should not be publicly accessible. The EC2 instance connects to the DB using its private DNS name and private IP address, which requires no public IP on the DB. Even if the DB instance had no public IP at all, it would still be reachable from the EC2 instance within the same VPC, so this is not the cause of the failure.

Visual reference

Go deeper

SOA-C02 Deployment, Provisioning, and Automation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question