Mobile App Now Available

Master Interviews
Anywhere, Anytime

Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.

Get it on

Google Play

4.9/5 Rating on Store

Subject page

MongoDB/NoSQL · Question Set

MongoDB Advanced Topics – MongoDB/NoSQL interview questions

MongoDB Advanced Topics interview questions for placements and exams.

Subject: MongoDB/NoSQLDifficulty: Mixed14 questions in this set

Set overview

Questions

Included in this set

Subject

MongoDB/NoSQL

Explore more sets

Difficulty

Mixed

Level of this set

MongoDB/NoSQL – MongoDB Advanced Topics questions (14)

Go through each question and its explanation. Use this set as a focused practice pack for MongoDB/NoSQL.

Back to MongoDB/NoSQL subject page

1. Explain geospatial indexes in MongoDB. What are the differences between 2d and 2dsphere indexes?

Difficulty: MediumType: SubjectiveTopic: Indexing

Geospatial indexes in MongoDB enable efficient queries on location data, allowing you to find documents based on geographic coordinates. MongoDB supports two types of geospatial indexes: 2d for flat geometries and 2dsphere for spherical geometries. 2d indexes are designed for flat, two-dimensional coordinate systems like maps. They work with legacy coordinate pairs represented as arrays of two numbers. 2d indexes support queries within rectangles, circles, and polygons on a flat plane. Use 2d indexes when your data represents points on a flat map, such as game positions or floor plans. 2dsphere indexes work with spherical geometries that model the Earth's surface. They use GeoJSON format to represent points, lines, and polygons considering the Earth as an oblate spheroid. This provides accurate distance calculations for geographic coordinates like GPS locations. 2dsphere indexes support queries like finding locations within a certain distance, within a polygon, or along a route. GeoJSON format specifies geometry types and coordinates. A point is defined with type Point and coordinates as longitude then latitude. A polygon is defined with type Polygon and an array of coordinate arrays forming closed rings. MongoDB provides geospatial query operators like dollar near for proximity queries, dollar geoWithin for area queries, and dollar geoIntersects for intersection queries. Geospatial queries are essential for location-based applications like finding nearby restaurants, delivery routing, ride-sharing services, or real estate searches. The 2dsphere index is recommended for most geographic applications because it accounts for the Earth's curvature and provides more accurate results.

Continue your preparation

For complete preparation, combine this set with full subject-wise practice for MongoDB/NoSQL. You can also explore other subjects and sets from the links below.

Quick navigation:MongoDB/NoSQL subject page•All subjects

2. What are Change Streams in MongoDB and what are practical use cases for them?

Difficulty: MediumType: SubjectiveTopic: Change Streams

Change Streams allow applications to access real-time data changes without the complexity of tailing the oplog. They provide a high-level API for subscribing to data changes across collections, databases, or entire clusters. Change Streams are built on top of the oplog and are available on replica sets and sharded clusters starting from MongoDB 3.6. Change Streams capture insert, update, replace, and delete operations as they occur. When you open a change stream, you receive a cursor that emits change events as documents are modified. Each event includes the operation type, the affected document or document key, and the timestamp. Practical use cases are numerous. First, cache invalidation where you update application caches when data changes in MongoDB. When a product price changes, you can immediately invalidate the cached price and fetch the new value. This keeps caches synchronized without polling. Second, real-time notifications where you push updates to users. For example, in a social media application, notify users when someone likes their post or sends a message. Change Streams detect these inserts and trigger notifications immediately. Third, data synchronization across systems where you replicate changes to other databases, search engines, or data warehouses. When an order is placed in MongoDB, you can push the order to an analytics database or update a search index in Elasticsearch. Fourth, audit logging where you record all changes to sensitive collections for compliance. Change Streams capture who changed what and when, creating an audit trail. Fifth, microservices communication where services react to data changes in other services, enabling event-driven architectures. Change Streams support filtering using aggregation pipeline syntax, allowing you to subscribe only to relevant changes. You can resume from a specific point using resume tokens, ensuring no events are missed during application restarts.

Example code

// Watch entire collection
const changeStream = db.collection('products').watch()

changeStream.on('change', (change) => {
  console.log('Change event:', change)
  
  switch(change.operationType) {
    case 'insert':
      handleNewProduct(change.fullDocument)
      break
    case 'update':
      invalidateCache(change.documentKey._id)
      break
    case 'delete':
      removeFromSearch(change.documentKey._id)
      break
  }
})

// Watch with filter - only completed orders
const pipeline = [
  {
    $match: {
      'operationType': 'insert',
      'fullDocument.status': 'completed'
    }
  }
]

const orderStream = db.orders.watch(pipeline)
orderStream.on('change', (change) => {
  // Trigger fulfillment process
  processOrder(change.fullDocument)
})

// Resume from token (after restart)
const resumeToken = getLastProcessedToken()
const resumableStream = db.orders.watch([], {
  resumeAfter: resumeToken
})

// Use case: Real-time dashboard
db.sales.watch().on('change', (change) => {
  if (change.operationType === 'insert') {
    updateDashboard(change.fullDocument)
    websocket.broadcast('newSale', change.fullDocument)
  }
})

3. What are the essential best practices for deploying MongoDB in production environments?

Difficulty: HardType: SubjectiveTopic: Production Ops

Deploying MongoDB in production requires careful planning and adherence to best practices to ensure reliability, performance, and security. These practices span architecture, configuration, operations, and monitoring. First, always use replica sets even for single-server deployments. Replica sets provide high availability through automatic failover and data redundancy. Use at least three data-bearing members across different availability zones or data centers for maximum resilience. Configure appropriate write and read concerns based on your durability requirements. Second, properly size your hardware and infrastructure. Ensure your working set fits in RAM for optimal performance. Working set is the frequently accessed data and indexes. MongoDB performance degrades significantly when the working set exceeds available memory. Use SSD storage for data directories to improve I/O performance. Allocate sufficient CPU cores for concurrent operations. Third, implement comprehensive monitoring and alerting. Track key metrics including query performance, replication lag, connection counts, memory usage, disk I/O, and error rates. Set up alerts for abnormal conditions like high replication lag, low disk space, or connection saturation. Use MongoDB Cloud Manager, Ops Manager, or integrate with tools like Prometheus and Grafana. Fourth, establish backup and disaster recovery procedures. Implement automated backups with point-in-time recovery capability. Test restore procedures regularly to verify backups work. Store backups in a different geographic location. Document recovery time objectives and recovery point objectives, and ensure procedures meet these targets. Fifth, implement security hardening. Enable authentication and authorization, use TLS for all connections, implement network security through firewalls and VPNs, enable encryption at rest for sensitive data, configure auditing for compliance, and keep MongoDB updated with security patches. Sixth, optimize for your workload. Create appropriate indexes based on query patterns, but avoid over-indexing which slows writes. Use covered queries where possible. In sharded clusters, choose shard keys carefully to ensure even distribution and support common queries. Seventh, manage connection pooling properly. Configure appropriate connection pool sizes in drivers to balance concurrency with resource usage. Monitor connection counts and adjust pool sizes if needed. Finally, document your deployment architecture, configurations, and operational procedures for your team.

Example code

// Production configuration example (mongod.conf)

// Network settings
net:
  port: 27017
  bindIp: 10.0.0.5,127.0.0.1  // Private IP + localhost
  maxIncomingConnections: 1000
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem

// Security
security:
  authorization: enabled
  keyFile: /etc/mongodb/keyfile  // Replica set auth

// Storage
storage:
  dbPath: /data/mongodb
  engine: wiredTiger
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8  // 50% of RAM
      journalCompressor: snappy
    collectionConfig:
      blockCompressor: snappy

// Replication
replication:
  replSetName: "production-rs"
  oplogSizeMB: 10240  // 10GB oplog

// System resource limits
processManagement:
  fork: true
  pidFilePath: /var/run/mongodb/mongod.pid

// Operational logging
systemLog:
  destination: file
  path: /var/log/mongodb/mongod.log
  logAppend: true
  logRotate: reopen

// Profiling (disable in production, enable when troubleshooting)
operationProfiling:
  mode: slowOp
  slowOpThresholdMs: 100

// Best practices checklist:
// ✓ Replica set with 3+ members
// ✓ Authentication and authorization enabled
// ✓ TLS encryption
// ✓ Monitoring and alerting configured
// ✓ Automated backups
// ✓ Proper hardware sizing (working set in RAM)
// ✓ Connection limits configured
// ✓ Regular security updates
// ✓ Documented procedures

7. What are the different backup and recovery strategies for MongoDB? Compare their advantages and disadvantages.

Difficulty: HardType: SubjectiveTopic: Backup

MongoDB offers several backup and recovery strategies, each with different trade-offs between consistency, performance impact, and ease of use. Choosing the right strategy depends on your recovery time objectives, data size, and operational requirements. First, mongodump and mongorestore are utility tools that create logical backups by reading documents and writing them to BSON files. Advantages include simplicity, platform independence, and ability to backup specific databases or collections. Disadvantages are that they are slow for large datasets, do not capture a point-in-time snapshot by default, and require significant I/O resources. Second, file system snapshots create binary copies of data files at the storage layer. Cloud providers and storage systems offer snapshot features that create consistent copies almost instantly. Advantages include speed, minimal performance impact, and point-in-time consistency. Disadvantages are dependency on specific storage systems and typically requiring the entire data directory. Third, MongoDB Cloud Manager and Ops Manager provide continuous backup with point-in-time recovery. They take periodic snapshots and capture oplog entries between snapshots, allowing you to restore to any point in time. Advantages include automated scheduling, point-in-time recovery, and minimal manual intervention. Disadvantages are cost for cloud services and complexity for on-premises Ops Manager. Fourth, delayed replica set members can serve as a live backup. Configure a secondary with a replication delay of several hours. If data corruption or accidental deletion occurs, you can recover from the delayed member before it replicates the problem. Advantages include continuous availability and simple recovery. Disadvantages are resource overhead and limited recovery window. Best practices include testing your backup and recovery procedures regularly, storing backups in a different location or region, encrypting sensitive backups, and documenting recovery procedures. Combine multiple strategies for defense in depth.

Example code

// Method 1: mongodump and mongorestore
// Backup entire database
mongodump --host=localhost --port=27017 --db=mydb --out=/backup/

// Restore from backup
mongorestore --host=localhost --port=27017 --db=mydb /backup/mydb/

// Method 2: File system snapshot (example with LVM)
lvcreate --size 10G --snapshot --name mongodb-snap /dev/vg0/mongodb
tar czf /backup/mongodb-snap.tar.gz /mnt/mongodb-snap
lvremove /dev/vg0/mongodb-snap

// Method 3: Delayed replica set member
// Configure secondary with 4-hour delay
var cfg = rs.conf()
cfg.members[2].priority = 0
cfg.members[2].hidden = true
cfg.members[2].slaveDelay = 14400  // 4 hours in seconds
rs.reconfig(cfg)

// Recovery from delayed member:
// 1. Stop delayed secondary
// 2. Copy its data files
// 3. Restore primary from these files

// Method 4: Continuous backup (conceptual)
// MongoDB Atlas automated backups:
// - Snapshots every 6-24 hours
// - Oplog between snapshots
// - Point-in-time restore to any second

8. What security measures should you implement for a production MongoDB deployment?

Difficulty: HardType: SubjectiveTopic: Security

Securing a production MongoDB deployment requires multiple layers of protection covering authentication, authorization, network security, encryption, and auditing. Following security best practices is essential to protect sensitive data and prevent unauthorized access. First, enable authentication and require all clients to authenticate before accessing the database. MongoDB supports various authentication mechanisms including SCRAM-SHA-256, LDAP, Kerberos, and x.509 certificates. Never run MongoDB without authentication in production. Create users with strong passwords and rotate credentials regularly. Second, implement role-based access control with the principle of least privilege. Create custom roles that grant only the minimum permissions needed for each user or application. MongoDB provides built-in roles like read, readWrite, dbAdmin, and userAdmin, but custom roles offer fine-grained control. Regularly audit user permissions and remove unnecessary access. Third, secure network access using firewalls, VPNs, or private networks. Bind MongoDB to specific network interfaces rather than all interfaces, and use IP whitelisting to restrict which hosts can connect. Never expose MongoDB directly to the internet without proper network security. Fourth, enable encryption both at rest and in transit. Use TLS/SSL for client connections and inter-node communication in replica sets and sharded clusters. Enable encryption at rest to protect data files from unauthorized access if physical media is compromised. MongoDB Enterprise edition provides native encryption at rest. Fifth, enable auditing to track database access and changes. Audit logs help detect suspicious activity, comply with regulations, and investigate security incidents. MongoDB Enterprise edition provides comprehensive auditing features. Sixth, keep MongoDB and drivers updated with the latest security patches. Follow MongoDB security advisories and apply patches promptly. Seventh, implement backup encryption and secure backup storage. Finally, use security scanning tools to detect vulnerabilities and misconfigurations.

Example code

// 1. Enable authentication
// Start MongoDB with --auth flag
mongod --auth --port 27017 --dbpath /data/db

// Create admin user
use admin
db.createUser({
  user: "admin",
  pwd: "SecurePassword123!",
  roles: [{ role: "userAdminAnyDatabase", db: "admin" }]
})

// 2. Create application user with limited permissions
use myapp
db.createUser({
  user: "appUser",
  pwd: "AppPassword456!",
  roles: [
    { role: "readWrite", db: "myapp" }
  ]
})

// 3. Custom role with specific permissions
use admin
db.createRole({
  role: "reportsReader",
  privileges: [
    {
      resource: { db: "analytics", collection: "reports" },
      actions: ["find"]
    }
  ],
  roles: []
})

// 4. Network security in config file
net:
  bindIp: 127.0.0.1,10.0.0.5  // Specific IPs only
  port: 27017
  tls:
    mode: requireTLS
    certificateKeyFile: /path/to/cert.pem
    CAFile: /path/to/ca.pem

// 5. Enable encryption at rest (Enterprise)
security:
  enableEncryption: true
  encryptionKeyFile: /path/to/keyfile

// 6. Enable auditing (Enterprise)
auditLog:
  destination: file
  format: JSON
  path: /var/log/mongodb/audit.json

10. What are the key differences between WiredTiger and MMAPv1 storage engines? Why was WiredTiger introduced?

Difficulty: MediumType: SubjectiveTopic: Storage

WiredTiger and MMAPv1 are two storage engines in MongoDB with significant differences in architecture and performance characteristics. MMAPv1 was the original storage engine but is now deprecated, while WiredTiger is the default since MongoDB 3.2. The primary difference is concurrency control. MMAPv1 uses collection-level locking, meaning only one write operation can occur per collection at a time. This creates bottlenecks in write-heavy workloads. WiredTiger uses document-level locking, allowing multiple write operations to different documents in the same collection simultaneously. This dramatically improves write throughput. Second, WiredTiger supports compression of both data and indexes using snappy or zlib algorithms. This reduces storage requirements by 50-80 percent and improves I/O performance because less data needs to be read from disk. MMAPv1 does not support compression. Third, WiredTiger uses checkpoints and write-ahead logging for crash recovery and durability. Checkpoints are snapshots of data written to disk every 60 seconds, while the journal records operations between checkpoints. This provides better recovery guarantees than MMAPv1's journaling. Fourth, WiredTiger uses a cache to hold frequently accessed data in memory. The cache size is configurable and defaults to 50 percent of RAM minus 1 GB. MMAPv1 relied on the operating system's file system cache, giving less control over memory usage. WiredTiger was introduced to address MMAPv1's limitations in write performance, storage efficiency, and concurrency. It provides better performance for most workloads, especially write-heavy applications, and is now the only supported storage engine in modern MongoDB versions.

Example code

// WiredTiger configuration
storage:
  engine: wiredTiger
  wiredTiger:
    engineConfig:
      cacheSizeGB: 4  // Internal cache size
      journalCompressor: snappy
    collectionConfig:
      blockCompressor: snappy  // Data compression
    indexConfig:
      prefixCompression: true  // Index compression

// WiredTiger features:
// - Document-level locking (high write concurrency)
// - Compression (60% space savings typical)
// - Checkpoints every 60 seconds
// - Write-ahead logging (journal)
// - Configurable cache

// MMAPv1 (deprecated):
// - Collection-level locking (write bottleneck)
// - No compression
// - Power-of-2 sized allocations (wasted space)
// - Relies on OS file system cache

11. How do you monitor and troubleshoot MongoDB performance issues in production?

Difficulty: HardType: SubjectiveTopic: Monitoring

Monitoring and troubleshooting MongoDB performance requires a systematic approach using built-in tools, metrics analysis, and query optimization techniques. Proactive monitoring helps identify issues before they impact users. First, use MongoDB's built-in monitoring tools. The db.serverStatus command provides comprehensive metrics including connections, memory usage, operations, network traffic, and storage statistics. The db.currentOp command shows currently running operations, helping identify long-running queries. The mongostat utility displays real-time statistics on operations, connections, and resource usage. Second, enable database profiling to capture slow queries. The profiler records queries exceeding a specified threshold to the system.profile collection. Set profiling level 1 to log slow queries or level 2 to log all queries. Analyze profiled queries to identify optimization opportunities. Use explain method on slow queries to understand execution plans and index usage. Third, monitor key performance metrics. Watch for high query execution times, low cache hit ratios indicating insufficient memory, high page faults showing working set exceeds RAM, connection saturation, replication lag in replica sets, and uneven shard distribution in sharded clusters. Set up alerts for abnormal values. Fourth, use monitoring platforms like MongoDB Cloud Manager, Ops Manager, or third-party tools like Prometheus and Grafana. These provide historical trending, alerting, and dashboards. They help identify patterns and correlate metrics across multiple servers. Fifth, when troubleshooting specific issues, follow a structured approach. For slow queries, use explain to check if indexes are used, verify index selectivity, and ensure query patterns match shard keys in sharded clusters. For memory issues, check working set size versus available RAM and consider adding memory or sharding. For write performance, verify write concern settings, check for lock contention, and ensure indexes are not over-indexed causing write overhead. Regularly review and optimize indexes, remove unused indexes, monitor index size and fragmentation, and rebuild indexes if needed. Test changes in staging environments before applying to production.

Example code

// 1. Check current operations
db.currentOp({
  "active": true,
  "secs_running": { "$gt": 5 }  // Running > 5 seconds
})

// Kill long-running operation
db.killOp(12345)

// 2. Enable profiling for slow queries (> 100ms)
db.setProfilingLevel(1, { slowms: 100 })

// Analyze slow queries
db.system.profile.find().sort({ ts: -1 }).limit(10)

// 3. Get server statistics
db.serverStatus()

// Key metrics to monitor:
// - connections.current (connection count)
// - opcounters (operations per second)
// - mem.resident (RAM usage)
// - wiredTiger.cache (cache statistics)
// - network.bytesIn/bytesOut
// - repl.lag (replication lag)

// 4. Check database statistics
db.stats()

// 5. Analyze query performance
db.orders.find({ customerId: 123 }).explain("executionStats")

// Look for:
// - executionTimeMillis (total time)
// - totalDocsExamined vs totalDocsReturned
// - stage: "IXSCAN" (using index) vs "COLLSCAN" (full scan)

// 6. Check index usage statistics
db.orders.aggregate([{ $indexStats: {} }])

// 7. Monitor with mongostat (external command)
mongstat --host localhost:27017 5
// Shows operations, memory, connections every 5 seconds

14. Explain multi-document transactions in MongoDB. How do they ensure ACID properties and what are their limitations?

Difficulty: HardType: SubjectiveTopic: Transactions

Multi-document transactions in MongoDB allow you to execute multiple operations across multiple documents and collections atomically, ensuring ACID properties: Atomicity, Consistency, Isolation, and Durability. Either all operations in a transaction succeed and are committed, or all fail and are rolled back. Atomicity means all operations in the transaction complete successfully or none do. If any operation fails, all previous operations are rolled back. Consistency ensures the database moves from one valid state to another. Isolation means concurrent transactions do not interfere with each other. Durability guarantees committed transactions survive system failures. To use transactions, you start a session, begin a transaction, perform operations passing the session to each operation, and then commit or abort the transaction. MongoDB uses write-ahead logging and the oplog to implement transaction guarantees. During a transaction, changes are not visible to other operations until commit. Transactions have important limitations. First, they are only available on replica sets and sharded clusters, not standalone instances. Second, they have a 60-second default timeout and are subject to the 16 MB oplog entry size limit. Third, transactions that affect multiple shards have additional overhead. Fourth, transactions should be kept short because they hold locks on documents. Long-running transactions can block other operations and affect performance. Fifth, DDL operations like creating indexes cannot be performed inside transactions. Finally, transactions add latency compared to individual operations, so use them only when atomicity across multiple documents is truly required.

Example code

// Bank transfer example - ACID transaction
const session = client.startSession()

try {
  session.startTransaction({
    readConcern: { level: 'snapshot' },
    writeConcern: { w: 'majority' }
  })
  
  // Deduct from account 1
  const result1 = await db.accounts.updateOne(
    { _id: 'account1', balance: { $gte: 100 } },
    { $inc: { balance: -100 } },
    { session }
  )
  
  if (result1.modifiedCount === 0) {
    throw new Error('Insufficient funds')
  }
  
  // Add to account 2
  await db.accounts.updateOne(
    { _id: 'account2' },
    { $inc: { balance: 100 } },
    { session }
  )
  
  // Record transaction
  await db.transfers.insertOne(
    { from: 'account1', to: 'account2', amount: 100 },
    { session }
  )
  
  // Commit - all or nothing
  await session.commitTransaction()
  
} catch (error) {
  // Rollback all changes
  await session.abortTransaction()
  throw error
} finally {
  session.endSession()
}

Master Interviews
Anywhere, Anytime

MongoDB Advanced Topics – MongoDB/NoSQL interview questions

Set overview

MongoDB/NoSQL – MongoDB Advanced Topics questions (14)

1. Explain geospatial indexes in MongoDB. What are the differences between 2d and 2dsphere indexes?

Continue your preparation

2. What are Change Streams in MongoDB and what are practical use cases for them?

3. What are the essential best practices for deploying MongoDB in production environments?

4. What is a key characteristic of capped collections in MongoDB?

5. Which storage engine is the default in MongoDB 3.2 and later?

6. When should you use GridFS in MongoDB?

7. What are the different backup and recovery strategies for MongoDB? Compare their advantages and disadvantages.

8. What security measures should you implement for a production MongoDB deployment?

9. What happens to documents when a TTL (Time To Live) index expires them?

10. What are the key differences between WiredTiger and MMAPv1 storage engines? Why was WiredTiger introduced?

11. How do you monitor and troubleshoot MongoDB performance issues in production?

12. What do Change Streams in MongoDB allow applications to do?

13. What is required to use multi-document transactions in MongoDB?

14. Explain multi-document transactions in MongoDB. How do they ensure ACID properties and what are their limitations?

More sets in MongoDB/NoSQL

Explore related subjects

Master Interviews Anywhere, Anytime

MongoDB Advanced Topics – MongoDB/NoSQL interview questions

Set overview

1. Explain geospatial indexes in MongoDB. What are the differences between 2d and 2dsphere indexes?

Continue your preparation

2. What are Change Streams in MongoDB and what are practical use cases for them?

3. What are the essential best practices for deploying MongoDB in production environments?

4. What is a key characteristic of capped collections in MongoDB?

5. Which storage engine is the default in MongoDB 3.2 and later?

6. When should you use GridFS in MongoDB?

7. What are the different backup and recovery strategies for MongoDB? Compare their advantages and disadvantages.

8. What security measures should you implement for a production MongoDB deployment?

9. What happens to documents when a TTL (Time To Live) index expires them?

10. What are the key differences between WiredTiger and MMAPv1 storage engines? Why was WiredTiger introduced?

11. How do you monitor and troubleshoot MongoDB performance issues in production?

12. What do Change Streams in MongoDB allow applications to do?

13. What is required to use multi-document transactions in MongoDB?

14. Explain multi-document transactions in MongoDB. How do they ensure ACID properties and what are their limitations?

More sets in MongoDB/NoSQL

Explore related subjects

Master Interviews
Anywhere, Anytime