C100DBA Sharding — 10 Questions

Question 1

When selecting a shard key for a new collection, which TWO of the following rules must be followed?

Accepted Answer

The shard key must be an indexed field or the prefix of an index.. Shard key selection is one of the most critical decisions in MongoDB architecture. A shard key must be part of an index and, for versions prior to 4.2, its value could not be changed. Understanding these constraints ensures that the collection can be successfully partitioned and that the database can efficiently route queries and manage data distribution across the shards.

Answer

The shard key value cannot be null for any document.

Answer

The shard key must be the same as the _id field for all collections.

Answer

Shard keys must be defined as unique indexes at the cluster level.

Question 2

Starting in MongoDB 4.4, you can refine a shard key by adding suffix fields to the existing key. Which TWO conditions must be met for this operation to succeed?

Accepted Answer

The new shard key must include the existing shard key as a prefix.. Refining a shard key allows for finer-grained data distribution when the original key lacks sufficient cardinality. Unlike changing a shard key entirely, refinement is a non-disruptive operation that adds fields to the existing key. This capability is essential for evolving schemas and addressing performance issues that arise as the volume and distribution of data change.

Answer

The collection must be dropped and recreated with the new key.

Answer

The balancer must be disabled during the entire refinement process.

Answer

All shards must be running the Enterprise Edition of MongoDB.

Question 3

What occurs when a chunk in a sharded collection exceeds the maximum configured chunk size?

Accepted Answer

The split is a metadata change that occurs when a chunk reaches the limit.. MongoDB automatically splits chunks when they reach a certain size, usually 64MB, to ensure that data can be distributed effectively across shards. Splitting is a metadata-only operation that occurs on the primary shard of the replica set containing the chunk. Understanding this process is vital for DBAs to manage cluster growth and prevent the creation of jumbo chunks.

Answer

The chunk is immediately moved to another shard to balance the load.

Answer

The collection becomes read-only until a DBA manually splits the chunk.

Answer

The shard key is automatically changed to provide better distribution.

Question 4

Which TWO actions should a database administrator perform before executing the shardCollection command on an existing populated MongoDB collection? Choose 2 answers.

Accepted Answer

Create an index on the collection that supports the chosen shard key prefix.. Sharding an existing populated collection requires creating the supporting index first to provide the routing foundation, and ensuring the database is explicitly enabled for sharding. Performing these prerequisites avoids runtime failures and ensures the cluster balancer can immediately initialize and distribute the initial data chunks across the configured shards without throwing administrative exceptions.

Answer

Temporarily stop all incoming application write operations across all mongod instances to prevent race conditions during chunk allocation.

Answer

Run the compact command on every underlying data file to defrag storage before shard boundary calculations execute.

Answer

Convert all ObjectId fields inside the target collection into standard string representations to satisfy BSON sharding constraints.

Question 5

Which THREE statements are true regarding the behavior and mechanics of the MongoDB cluster balancer? Choose 3 answers.

Accepted Answer

The balancer runs in the background and is coordinated by the primary node of the config server replica set.. The MongoDB balancer runs as a background process coordinated by the primary config server, moving chunks between shards when migration thresholds are met. Knowing balancer mechanics helps DBAs troubleshoot uneven data distributions, plan maintenance windows, and manage cluster resources effectively without causing unexpected performance degradation.

Answer

The balancer requires every individual shard in the cluster to be configured as a standalone mongod instance for optimal migration speed.

Answer

Disabling the balancer permanently deletes all existing chunk distribution boundaries and collapses the collection into a single unsharded file.

Question 6

Why is it critical to select a shard key that cannot be changed after a collection has been sharded in MongoDB?

Accepted Answer

MongoDB does not support updating shard key values directly or altering the shard key definition once a collection is sharded, requiring a full collection re-creation to change it.. MongoDB does not allow direct updates or modifications to an existing shard key value because the key dictates how documents are distributed across physical chunks and shards. Changing a shard key would require completely re-architecting and re-sharding the entire collection dataset. Understanding this immutability underscores the importance of careful upfront shard key design.

Answer

Changing a shard key automatically triggers an unrecoverable corruption of the WiredTiger storage engine's internal block allocation tables.

Answer

Updating a shard key requires restarting every mongos instance in the cluster simultaneously to flush query routing caches.

Answer

Modifying a shard key invalidates all secondary indexes across all shards, forcing a complete cluster-wide index rebuild from scratch.

Question 7

A production MongoDB 6.0 sharded cluster is running with three shards. An administrator needs to add a fourth shard to the cluster to handle increasing data volume. The new shard is a three-member replica set named rs4. Which sequence of commands will correctly add the new shard to the cluster?

Accepted Answer

Connect to mongos and run sh.addShard("rs4/host1:27017,host2:27017,host3:27017"). Adding a shard to a MongoDB cluster requires connecting to mongos and using sh.addShard() with the replica set name and member list in a single string. This registers the shard with the config servers and enables the balancer to distribute chunks to it. The other options use invalid syntax, wrong commands, or incorrect database context.

Answer

Connect to the config server primary and run rs.addShard("rs4/host1:27017,host2:27017,host3:27017")

Answer

Connect to mongos and run sh.addShard("rs4", "host1:27017,host2:27017,host3:27017")

Answer

Connect to mongos and run db.runCommand({addShard: "rs4/host1:27017,host2:27017,host3:27017"}) on the admin database

Question 8

A DBA is configuring a new sharded cluster and must choose a shard key for a collection that stores IoT sensor readings. The collection will have high insert volume and queries will often filter by `deviceId` and a timestamp range. The team wants to avoid write hotspots and support efficient range queries on timestamp. Which two shard key strategies should the DBA consider? (Choose two.)

Accepted Answer

Use a compound shard key with `deviceId` as the first field and timestamp as the second field.. The best strategies balance write distribution with query isolation. A compound key with `deviceId` first and timestamp second supports targeted queries on `deviceId` and range queries on timestamp, while providing good cardinality. A ranged key on timestamp alone supports range queries but may cause hotspots; however, it is still a valid option if combined with a prefix. The other options either destroy query efficiency or do not support the required query patterns.

Answer

Use a hashed shard key on the timestamp field.

Answer

Use a random shard key generated by the application for each document.

Answer

Use a hashed shard key on `deviceId`.

Question 9

A sharded collection uses a ranged shard key on the field {region: 1, customerId: 1}. An application frequently runs queries that filter only on customerId without including region. Which TWO statements accurately describe the behavior and recommended remediation? (Choose two.)

Accepted Answer

The collection should be resharded with a new shard key that includes customerId as a prefix, such as {customerId: 1, region: 1}.. Queries that omit the shard key prefix force scatter-gather operations across all shards. The only ways to fix this are to include the prefix in queries or to reshard the collection with a new shard key that matches the query pattern. Adding a secondary index or trying to refine the key cannot change the prefix.

Answer

The queries will still be targeted because MongoDB automatically uses the most selective field in the shard key for routing.

Answer

The shard key can be refined by adding customerId as a prefix using the refineCollectionShardKey command.

Answer

The queries can be optimized by creating an index on customerId alone on every shard.

Question 10

A MongoDB 6.0 cluster has a sharded collection with a shard key of { accountId: 1 }. The DBA needs to split a large chunk that covers accountId values from 1000 to 5000 into two chunks at the midpoint 3000, but the balancer is currently running and the cluster is under heavy load. Which approach correctly performs the split with minimal impact?

Accepted Answer

Run sh.splitAt("mydb.accounts", { accountId: 3000 }) against the mongos, which splits the chunk containing that value into two chunks.. sh.splitAt splits the chunk that contains the specified shard key value at that exact value, producing two chunks. It operates through mongos, uses current metadata, and does not require stopping the balancer, making it suitable during heavy load. The other methods either split at the median, rely on unsupported manual edits, or reference nonexistent startup options, so they fail to meet the precise, low-impact requirement.

Answer

Run sh.splitFind("mydb.accounts", { accountId: 3000 }) after disabling the balancer, because splitFind requires the balancer to be stopped.

Answer

Manually update the config.chunks collection to insert a new chunk document with the boundary at 3000 and refresh the mongos caches.

Answer

Restart the mongos processes with the --splitChunks option so the cluster automatically splits chunks at their midpoint during startup.