Personally my answer would be:
First utilise the warnings that the compiler provides, which in the case of some well known companies tool chain defaults to silent, by making sure that all the warnings were enabled. Actually I would recommend that the compiler warnings are all turned on and a coding standard used that called for zero warnings.
I would also strongly consider running static analysis with a tool such as Coverity, or even PCLint, as they are great at spotting potential issues like this.
Then I would run the entire test suite under a profiling tool to ensure that we had as near to 100% coverage as possible, then again under a checker such as Valgrind, or even the debugger if it support this.
Finally, and probably only if the tool chain & target did not support such tools and if I could not buy in a library to do this, I would consider implementing my own, either in a special build for test or as a background component of the product.
Only then, if asked to expand, I would start into how I would implement this.
If asked why this strategy I would reply cost, the compiler authors have spent a great many thousands of man hours addressing issues such as memory leaks, as have the static analysis tool developers and both provide 100% coverage of the code. Tools such as Valgrind can do an excellent job but only if the code is 100% exercised while they are watching - hence using a profiling tool to establish coverage.
Generally memory profiling tools do not belong in production code as, for the most part, they will normally be quite a heavy overhead and it is normally more effective to enable, install or enable garbage collection.
They may have been looking for you to mention RAII, Resource Acquisition Is Initialization, but strictly that is a strategy for avoiding rather than detecting memory leaks.