Which solution meets these requirements?
Create a now route table that excludes the route to the public subnets’ CIDR blocks. Associate the route table to the database subnets.
Create a security group that denies ingress from the security group used by instances in the public subnets. Attach the security group to an Amazon RDS DB instance.
Create a security group that allows ingress from the security group used by instances in the private subnets. Attach the security group to an Amazon RDS DB instance.
Create a new peering connection between the public subnets and the private subnets. Create a different peering connection between the private subnets and the database subnets.
Explanations:
A route table that excludes routes to public subnets does not prevent access from public subnets to the database subnets. It simply controls routing but does not enforce security or access control. Instances in public subnets can still attempt to reach the database unless explicitly restricted.
Creating a security group that denies ingress from the public subnet’s security group does not effectively limit access to the database. Security groups do not support explicit deny rules; they only allow specified traffic. Therefore, this option cannot guarantee that instances in public subnets cannot access the database.
This option creates a security group that allows ingress from the private subnet’s security group, effectively allowing only instances in the private subnets to access the Amazon RDS database. This meets the requirement that only private subnet instances can connect to the database.
Creating peering connections between subnets does not restrict access. Peering allows network traffic to flow between VPCs or subnets, but it does not enforce access controls. Without security groups or other access controls, instances in public subnets could still access the database.