Advanced MongoDB test (Advanced)

Sample questions

5 sample questions from the Advanced MongoDB test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.

1. Which statement accurately describes the relationship between shard key cardinality and performance in a sharded MongoDB cluster?

   1. Shard key cardinality is irrelevant to sharding and should be ignored in design.
   2. Shard key cardinality directly affects data distribution and query performance in a sharded cluster.
   3. Shard key cardinality only affects the number of documents in a collection, not performance.
   4. Shard key cardinality has no impact on data distribution or query performance.

   Answer: B. Shard key cardinality directly affects data distribution and query performance in a sharded cluster.

   High cardinality shard keys lead to even data distribution across shards, improving query performance. Low cardinality shard keys can result in uneven data distribution and hotspots, degrading performance. This is a core concept in sharding design.

2. What is a recommended approach for implementing schema versioning with embedded documents in MongoDB?

   1. Use a separate collection to track schema changes for embedded documents.
   2. Use a version field within the embedded document and update it when the structure changes.
   3. Ignore schema versioning for embedded documents since they are immutable.
   4. Rely on MongoDB's automatic schema versioning for embedded documents.

   Answer: B. Use a version field within the embedded document and update it when the structure changes.

   When using embedded documents, a common approach to schema versioning is to include a version field within the document. This allows for tracking changes in the structure of the embedded document over time. Other options may lead to data inconsistencies or make it harder to track schema changes.

3. Which of the following is a common challenge when implementing schema versioning in MongoDB and requires careful planning to ensure backward compatibility and prevent disruptions to existing queries or applications?

   1. Schema versioning with embedded documents
   2. Schema versioning with references
   3. Schema versioning with TTL indexes
   4. Schema versioning with arrays

   Answer: A. Schema versioning with embedded documents

   When using embedded documents in MongoDB, schema versioning can be more complex due to the nested structure. This requires careful planning to ensure backward compatibility and to handle changes without disrupting existing queries or applications. One approach is to use a version field within the embedded document to manage different versions of the data structure.

4. Which statement accurately describes how MongoDB handles query plan cache invalidation?

   1. Query plan cache entries are invalidated upon database restart.
   2. Query plan cache entries are invalidated based on query performance metrics.
   3. MongoDB automatically invalidates query plan cache entries when the underlying collection schema changes.
   4. Query plan cache entries are invalidated only when a query is executed with different parameters.

   Answer: C. MongoDB automatically invalidates query plan cache entries when the underlying collection schema changes.

   MongoDB automatically invalidates query plan cache entries when the underlying collection schema changes, such as when indexes are added, removed, or modified. This ensures that the query planner uses up-to-date information to generate optimal query plans. Other options are incorrect because query plan cache invalidation is not triggered by query execution, query performance, or database restarts in a standard MongoDB setup.

5. A MongoDB cluster is experiencing frequent chunk migration failures, causing performance issues. Which of the following is the most likely cause of this problem?

   1. The chunk migration is failing due to an incorrect version of MongoDB being used.
   2. The chunk migration is failing due to an unbalanced shard key, causing excessive data movement.
   3. The chunk migration is failing due to a misconfigured mongos router.
   4. The chunk migration is failing due to a network outage between the shards.

   Answer: B. The chunk migration is failing due to an unbalanced shard key, causing excessive data movement.

   Chunk migration can fail if the shard key is not well-balanced, leading to uneven distribution of data and excessive migration. This is a common issue when the shard key does not support even distribution of data across shards. The other options do not directly relate to chunk migration mechanics.