C100DEV Aggregation Framework Practice Question
You are troubleshooting a pipeline over a large `telemetry` collection that exceeds the aggregation memory limit while running on a single mongod instance. You must let the pipeline complete successfully without changing the server-wide configuration. Which two actions will allow the pipeline to keep running? (Choose two.)
⚠ Common exam trap
The trap here is reaching for server-wide memory parameters, which the scenario forbids, instead of the per-operation allowDiskUse option and early filtering.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Add a $match stage before the memory-intensive stage to reduce the document count.
Two levers work within the stated constraints: enabling allowDiskUse so blocking stages can spill to disk, and shrinking the input with an early $match that can also exploit indexes. Together they address both the spill capacity and the underlying data volume, letting the pipeline complete on a single instance without any server-wide reconfiguration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Move the memory-intensive stage to the end of the pipeline.
Why it's wrong here
Reordering stages does not reduce the volume of data a blocking stage must buffer, because the stage still processes whatever reaches it. If anything, deferring filtering lets more documents accumulate, making the memory problem worse rather than resolving it, and it offers no mechanism to spill to disk.
- ✗
Disable the memory limit by restarting mongod with a larger wiredTigerCacheSizeGB value.
Why it's wrong here
The wiredTiger cache controls storage-engine memory, not the aggregation pipeline's per-stage buffering threshold, so raising it does not lift the aggregation limit. This also requires a server restart and configuration change, both of which the scenario prohibits, making it doubly unsuitable.
- ✓
Add a $match stage before the memory-intensive stage to reduce the document count.
Why this is correct
Filtering earlier shrinks the working set that downstream blocking stages must hold, often bringing the pipeline back under the memory threshold. Placing the $match first also lets it use indexes, so it is a legitimate way to avoid exceeding the limit without any server-wide change.
- ✗
Set the internalQueryMaxBlockingSortMemoryUsageBytes parameter to a larger value.
Why it's wrong here
That parameter is a server-wide configuration change, which the scenario explicitly rules out. It also affects blocking sort memory globally rather than scoping the increase to this pipeline, so it violates the constraint even though it might technically permit a larger in-memory sort.
- ✓
Pass the allowDiskUse option when executing the aggregation.
Why this is correct
Setting allowDiskUse to true permits stages that exceed the in-memory threshold to spill temporary data to the _tmp directory on disk. This lets the pipeline finish on a single mongod without altering server configuration, which directly satisfies the requirement when memory pressure comes from a blocking stage.
About these practice questions
One of 259 original C100DEV practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official MongoDB exam blueprint
This C100DEV practice question is part of Courseiva's free MongoDB certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the C100DEV exam.