C100DBA Sharding Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Create an index on userId, because a sharded collection requires a supporting index on the shard key.

  Why this is correct

  MongoDB requires an index that starts with the shard key fields before a collection can be sharded. If no such index exists, shardCollection fails. Creating an index on userId satisfies this requirement. The index is used to enforce chunk boundaries and support routing, so it must exist prior to the sharding operation.

• ✗

  Convert the shard key to a hashed key first, because ranged shard keys cannot be applied to existing collections.

  Why it's wrong here

  Ranged shard keys can absolutely be applied to existing collections. There is no requirement to convert to hashed sharding. The only index-related prerequisite is a supporting index on the chosen shard key fields. Hashed sharding is a design choice, not a mandatory precursor to sharding an existing collection.

• ✗

  Set the collection to unsharded status and disable the balancer for the duration of the operation.

  Why it's wrong here

  The collection must not already be sharded, but disabling the balancer is not a prerequisite for shardCollection. In fact, the balancer may need to run afterward to distribute chunks. Setting an unsharded status is not a valid prerequisite step; the operation itself transitions the collection from unsharded to sharded.

• ✗

  Move the collection to the primary shard and ensure it is empty, because only empty collections can be sharded.

  Why it's wrong here

  Collections do not need to be empty to be sharded. MongoDB can shard a populated collection, distributing existing data into chunks across shards. Requiring an empty collection would make sharding impractical for production workloads. The only hard prerequisite related to indexes is that a supporting index on the shard key must exist.