Senior NoSQL & MongoDB Interview Questions (50 MCQs)

Question 1

Why is a low-cardinality shard key like `country` (about 200 values) problematic for a large collection?

Accepted Answer

It caps the number of splittable chunks, and heavy values become unmovable jumbo chunks

Answer

MongoDB doesn't accept string shard keys

Answer

Queries on this field always become scatter-gather

Answer

Replication between shards stops

Question 2

What problem does using `{ createdAt: 1 }` or an ObjectId `_id` as a ranged shard key cause?

Accepted Answer

All inserts land in the last (maxKey) chunk on one shard, making it a write hotspot

Answer

Documents scatter randomly across shards, so range queries are impossible

Answer

ObjectId isn't allowed as a shard key

Answer

The balancer constantly moves chunks but write load stays spread out

Question 3

What's the main trade-off of hashed sharding compared to ranged sharding?

Accepted Answer

Writes spread evenly, but range queries on the shard key become scatter-gather across all shards

Answer

Range queries get faster but writes concentrate on one shard

Answer

Hashed sharding only works on numeric fields

Answer

Hashed sharding removes the need for config servers

Question 4

In a cluster sharded on `{ userId: 1 }`, how is `find({ email: 'x@y.com' })` executed?

Accepted Answer

`mongos` broadcasts it to all shards and merges the results

Answer

It's sent only to the database's primary shard

Answer

It's rejected because it lacks the shard key

Answer

`mongos` hashes the email to find the right shard

Question 5

In a multi-tenant SaaS, why is `{ tenantId: 1, _id: 1 }` often a better shard key than `{ tenantId: 1 }` alone?

Accepted Answer

Per-tenant queries stay targeted while large tenants' data can still split into multiple chunks

Answer

Because MongoDB only accepts two-field shard keys

Answer

Because `_id` encrypts the data

Answer

Because it keeps all tenants on one shard

Question 6

What is a jumbo chunk in MongoDB and what typically causes it?

Accepted Answer

A chunk over the size limit that can't split because its documents share the same shard key value

Answer

A chunk containing documents larger than 16 MB

Answer

A chunk stored on the config server

Answer

A chunk created intentionally for backups

Question 7

In modern MongoDB (5.0+), what option exists if the wrong shard key was chosen?

Accepted Answer

`reshardCollection`, which redistributes data online under a new shard key

Answer

There's no way except a full dump and restore with downtime

Answer

Directly editing the `key` field in the config database

Answer

Dropping all indexes so MongoDB picks a new shard key itself

Question 8

What scenario is zone sharding in MongoDB suited for?

Accepted Answer

Keeping EU users' data on shards located in Europe for compliance and latency

Answer

Compressing old data

Answer

Running faster elections

Answer

Removing the need for a shard key

Question 9

During a network partition, what does a replica set primary on the minority side do?

Accepted Answer

It steps down and stops accepting writes; the majority side elects a new primary

Answer

It keeps accepting writes and conflicts are merged later

Answer

It shuts down the whole cluster

Answer

It turns into an arbiter

Question 10

What does PACELC add to the CAP theorem?

Accepted Answer

Even without a partition (Else), a system trades off Latency against Consistency

Answer

That partition tolerance is optional

Answer

That all three CAP properties can be had at once

Answer

A metric for measuring disk throughput

Question 11

In Cassandra with replication factor 3, which consistency level combination guarantees strong reads (read-your-writes)?

Accepted Answer

Write at `QUORUM` and read at `QUORUM`, since 2 + 2 > 3

Answer

Write at `ONE` and read at `ONE`

Answer

Write at `ONE` and read at `QUORUM`

Answer

Write at `ANY` and read at `TWO`

Question 12

In a multi-datacenter Cassandra cluster, why is `LOCAL_QUORUM` usually preferred over `QUORUM`?

Accepted Answer

It waits only for a quorum in the local DC, avoiding cross-DC latency and dependence on remote DC availability

Answer

It confirms the data in all DCs synchronously

Answer

It gives stronger consistency than `ALL`

Answer

It disables replication to other DCs

Question 13

Why does a queue-like pattern with heavy inserts and deletes in one partition degrade Cassandra reads?

Accepted Answer

Deletes write tombstones, and reads must skip thousands of them until compaction after `gc_grace_seconds`

Answer

Deletes lock the entire partition in Cassandra

Answer

Cassandra doesn't support deletes; data is only removed via TTL

Answer

Each delete triggers a full index rebuild

Question 14

How does Cassandra resolve conflicting concurrent writes to the same column on different replicas?

Accepted Answer

Last-write-wins by per-cell timestamp, which is vulnerable to clock skew

Answer

With vector clocks, returning all versions to the client

Answer

With a distributed lock before every write

Answer

The second write is always rejected

Question 15

Why are writes so fast in Cassandra (an LSM-tree-based engine)?

Accepted Answer

A write is just a sequential append to the commit log plus a memtable insert; SSTables are flushed and compacted later

Answer

Writes update a B-tree in place on disk

Answer

Writes stay in client memory until all replicas confirm

Answer

Cassandra never writes data to disk

Question 16

Which Cassandra mechanism reconciles inconsistent replicas by comparing Merkle trees?

Accepted Answer

Anti-entropy repair (`nodetool repair`)

Answer

Hinted handoff

Answer

Read repair

Answer

Gossip protocol

Question 17

For billions of sensor readings in Cassandra, why use `((sensor_id, day))` as the partition key instead of just `sensor_id`?

Accepted Answer

To keep partitions from growing unboundedly and keep their size bounded

Answer

Because Cassandra only accepts two-column partition keys

Answer

To put all sensors' data on a single node

Answer

To remove the need for a clustering key

Question 18

What's the benefit of consistent hashing with virtual nodes (vnodes) in systems like Cassandra?

Accepted Answer

Adding or removing a node moves only a small fraction of data, and load spreads more evenly

Answer

All data is copied to every node

Answer

It removes the need for replication

Answer

It makes range queries on the partition key efficient

Question 19

What is the cost of a Cassandra lightweight transaction like `INSERT ... IF NOT EXISTS`?

Accepted Answer

It uses Paxos with multiple replica round trips, so latency is much higher than a normal write

Answer

It has no extra cost

Answer

It locks the whole cluster until completion

Answer

It runs on a single node without replication

Question 20

For a table where votes are written with partition key `candidateId` and one candidate is extremely popular, what's a common fix for the hot partition?

Accepted Answer

Write sharding: append a random suffix like `candidateId#7` and aggregate on read

Answer

Raising the table's total provisioned capacity alone is always enough

Answer

Converting all writes to `Scan`

Answer

Adding an LSI on `candidateId`

Question 21

Roughly what is the throughput ceiling of a single DynamoDB physical partition?

Accepted Answer

3,000 RCU and 1,000 WCU per second

Answer

40,000 RCU and 40,000 WCU per second

Answer

100 RCU and 10 WCU per second

Answer

There is no limit

Question 22

What is the core idea of single-table design in DynamoDB?

Accepted Answer

Store multiple entity types in one table with generic keys like `PK = USER#123`, `SK = ORDER#456` so related data comes back in one `Query`

Answer

Each table holds only one item

Answer

All data is stored in one big JSON attribute

Answer

Use one table for all dev and prod environments

Question 23

How does a sparse GSI work in DynamoDB?

Accepted Answer

Only items that have the GSI key attribute appear in the index, so you can query a small subset directly

Answer

The GSI samples only every few items

Answer

The GSI is defined without a partition key

Answer

Items are removed from the GSI after a while

Question 24

How do you prevent lost updates between two concurrent clients in DynamoDB?

Accepted Answer

Optimistic locking with a `version` attribute and `ConditionExpression: 'version = :expected'` on each update

Answer

With a strongly consistent read alone

Answer

With a `Scan` before every write

Answer

DynamoDB automatically merges all updates

Question 25

Which statement about DynamoDB `TransactWriteItems` is true?

Accepted Answer

It writes up to 100 items atomically and consumes about twice the capacity of normal writes

Answer

It supports unlimited items at no extra cost

Answer

It only works within a single partition

Answer

It has no isolation and intermediate results are visible

Question 26

In MongoDB's election protocol (pv1, Raft-based), which secondary is most likely to become primary?

Accepted Answer

A member with the most up-to-date oplog that wins a majority vote in a new term; higher priority is also preferred

Answer

The member with the most disk space

Answer

The member that joined the cluster first

Answer

The arbiter, since it holds no data and is faster

Question 27

When an old primary rejoins after failover holding writes that never reached a majority, what happens?

Accepted Answer

Those writes are rolled back and saved to rollback files for manual review

Answer

They are automatically merged with the new primary

Answer

The old primary becomes primary again and discards the new data

Answer

The whole replica set halts

Question 28

What does a causally consistent session in MongoDB guarantee for reads from secondaries?

Accepted Answer

Read-your-writes and monotonic reads, by having the secondary wait until it reaches the session's `operationTime`

Answer

All secondaries update synchronously with the primary

Answer

Reads are always routed to the primary

Answer

No guarantee; it only lowers latency

Question 29

What are the properties and limits of read concern `'linearizable'` in MongoDB?

Accepted Answer

Primary-only, for queries returning a single document, and guarantees all prior majority writes are seen

Answer

Works on any secondary and is the fastest read concern

Answer

It's only usable inside multi-document transactions

Answer

It also returns unacknowledged data

Question 30

In a multi-document transaction with `readConcern: 'snapshot'`, how do reads behave?

Accepted Answer

All reads see a consistent snapshot of majority-committed data as of the start

Answer

Each read sees the newest data, even uncommitted

Answer

Reads take an exclusive lock on the collection

Answer

Reads are served only by secondaries

Question 31

When a MongoDB transaction fails with an error labeled `TransientTransactionError` (e.g., a write conflict), what's the right behavior?

Accepted Answer

Retry the entire transaction from the start; the `withTransaction()` helper does this automatically

Answer

Retry only the last operation

Answer

Ignore the error and commit

Answer

Switch read concern to `'local'`

Question 32

Why are transactions spanning multiple shards more expensive than single-shard ones?

Accepted Answer

They require a coordinated two-phase commit across shards, adding round trips and latency

Answer

MongoDB doesn't support multi-shard transactions

Answer

The whole cluster becomes read-only during the transaction

Answer

Data is moved to one shard before commit

Question 33

If a change stream consumer is down for hours and its resume token has fallen off the oplog, what happens?

Accepted Answer

Resume fails, and you must do a full resync or start from a new point

Answer

MongoDB rebuilds the missed events from backups

Answer

The change stream automatically restarts from the beginning of the collection

Answer

The events are buffered in a `mongos` queue

Question 34

Why is 'save to MongoDB then publish to Kafka' in app code unreliable, and what's the alternative?

Accepted Answer

A crash between the two causes inconsistency; store the event in the same write (outbox) and publish via change streams/CDC

Answer

Kafka isn't compatible with MongoDB

Answer

Publishing first and then saving fixes the problem

Answer

Using `w: 0` solves this problem

Question 35

At what granularity does WiredTiger handle write concurrency?

Accepted Answer

Document-level with optimistic concurrency and MVCC; conflicts are retried internally

Answer

A single global lock for the whole database

Answer

A collection-level lock for every write

Answer

An OS file-level lock

Question 36

What symptom appears when the working set (hot data and indexes) exceeds the WiredTiger cache?

Accepted Answer

A sharp rise in page faults and disk I/O, and query latency spikes

Answer

Queries throw out-of-memory errors and data is deleted

Answer

MongoDB automatically creates a new shard

Answer

No effect, since everything is on disk anyway

Question 37

How does MongoDB's query planner choose when multiple candidate indexes exist?

Accepted Answer

It races candidate plans in a trial period and caches the winner for that query shape

Answer

It always picks the smallest index

Answer

It always picks the most recently created index

Answer

It picks an index at random

Question 38

Why is a compound index usually better than two separate single-field indexes for a hot query on `{ a, b }`?

Accepted Answer

The planner rarely chooses index intersection, while a compound index seeks matching keys directly and supports sorting

Answer

MongoDB can't have more than one single-field index per collection

Answer

Single-field indexes aren't stored on disk

Answer

A compound index has no write cost

Question 39

What is a hidden index in MongoDB (4.4+) used for?

Accepted Answer

Evaluating the impact of dropping an index without actually dropping it; the planner ignores it but it stays maintained

Answer

Hiding sensitive data from users

Answer

Building an index only on secondaries

Answer

An index that's used but not shown in `explain()`

Question 40

To build a large index on a busy replica set with minimal primary impact, what approach is common?

Accepted Answer

A rolling index build: build on each secondary as standalone, then step down the primary and build there

Answer

Drop all indexes and rebuild them at peak hours

Answer

Temporarily convert the replica set to a standalone

Answer

Build the index only on the arbiter

Question 41

What scenario is `$merge` at the end of an aggregation useful for?

Accepted Answer

Building an on-demand materialized view that incrementally upserts results into a collection

Answer

Merging two replica sets into one

Answer

Combining two indexes into one

Answer

Merging concurrent write conflicts

Question 42

How does a MongoDB time-series collection (5.0+) store data efficiently?

Accepted Answer

It internally groups measurements by `metaField` and time range into compressed columnar buckets

Answer

It places each measurement on its own shard

Answer

It keeps data only in memory

Answer

It disables indexes

Question 43

Why might a document just indexed in Elasticsearch not immediately appear in search results?

Accepted Answer

Elasticsearch is near real-time; documents become searchable only after a refresh (every 1 second by default)

Answer

Indexing always takes several minutes

Answer

Documents are searchable only after a node restart

Answer

Searches always hit a daily stale replica

Question 44

Why is choosing the number of primary shards for an Elasticsearch index an important decision?

Accepted Answer

It can't easily change after creation (needs reindex or split/shrink), and too many shards add overhead

Answer

Shard count can change anytime at no cost

Answer

Shard count only affects security

Answer

Elasticsearch always uses exactly one shard

Question 45

What's a common best practice for keeping Elasticsearch in sync with primary data in MongoDB?

Accepted Answer

Keep MongoDB as the source of truth and propagate changes to Elasticsearch via CDC (change streams or Debezium)

Answer

Use Elasticsearch as the sole transactional database

Answer

Have the app write to both on every request and ignore errors

Answer

Copy all data manually each night with no real-time search

Question 46

Why are deep traversals (e.g., 5 hops) faster in Neo4j than recursive joins in SQL?

Accepted Answer

Index-free adjacency: each node points directly to its relationships, so per-hop cost doesn't depend on total data size

Answer

Neo4j stores all data in one huge table

Answer

Neo4j precomputes all traversal results

Answer

Neo4j uses a B-tree lookup per hop, which is faster than SQL

Question 47

In Dynamo-style systems like Riak, what advantage do vector clocks have over last-write-wins?

Accepted Answer

They detect truly concurrent writes and keep conflicting versions (siblings) for merging instead of silently dropping one

Answer

They remove the need for replication

Answer

They perfectly synchronize all node clocks

Answer

They compress the data

Question 48

How do MongoDB retryable writes prevent an `insertOne` from being applied twice after a network error?

Accepted Answer

The driver tags the write with a session id and transaction number, and the server recognizes the retry and returns the prior result

Answer

The driver scans the whole collection before retrying

Answer

The server rejects duplicates via unique indexes on every field

Answer

Retryable writes just resend the request with no guarantees

Question 49

In the document versioning pattern for keeping contract history, what's the common design?

Accepted Answer

The current version lives in the main collection with a `revision` field, and prior versions go to a separate history collection

Answer

All versions in an unbounded array inside the main document

Answer

Each version as a separate database

Answer

MongoDB automatically keeps all versions

Question 50

If `username` is denormalized into millions of comments, what's the main cost of a username change, and when is the design acceptable?

Accepted Answer

Write amplification and temporary inconsistency; acceptable when changes are rare, reads are very frequent, and async updates are tolerable

Answer

No cost, since MongoDB automatically updates all copies

Answer

Denormalization is always an anti-pattern and never acceptable

Answer

It only uses more disk space and has no effect on writes