Troubleshooting and Operational Readiness
This domain tests systematic diagnosis and operational readiness: isolating connectivity, authentication, performance, and failover issues before they become outages.
Core rules
- Troubleshoot in layers: DNS, network path, TLS, authentication, authorization, then cluster and query performance.
- ServerSelectionTimeout usually points to an Atlas access list, peering route, private endpoint, or DNS problem. Authentication failed means bad credentials or mechanism; not authorized means the user lacks a role.
- Use Atlas metrics, logs, explain, Query Profiler, and Performance Advisor. Check COLLSCAN, high keysExamined, in-memory sorts, and replication lag.
- Test failover with Atlas-initiated failover and confirm the driver reconnects. Validate alerts, runbooks, backup restores, and maintenance windows before incidents.
- Operational readiness includes least privilege, terminate protection, tagging, quotas, and documented rollback.
Worked example
A new subnet cannot connect after VPC peering, while the old subnet works. Check the Atlas access list: it allows the old CIDR only. Add the new subnet CIDR. Check the new subnet route table: it lacks a route to the Atlas VPC. Add the route and allow outbound 443 in the security group. Test with mongosh from the new subnet, then confirm the application. This is a network-layer issue, not an authentication problem, because the error is server selection timeout rather than authentication failed.
Traps
Opening 0.0.0.0/0 to fix connectivity; confusing authentication with authorization; changing indexes before reading explain; skipping route tables and security groups; never testing failover; treating a single alert as root cause.