MongoDB DBA associate exam pilot

With each of the three MongoDB courses I passed my satisfaction of finishing yet another course drooped. I feel that passing a course doesn’t truly reflect skill with nor knowledge of the course’s subject. The main reason for this is that with careful reading of the homework assignments and roughly a week to do an open book final exam, in my opinion, anyone could pass with a score over 80% easily.

For each of the courses I easily scored 95% or higher as a final grade by careful reading and taking my time to experiment during the final exam to make sure I picked the right answer. In fact, the only reason I didn’t get perfect scores in two of the exams was because in hindsight I didn’t read a question properly. Therefore, in my opinion, passing a course founded on self-study without a time limit on the exam doesn’t show your true level in grasping the MongoDB subject at hand. It just shows you can read and understand English well enough to pass or perhaps cheat your way to that perfect score.

Finally a meaningful certificate

In the last week of September I got an invitation to take part in a pilot for the MongoDB DBA Associate Exam. The email said the closed-book exam would have roughly 100 multiple-choice questions with a time limit of two hours. During the exam there would be an audio and video recording to check for any form of cheating.

Reading about this exam got me excited to experience it, but the bad news was that I would be taking a vacation for most of the week that was available for the exam. The only days left would be the last two days it would be open, October 14th and 15th. I knew that on the 15th of October I couldn’t do the exam due to an important company meeting that evening.

I had to make a decision, take part in the pilot or not? There were only 150 spots available according to EventBrite and I assumed every person with a top score on a MongoDB DBA course (M102) got that email. This made me decide to sign up immediate, because it’s better to be fast and not take the exam, than to decide late and not have a spot. Should I decided not to participate, then perhaps my spot could be filled by someone else and it wouldn’t hurt the overall outcome for the pilot.

There probably was a pilot for developer associate exams as well, but I didn’t get a top score on either M101J (Java development for MongoDB) or M101JS (JavaScript development for MongoDB) which is probably why I didn’t get invited to that pilot.

Preparing for the exam

Having days off right before an exam is beneficial in most cases. It gives you the time to study or cram and get the best possible score out of the exam. I knew that would not be an option for me, because I would take the test one day after a long flight returning from the Philippines.

Most of the time of my trip would be spent away from computers. This meant that I could not experiment at all, which meant I could only rely on whatever I remembered from the MongoDB courses and any reading material I could find. My strategy was to focus on my weak points and brush up on the basics. This lead to the following list of topics:

  • Creating databases and collections
  • CRUD, the basics of getting data in and out of MongoDB
  • Replication, how to build a cluster and what happens during failover
  • Sharding, how to set it up and pick the right sharding key
  • Some tools, mongostat and mongotop

These topics would probably cover most of the exam. In my preparation I could only go through a PDF version of the manual for MongoDB and saved versions of blogs on my phone.

Taking the exam

While I was roaming around the other side of the world I got a mail mentioning a trial run for the exam, just to get familiar with the monitoring software. This made me consider doing the exam while in the Philippines. After some thought I knew this was not an option. My itinerary wouldn’t allow for access to a quiet room with a reliable high-speed internet connection. It’s rare to find that combination in a public place. There are high-speed internet cafes, but they are crowded with people using Skype or playing online games. The best place would be to take the test from home after hopefully a good night’s rest from the return flight.

It is hard to remember how much sleep I had between getting home and taking the test, but it certainly felt too short. Due to a six-hour time difference I woke up early on that Monday. The idea was to complete the test before heading of to work. I am in luck for having flexible working hours, up to a certain degree, which gave me enough time to complete the test.

First I had some breakfast and made sure I wouldn’t have to leave my desk for two hours. This included a toilet visit and switching off any distractions. Then I made sure there was enough light for the webcam. I had to turn on a spot light which would pointed at me for the next two hours.

When I started the preparations for the exam I had trouble getting my camera to focus on my passport for verification. The verification screenshot ended up a little blurred, but legible to me. I spent two hours fighting of yawns and scratching my head a few times while going through the questions and possible choices properly to finish the exam. At the end I cared less for actually passing the exam, it just had to end and I did my best to pick the most correct answers. After answering 96 questions I was tired. Needless to say, that day I wasn’t productive at work. Using lack of sleep and an exhausting trip as an excuse I got through the day.

Reviewing the exam

During the exam I couldn’t make any notes. There were no pen and paper on my desk, perhaps it wasn’t even allowed. So I took mental notes which I scribbled down later so I could write a blog about my experience. These notes included overall annoyances, annoyances to particular questions and subjects of the questions.

General annoyances

There were a few things that bothered me during the exam. First is that each time I went to the next page I had to scroll until I got to the first question of that page. Secondly, it would have been nice to know which questions I answered. The only way was to check if any of the check boxes was ticked. The third was that there didn’t seem to be any way of skipping a question in the exam to get back to it later. Because of the length of the exam and some of the questions, an overview page of questions left unanswered would have been nice.

Lengthy questions

Sometimes during the exam I had trouble answering a question just by the sheer length of its example or data. These questions might involve a lot of scrolling back and forth between the data and question. Think for example about an overview of indexes on a collection or a pretty printed document.

Poorly formatted questions

Some questions could have benefited of some editing. It seems question are just put into a general format not suited to display console output in a decent way. Take for instance wrapping long lines of output from the tools mongostat and mongotop. Depending on the width of the console the output is wrapped over several lines causing a chaotic overview where it’s hard to determine what data belongs to which column and row. This kind of poor formatting sucked away precious exam time. It’s true that is how output looks when you run a command line tool, but surely I am not going to waste time asking for all columns and looking at it in a poorly formatted way when I need that kind of data.

Tough questions

There were some tough questions in the exam. They made me think a lot about what was meant or were very confusing. One question was about the possibility to use a document as an index. Everything in the manual and during the courses I followed says it’s not a good idea, but still possible.

Another question was talking was asking for the output of a query where the data mentioned a different collection name than the one in the question. The data might have shown the indexes or an example document from a collection called shoes while the question asked something about a collection called gloves. Based on the data, there is no proof the gloves collection exists. Which made me answer that there would be zero results, considering that querying a non-existing collection is similar to querying an empty collection.


After completing the pilot exam I learned that there are a lot of DBA subjects I don’t know much about. The one I felt particularly uneasy about is the question if you can create an index that will use documents as its value and what the implications of such a choice are. Aside from that, I should put more time into studying the mechanics of fail-over and rollbacks in several scenarios, especially when delayed nodes are involved.

So what would you need to know if you want to pass the DBA exam? In my opinion you need a thorough knowledge of the following subjects:

  • English, if you don’t understand it you might not grasp some of the problems
  • Sharding
  • Replication
  • Failover
  • CRUD

Of course you need to experiment as well and the MongoDB course for DBAs and developers will give you some material to go through. The really difficult part is to experiment with sharding, replication and failovers. It will consume a lot of time and perhaps you need a lot of data to get a solid grasp on these topics.

With my knowledge I managed to pass, barely. The passing score was 70 and I got a score of 76. I can only assume that means that out of 96 questions I failed on 20 of them. Which I consider to be very high and not acceptable. In the week of November 11th I got a PDF of my certificate with ugly snapshot of my jetlagged face during the exam. A link should be following soon, but I haven’t received it yet.

Gimme everything you got slashes

Today I discovered a new bug. No, not the insect kind. It was a programming error. To be more specific, one that only showed up after fixing another one. Somehow using ‘//whatever’ as an XPath query on any node in a Document will give you all the nodes that match from the Document root. That’s because you said ‘//’, it means ‘I-don’t-know-where-it-is-but-I-want-it’.

Normally I would invoke it on the root of a XML document, so no problem there. But processing a collection of parts in a collection of parts will cause some problems. If you already know about the structure , then there is no need for the gimme-everything-you-got slashes!

Globally excluding commons-logging

Today I solved a long-lasting annoyance of mine, that lots of Java libraries in the Maven2 repository have a (transitive) dependency on Java Commons Logging (JCL). I prefer to use SLF4J instead, using JCL over SLF4J as implementation of the JCL API. Up till now, or actually 5 minutes ago, I had to do the RSI inducing task of using exclusions on every dependency which transitively depends on JCL. Not entirely error-proof, since forgetting to exclude it on even one dependency can horribly… mess up your day 🙂

Making yet another probably fruitless attempt at finding a solution to this annoyance, I happened to stumble upon a blog post of James Lorenzen. The solution there in part deals with my real problem, not wanting to use a transitive dependency at all but ignoring the bugger. The proposed, and working, solution is to use a scope of provided in your main POM which will root out the problem in sub projects as well. As mentioned, no more of that particular dependency in your distribution or whatever.

This is only part the problem in the case of JCL; I want it entirely out of the picture in my classpath. Here knowing the (dis)advantage of order in a classpath comes in. Of all classes with the same name in the same package on the classpath the classloader will load only the first one, ignoring the others. So how do we get the JCL stuff at the end of our classpath in Maven? Simply by adding it as the last “dependency” in your POM. Yes, not much to it actually.

This revelation really shortens my future POM files, especially in cases where my application consists of frameworks which are split up in many components all depending on that same logging library.