Introduction

If you are willing to take the MongoDB Data Modeling Exam and are looking for someone who can explain it from A to Z, how to prepare, and strategies for the exam, you are in the right place. I published this article because when I went through the exam, there weren’t any resources available from someone who had already done it. So here we are.

Having paid for it from my own pocket, I can provide an unbiased breakdown. Don’t worry, I will also tell you how to get a discount.

Why I took the MongoDB Data Modeler Exam

The truth is that I am not one of those developers with years and years of experience under their belt. I started developing about five years ago, and even though I got to a point where I am comfortable with what I know, a) It is never enough, and b) I get bored quickly.

Also, since experience can’t be gained faster than the pace of the clock, I rely on certifications to challenge myself. At this point, I might have about 30.

So there we were: me, my 30 certifications, my boredom, and the fact that I saw that MongoDB had a new one… The challenge was screaming my name. Also, I already had the C100DEV certification when Mongo was sitting in its 4.4 version—time flies by—so the foundations were there.

Exam Overview

The exam is about designing data structures and applying design patterns to them. What does this mean? Given data requirements, query needs, and other parameters, you should find the pattern that will fit better for the use case.

For example, you are working on an application that stores Posts. Each Post can hold several Users’ Comments. So, we have three entities: Posts, Users, and Comments.

How should you model that relationship?

If you come from the SQL world, the first answer that might come to your mind is: “Easy! Create a post document that can hold an array of the comments’ IDs. Store the comments in a different collection.”

In MongoDB culture, that is called to reference, *which is the opposite of *to embed. For this use case, that may not be the most adequate solution. While it takes care of the unbounded growth of the comments, the reads will be relatively slow since they will need to query two collections. Comments are often queried for reads, not for writes.

What MongoDB recommends is actually to live and breathe for the moto:

Data that is accessed together should be stored together.

So, going back to our example, as long as you know that the comments can’t exceed the maximum file size of 16MB per document, you should store them as an array of documents inside the Post entity. That is called the Embedded Document Pattern. It is helpful for read-heavy queries, fast data retrieval, and simplicity. On the other hand, it may not scale very well, and writes could be slow if there is a peak.

I know what you are thinking right now. Most Posts will be okay with that for a while, but some will have an incredible number of comments that may outgrow the maximum file size.

In that case, you can mix it up by embedding the last 10–20 comments and moving the rest to a separate collection. You will pay some latency price on every write, but reads will be simplified. This is called the Subset pattern.

As you can see, there is no “one size fits all” solution: the answer is always “it depends,” you need to have all the information, and pay attention to the small details.

Getting a discount for the exam

As of April 2024, the good news is that if you finish their Learning Path, you get a 50% discount on the price of the exam, resulting in a total of $75 instead of $150. If you are a student or educator, you get a 100% discount — but you still need to complete the Learning Path.

There is no reason not to go over the content: you can “finish” the learning path by skipping all the labs — they are optional; failing all the quizzes — you need to complete them, not pass them; and waiting 5 seconds on each video until it marks it as “visited.” With that technique, you can get the discount in 20ish minutes of skipping content without consuming it. That is up to you.

Their learning dashboard was renewed since I last signed in in 2021. It looks nice, but the UI for the learning path is cumbersome.

The Exam Format

Once you buy your exam (link here), you can schedule it in Examity, the platform that provides it. The booking hours were broad, with slots usually available the next day. You must upload some ID, undergo computer checks for hardware, and fill in some details.

I recommend connecting to the platform 15 minutes before your scheduled hour on the exam day because all the setups and ceremonies with your proctor take time.

If you don’t know what a “proctored exam” means, a person will constantly monitor you through your webcam for the extent of the exam. You will usually need to clear the desk where you will take it: no extra monitors, no papers on top, and nothing else than your laptop or computer. You will need to take your laptop for a walk inside the room to show that no one is hiding in it. For me, that is as cringe as it gets, but rules are rules.

The official length of the exam is 1 hour and 45 minutes, but it can be done in less time, even for non-native English speakers. It has 70 multiple-choice questions. You can go to the bathroom and take a break, but when you return, you must show again with your webcam that no one is in the room or hiding under the desk 😂.

Only 60 of those questions count toward your score; 10 are for testing new variants, but you won’t know which ones count. You must clear at least 70% of them, meaning you should correctly answer 49 out of 70 to pass.

For the multiple-choice questions, most are “choose the right answer,” but some of them require marking two out of four or five options.

Timewise, the timeframe is generous: 105 minutes for 70 questions means you will have about 70 minutes to answer calmly and some 35 to double-check your answers. This is more than enough to go over all your marked questions for review.

As a reference, I averaged about 1 minute per question: I read each question meticulously, thought a bit about it, and double-checked my answers before moving to the next. I didn’t rush it, quite the opposite. I stopped to think when I needed to, but I didn’t spend too much time — if I were troubled, I would pick the best option, mark it, and revise it later. Of the 35 minutes remaining, I only used about 15 to modify the bookmarked questions, finishing my exam 20 minutes earlier than what was stipulated.

How to NOT prepare for the exam

As mentioned, MongoDB has crafted content called MongoDB University. This was not the first time I went through their lectures, quizzes, and labs; I did that some time ago for the Developer exam.

While the developer exam content was definitely worth the deep dive, the resources provided for this certification were too superficial and naive. You can check them out here. It is a 9-hour course, divided into 7 slow-paced parts, and it is free to take. None of the content provided will help you pass the exam; it is just enough for you to get the broader picture and understand the foundational concepts. It includes some quizzes after each chapter to check your knowledge, and while it is nice to have, the questions don’t get even close to the real deal. The labs are more challenging, but you won’t get those tasks in the exam. The videos can be sped up to 1.50–1.75x easily.

There is no chance that someone will clear the exam by only finishing this. It can be enough to clear the “easy” questions, but about half of the exam requires more in-depth knowledge. Don’t worry; I will point you to the right resources so you can clear it on the first try.

Additionally, MongoDB provides a practice test with 25 questions. These questions are closer to the exam's difficulty level but intentionally less challenging, so achieving a high score doesn’t necessarily reflect what you’ll encounter in the exam. A good resource, but not enough.

Let’s go over the Study Guide.

First, if you have some general knowledge of MongoDB and common sense and have finished your Learning Path, you can cover the exam's first 30–35 questions. That's not bad.

To cover the second half of the exam, I recommend you to go over the official study guide subjects and their descriptions:

• Requirements Gathering (10%)

• Entities (13%)

• Relationships (8.5%)

• Workload/Usage (10%)

• Data model Design (28%)

• Modeling for technical requirements (10%)

• Indexing (13%)

• Monitoring and evolving Data models (7.5%)

Let’s go over each one by one.

• Requirements gathering: Ensure you read the questions correctly and notice small clues that might change the answer. Look for details on the write speed: If it says something like “fast writes are required,” you will know to cross out some patterns. Also, sometimes, they specify that they want to model for “scalability,” meaning that embedding will probably not be the right option. Pay attention to those clues. It also appeared a lot regarding questions with analytics: sometimes they will say that the analytic needs to be computed on the fly, and sometimes they will suggest that it can be pre-computed and stored in a separate collection, for example: “the data modeler requires to review the analytics once a month.” Be sharp on all the data models to recognize these clues quickly.

• Entities: You will need to know what weak and strong entities are and the relationships between them. This section is a walk in the park.

• Relationships: You should know the basic one-to-one, one-to-many, and many-to-many. Something that surprised me was that I had questions about one-to-few. This article covers this topic very well. I didn’t encounter questions about one-to-squillions in my exam. Usually, these were among the easy questions, too.

• Workload/Usage: This section relates to the first one, where understanding correctly the needs of the situation described in the question plays a crucial role in choosing the correct answer. Something that you should know is how to identify the workload. Ensure you understand the whole chapter of query optimization, especially how to read the results of an explain command, the winning plan explained in the executionStats, and the interpretation of the results. Some questions were addressed with “on some query…. there are X amount totalKeysExamined and Y amount of totalDocsExamined while nReturned was Z”. This subject also relates to indexes because sometimes changing or adding an index improves these results (see Indexing item below for further details). This section is also about historical data. When you have a “historical data” requirement, a TTL index will probably be involved, and a separate collection will be needed to store that data; keep that in mind.

• Data model design: This is the essential unit in the exam. Go over all 12 patterns and ensure you know them by heart. Some questions will be formulated in a somewhat unclear situation where two different patterns might be a good fit, typically between bucket or pre-computed. Again, pay attention to the small details of the questions. Ensure you understand when to embed, reference, and choose a proper model based on scalability or efficiency on reads or writes. One thing that you need to have in mind in this section is JSON Schema validation: how to create a schema, how to make elements unique, and how to lock elements to a list (enum). Go over the official documentation; while creating a schema is a simple task, some questions pertained to details in the validationLevel or validationAction fields. Ensure you know what happens when you try inserting an invalid document with validationLevel set to strict and moderate. Same thing for validationAction. We can agree that encountering 3–4 questions about this in the exam was slightly nitpicked.

• Modeling for technical requirements: This unit relates tightly to requirements Gathering and Data Model Design. They could be grouped: combined, they total 53% of the questions. In this unit, you should focus on each model's limitations, disadvantages, and trade-offs. Ensure you know when not to use a model: sometimes, crossing out nonviable options will lead you to the correct answer rather than striking the right one.

• Indexing: Indexing was a subject that appeared frequently in my exam. You should know how indexes work, how to optimize them, and all their perks and whistles: compound indexes, multi-key, partial indexes, sparse indexes, clustered indexes, and TTL indexes. This unit also covers partial Indexes using the partialFilterExpression. One tricky case that I encountered is that some questions asked to choose the proper way to index a collection, and something like these two options were provided:
  

    db.restaurants.createIndex(
       { cuisine: 1,
       { partialFilterExpression: { cuisine: { $exists: true } } }
    )

    db.restaurants.createIndex(
       { cuisine: 1 }
    )

• While the first query looks like a partial filter, it uses the filter expression that would create a sparse index. The difference between a regular index and a sparse one — besides that some documents won’t be indexed with the sparse — is that regular indexes contain all documents in a collection, storing null values for those documents that do not include the indexed field. In contrast, those documents won’t be stored on the sparse index. Keep that detail in mind.

• You should also go over the documentation on hidden indexes and TTL indexes. I encountered some questions in the exam on using TTL indexes to make documents expire after a specific time (e.g., one hour) or date. I can’t recall whether I came across questions about clustered indexes, but make sure you know what you can/can’t do with them.

• I also ran into questions where you have at least two common queries that share some fields and must choose the best index strategy.

• Monitoring and evolving Data models: You should know how and when a data model needs to be updated based on data changes — increased throughput, peak demands, analytics, and new requirements. Understand how you can capitalize on the db.collection.stats() command, as well as in the db.serverStatus(), specially in the indexStats section. Remember that you can also access the indexStats through aggregation.

What you won’t need for the exam

In my case, I didn't encounter any of the following:

• Questions about shards

• Questions about clusters

• Questions about how to run some query commands in a collection

• Questions about journaling or the WiredTiger engine

• Questions about transactions.

It makes sense since those subjects weren’t listed in the study guide, but you never know.

What took me by surprise

One thing that I noticed is that the exam presents an imbalanced level of difficulty among the questions. While some questions were easy-peasy, as simple as the ones in their practice exam, others weren’t for the faint-hearted. They dove so much into niche subjects that you must remember particular configurations, like the ones on validationAction.

Another subject that caught me off guard leveraging some 2–3 questions, was write concerns. I remember having a question about what would happen if an insertOne operation with a write concern of “majority” and a timeout of 5000 fails to achieve that under that time. I needed to know exactly how it would respond:

wtimeout causes write operations to return with an error after the specified limit, even if the required write concern will eventually succeed. When these write operations return, MongoDB does not undo successful data modifications performed before the write concern exceeded the wtimeout time limit.

Lastly, in the entities section, I encountered 1–2 questions that included an element of Domain. I couldn’t find anything specific about what they wanted from my life, so I chose whatever was right for me.

Wrapping up

You can review the Learning Path to get the basics, but you will need to dive deeper into the documentation and the subjects mentioned here. Make sure you understand:

• The 12 design patterns that MongoDB recommends, with its advantages and disadvantages, as well as application cases,

• Entities and their relationships and how they relate to design patterns,

• How indexes work, how to optimize them, and all their perks and whistles: compound indexes, multi-key, partial indexes, sparsed indexes, clustered indexes, and TTL indexes,

• JSON Schema validation: creating a schema, making elements unique, and locking elements to a list (enum). You will also need to know the different levels of validationLevel available, the default behavior, and the same for validationAction,

• You will need to know to read the result of an execution plan and recommend actions based on that,

• Implementation details on write concern.

Combine the Learning Path, the practice exam, the documentation, and the tips provided here to level up your knowledge and ensure you can hit 85% or above in any mock exam you encounter. Free some 2 hours for the exam; start it 15 minutes before.

All in all, it is not a challenging exam if you understand the concepts, and if you do well enough, you will get a badge like this one:

Good luck with the exam 🤞!