C100DBA Sharding Practice Test 3 — 15 Questions

Question 1

An application issues a find query against a sharded collection without including the shard key in the query filter. How does the mongos query router handle this operation?

Accepted Answer

It performs a scatter-gather query by sending the request to all shards in the cluster, merging the results before returning them to the client.. When a query lacks the shard key, the mongos query router cannot determine which specific shard holds the target document. Consequently, it executes a scatter-gather query, forwarding the request to every shard in the cluster, collecting the responses, and merging them before returning the result to the client.

Answer

It rejects the query immediately with an invalid operation exception to protect cluster performance from unindexed scans.

Answer

It routes the query exclusively to the primary shard of the database, bypassing all other shards in the infrastructure.

Answer

It broadcasts the query only to the config server primary, which evaluates the predicate against cached metadata documents.

Question 2

When is it appropriate to use a hashed shard key instead of a ranged shard key in a MongoDB sharded collection?

Accepted Answer

When the application generates monotonically increasing write keys, and the primary objective is to distribute write operations evenly across all shards to prevent bottlenecks.. Hashed shard keys are ideal when incoming write operations rely on monotonic or sequential values, such as auto-incrementing IDs or timestamps. Hashing prevents write bottlenecks by scattering insertions across all cluster shards, whereas ranged keys would force all writes onto a single shard.

Answer

When the application executes frequent range-based find queries that require contiguous document retrieval across multiple chunks.

Answer

When the collection dataset size is guaranteed to remain under one gigabyte, eliminating the need for automated chunk balancing.

Answer

When compliance regulations require all database documents to be encrypted using deterministic hashing algorithms at rest.

Question 3

An application requires high write throughput for time-series data indexed by a timestamp field. You observe that all incoming data is being routed to a single shard, creating a write hotspot. Which shard key strategy best resolves this performance bottleneck?

Accepted Answer

Apply a hashed index to the timestamp field as the shard key.. Using a hashed shard key distributes documents uniformly across all shards in the cluster regardless of the timestamp value. By hashing the shard key, the balancer ensures that contiguous ranges of data are not sent to the same shard. This strategy is critical in MongoDB sharding to prevent write hotspots and ensure that the disk I/O and CPU utilization are evenly balanced across the entire sharded cluster, effectively scaling write operations horizontally.

Answer

Use the timestamp field as a single-field shard key.

Answer

Implement a range-based shard key using a UUID.

Answer

Increase the number of mongos instances in the cluster.

Question 4

A production MongoDB 6.0 sharded cluster has a collection with a ranged shard key on the field `customerId`. Over time, the team notices that nearly all new documents have monotonically increasing `customerId` values, and one shard is receiving a disproportionate share of writes while the other shards remain relatively idle. The balancer is enabled and running. Which of the following is the most likely explanation for this imbalance?

Accepted Answer

The shard key is monotonically increasing, causing all new inserts to target the highest chunk on a single shard.. With a monotonically increasing shard key, new inserts always target the chunk with the highest key range. Because chunks are assigned to shards, that highest chunk lives on one shard at a time, making it a write hotspot. The balancer will eventually migrate chunks, but the stream of new inserts keeps hitting the newest chunk, so the imbalance persists.

Answer

The shard key field is not indexed on the shards, forcing all writes to a single primary.

Answer

The config servers are overloaded and cannot process chunk migration commands.

Answer

The collection has too few chunks, so the balancer cannot distribute them evenly across shards.

Question 5

A MongoDB 6.0 sharded cluster has a collection with a ranged shard key on the field 'customerId'. The balancer has been running normally, but the operations team notices that one shard consistently holds significantly more chunks than the others. They want to understand which internal metadata collection the mongos uses to determine chunk distribution and to verify the current chunk-to-shard mapping. Which collection should they query?

Accepted Answer

config.chunks. Chunk distribution is tracked in the config database, specifically in config.chunks, which maps each chunk's key range to its host shard. To verify which shard holds more chunks, an administrator queries config.chunks. The other collections store different metadata: shard list, collection definitions, or version info, none of which include per-chunk placement.

Answer

config.shards

Answer

config.collections

Answer

admin.system.version

Question 6

A financial services company runs a sharded MongoDB cluster with three shards. They need to shard a new collection that stores transaction records. The collection will be queried primarily by 'accountId' and 'transactionDate'. The team wants to minimize scatter-gather queries and ensure even data distribution. Which two actions should they take when choosing and implementing the shard key? (Choose two.)

Accepted Answer

Ensure the shard key has high cardinality and low frequency to avoid jumbo chunks and hot spots.. The compound shard key with 'accountId' first supports targeted queries on account and range queries on date, while also providing high cardinality and low frequency. This combination reduces scatter-gather and avoids hot spots. Hashed or random keys improve distribution but break query targeting, and a monotonically increasing key creates write hot spots.

Answer

Choose a shard key that is monotonically increasing, such as an auto-incrementing transaction ID, to simplify range queries.

Answer

Use a random shard key generated by the application to guarantee even distribution across shards.

Answer

Use a hashed shard key on 'accountId' to ensure even distribution, even though it prevents efficient range queries on 'transactionDate'.

Question 7

A MongoDB DBA is configuring a new sharded cluster. The application requires that queries on the sharded collection include the shard key to avoid scatter-gather. The DBA decides to use a ranged shard key on the field 'region'. After sharding, the DBA notices that queries filtering only on 'region' are performing well, but queries that also filter on 'city' are still scanning all shards. What is the most likely cause?

Accepted Answer

The shard key does not include 'city', so queries with both 'region' and 'city' cannot be targeted to a single shard.. Query targeting in a sharded cluster depends on the shard key. If the shard key is only 'region', queries that filter on 'region' can be routed to specific shards. Adding 'city' does not change the routing because 'city' is not part of the shard key. To target on both fields, the shard key would need to be compound, including both 'region' and 'city'.

Answer

The 'city' field is not indexed, causing the query to scan all shards.

Answer

The balancer has not yet distributed chunks evenly, so some shards have more data and cause the query to scan them.

Answer

The shard key 'region' has low cardinality, so queries cannot be targeted efficiently.

Question 8

A MongoDB 6.0 sharded cluster has a collection sharded with a hashed shard key on 'userId'. The operations team needs to run an aggregation that groups documents by 'userId' and calculates the total transaction amount. They want to know whether the aggregation can be optimized to run only on the shards that contain the relevant 'userId' values. Which statement describes the correct behavior?

Accepted Answer

The aggregation can target specific shards if the $match stage includes an equality condition on 'userId'.. For a hashed shard key, mongos can target a specific shard when the query includes an equality condition on the shard key field. This is because the hash of the value determines the chunk and thus the shard. Other stages or options do not affect targeting. Therefore, an aggregation with a $match on 'userId' with an equality can be optimized to run on a single shard.

Answer

The aggregation can target specific shards only if it includes a $sort stage on 'userId' before the $group stage.

Answer

The aggregation will always run on all shards because hashed shard keys prevent any query targeting.

Answer

The aggregation must be run with the allowDiskUse option to target specific shards.

Question 9

A DBA is troubleshooting a sharded cluster where the balancer is not migrating chunks even though there is an imbalance. The DBA runs `sh.getBalancerState()` and it returns `true`. Which of the following is the most likely reason the balancer is not migrating chunks?

Accepted Answer

The balancer window is configured to a time period outside of the current time.. The balancer only runs during the configured balancing window. Even if `sh.getBalancerState()` returns `true`, migrations will not occur outside that window. The DBA should check the balancer window settings and ensure they align with the desired migration times. Other options would either cause broader failures or are not relevant to the balancer's operation.

Answer

The config servers are in a read-only state.

Answer

The collection has no indexes on the shard key, so the balancer cannot identify chunks to migrate.

Answer

The shard key is hashed, and hashed shard keys prevent the balancer from migrating chunks.

Question 10

A MongoDB 6.0 sharded cluster uses a shard key of { region: 1, customerId: 1 } for a global order collection. Most queries filter on customerId only, without region. The operations team observes that nearly every read is a scatter-gather across all shards. What is the most accurate explanation for this behavior?

Accepted Answer

The shard key fields are in the wrong order: customerId must precede region so that queries filtering only on customerId can target a subset of shards.. Query targeting on a sharded collection depends on whether the predicate includes a prefix of the shard key. With { region: 1, customerId: 1 }, the leading field is region, so a query filtering only on customerId matches no prefix and mongos broadcasts to all shards. Placing customerId first allows equality queries on customerId to be routed to a single shard, resolving the scatter-gather pattern.

Answer

The collection uses hashed sharding, which prevents any targeted reads regardless of which shard key fields appear in the query predicate.

Answer

The balancer is disabled, so chunks for the customerId values are not distributed and queries cannot be routed to a single shard.

Answer

The shard key is compound, and MongoDB cannot route queries unless every field in the shard key is present with an equality match.

Question 11

A MongoDB DBA is managing a sharded cluster where the collection 'orders' is sharded on the field 'orderDate' using ranged sharding. The DBA needs to add a new shard to the cluster to handle increasing data volume. After adding the shard, the balancer begins migrating chunks. During this migration, the DBA runs a query that includes 'orderDate' and notices increased latency. What is the most likely reason for the increased latency?

Accepted Answer

The balancer migration process consumes resources on the shards and may cause temporary performance degradation.. Adding a shard triggers the balancer to migrate chunks to distribute data. This migration process involves copying data and updating metadata, which consumes resources on the source and destination shards. As a result, concurrent queries may experience increased latency until migrations finish. The other options describe unrelated issues or misconceptions about indexing and hot spots.

Answer

The config servers are overloaded with metadata updates, causing mongos to delay query routing.

Answer

The query must now be routed to the new shard, which has not yet been indexed, causing a full collection scan.

Answer

The shard key 'orderDate' is monotonically increasing, so all new data is going to the new shard, causing a hot spot.

Question 12

A financial services company shards a transactions collection using a ranged shard key on an incrementing timestamp field. Over several months, the cluster develops a single hot shard that receives almost all writes, while the other shards remain nearly idle. Which change best addresses the root cause while preserving efficient range queries on timestamp?

Accepted Answer

Use a compound shard key that combines a low-cardinality prefix such as a hash of the timestamp bucket with the timestamp, or apply a bucketing strategy to spread inserts.. A monotonically increasing shard key concentrates all inserts in the highest chunk, creating a single hot shard regardless of cluster size. Introducing a hashed or bucketed prefix spreads writes across many chunks and shards, while retaining timestamp as a suffix preserves efficient range queries. This combination solves the imbalance without sacrificing the query pattern the application depends on.

Answer

Enable the balancer and lower the chunk size to 32 MB so chunks migrate more aggressively during peak hours.

Answer

Convert the shard key to a hashed key on timestamp, which spreads writes evenly across shards and keeps range queries efficient.

Answer

Add more shards to the cluster so the hot shard's load is diluted across a larger number of nodes.

Question 13

A database administrator is setting up a new sharded cluster and needs to enable sharding on a database named 'sales' before sharding any collections. Which command should be executed on mongos to enable sharding for this database?

Accepted Answer

sh.enableSharding("sales"). To enable sharding on a database in MongoDB, you must run sh.enableSharding() on mongos with the database name. This marks the database as sharding-enabled in the config servers, allowing collections within it to be sharded. The other commands either shard a collection, add a shard, or use incorrect syntax.

Answer

db.runCommand({enableSharding: "sales"}) on the admin database

Answer

sh.addShard("sales")

Answer

sh.shardCollection("sales", {_id: "hashed"})

Question 14

A sharded cluster has a collection sharded on `{ location: 1 }`. A query is executed with the filter `{ location: { $in: ["NY", "CA"] } }`. How does MongoDB route this query?

Accepted Answer

The query is routed to the shards that own chunks covering the values "NY" and "CA".. MongoDB's query router, mongos, can target queries that include the shard key, even with `$in`. It looks up the chunk ranges for the specified values and routes the query only to the shards that own those chunks. This is known as a targeted query and is efficient because it avoids contacting unnecessary shards.

Answer

The query is sent to all shards because `$in` cannot be targeted.

Answer

The query is routed to a random shard, and that shard forwards the request to the others as needed.

Answer

The query is routed to the primary shard for the database because `$in` is not a targeted operation.

Question 15

A DBA is preparing to shard a collection in a MongoDB 6.0 cluster. The collection currently has no indexes other than the default _id index. The chosen shard key is { userId: 1 }. What must the DBA do before running shardCollection?

Accepted Answer

Create an index on userId, because a sharded collection requires a supporting index on the shard key.. Before sharding a collection, MongoDB requires an index whose leading fields match the shard key. Without it, the shardCollection command returns an error. Creating an index on userId satisfies this requirement and enables the cluster to manage chunk boundaries and route queries. Emptying the collection or disabling the balancer is unnecessary and would not satisfy the actual prerequisite.

Answer

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

Answer

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

Answer

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