Networking and Connectivity
This domain tests how clients reach Atlas privately and securely: access lists, VPC peering, private endpoints, DNS, and TLS.
Core rules
- Atlas clusters have public endpoints by default. A project IP access list must allow the client egress IP or CIDR even when private connectivity is used.
- VPC peering connects your cloud VPC/VNet to the Atlas VPC. CIDRs must not overlap; you must update route tables and security groups on both sides. Peering is non-transitive, so hub-and-spoke designs need a transit gateway.
- AWS PrivateLink, Azure Private Link, and GCP Private Service Connect create a private endpoint in your network and do not require CIDR coordination. They are available on dedicated clusters, not M0/Flex.
- Use mongodb+srv for DNS seed lists; the private endpoint hostname must resolve through private DNS. Atlas requires TLS, and you can enforce a minimum TLS version.
- Cross-region clusters can expose endpoints in multiple regions; place the endpoint near the application.
Worked example
An AWS application in 10.0.0.0/16 needs private access to Atlas in us-east-1, and a new acquisition uses 10.0.0.0/8. Peering would overlap. Choose AWS PrivateLink: create an interface endpoint, link it to the Atlas project, enable private DNS, and connect with the private endpoint connection string. Add the application subnet CIDR to the Atlas access list and allow outbound 443 from the application security group.
Traps
Assuming peering removes the need for an Atlas access list; forgetting route-table entries for a new subnet; using a public SRV name from a private-only subnet; trying PrivateLink on a free cluster; allowing 0.0.0.0/0 as a shortcut.