C100DBA Philosophy and Features Practice Question
A global IoT platform ingests sensor readings from millions of devices. The team must choose a database that can store semi-structured data, scale horizontally, and provide high write throughput. Which TWO MongoDB features directly support these requirements? (Choose two.)
⚠ Common exam trap
The trap here is assuming that sharding automatically picks a good shard key, when the key must be chosen deliberately to avoid hotspots.
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
✓
Sharding with a well-chosen shard key
Sharding distributes data across shards for horizontal scale and high write throughput, while the dynamic schema accommodates heterogeneous sensor payloads without migrations. Together, these features address the platform's need to ingest semi-structured data from millions of devices and scale out as volume grows.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Mandatory multi-document ACID transactions for every insert
Why it's wrong here
Mandatory multi-document ACID transactions for every insert would add significant overhead and reduce write throughput. While MongoDB supports multi-document transactions, they are not required for single-document inserts and are not the mechanism for scaling writes. This option contradicts the goal of high-throughput ingestion.
- ✓
Sharding with a well-chosen shard key
Why this is correct
Sharding with a well-chosen shard key distributes data across multiple shards, enabling horizontal scaling and high write throughput. For IoT workloads, a shard key that spreads writes evenly, such as a hashed device ID, prevents hotspots. This directly supports the platform's need to ingest millions of readings and scale out as device count grows.
- ✓
Dynamic schema for heterogeneous sensor payloads
Why this is correct
A dynamic schema allows each sensor reading to have different fields, such as temperature, humidity, or motion, without requiring schema migrations. This flexibility is essential when devices report varied payloads. It lets the platform store semi-structured data efficiently and evolve as new sensor types are added, directly supporting the requirement for semi-structured data handling.
- ✗
Strict table-level locking for all write operations
Why it's wrong here
Strict table-level locking would serialize writes and severely limit throughput, which is the opposite of what a high-ingest IoT platform needs. MongoDB uses document-level concurrency control, not table-level locking, to allow many concurrent writes. This option would create bottlenecks and is not a feature that supports high write throughput.
- ✗
Automatic sharding based on the first field alphabetically
Why it's wrong here
MongoDB does not automatically shard based on the first field alphabetically. The shard key must be chosen explicitly, and a poor choice can lead to uneven distribution. This option describes a non-existent automatic behavior and would not reliably support horizontal scaling or high write throughput for IoT data.
About these practice questions
Courseiva writes every C100DBA question from scratch — 222 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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 C100DBA 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 C100DBA exam.