Atlas Deployment and Cluster Configuration
This domain tests how you choose and configure Atlas cluster topology: dedicated versus shared tiers, replica set and sharded layouts, region placement, scaling, and maintenance behavior.
Core rules
- Dedicated clusters (M10 and above) provide isolated resources, Atlas-managed backups, private connectivity, and configurable IOPS; M0/Flex are for development and have feature limits.
- A default replica set has three electable nodes across three availability zones in one region. You can add electable, read-only, or analytics nodes. Analytics nodes are read-only, do not vote in elections, and can be tagged so BI clients target them.
- Sharded clusters add mongos routers and config servers; each shard is its own replica set. Choose a shard key with high cardinality and low monotonicity before loading data.
- Place electable nodes in multiple regions only when you need regional failover; read-only nodes in additional regions reduce read latency without voting.
- Vertical scaling changes the tier and triggers a rolling restart; storage can autoscale upward but cannot be reduced. Shard count changes are online but expensive.
Worked example
An application runs in eu-west-1, needs to survive an eu-west-1 outage, and has BI users in us-east-1. A single-region three-node replica set gives AZ resilience but not region failover. Configure electable nodes in eu-west-1 and eu-west-2, plus a read-only analytics node tagged workload:analytics in us-east-1. Point the BI connection string at the analytics tag. This meets regional failover and keeps analytics off the primary.
Traps
Assuming analytics nodes participate in elections; expecting M0 to support private endpoints or continuous backup; shrinking storage after growth; treating three AZs in one region as multi-region disaster recovery.