Whether you are configuring a 404 page or rewriting an url, at some point you'll ask yourself the question: Who takes care of what? Here are the main concepts.
IIS can been looked at as the system serving the pages, as .Net is more of a framework of libraries running on top of IIS. IIS therefore works as a fallback for all that is not handled within the .Net framework. For example the 404 pages. If you don't handle them from your application, IIS ´ll handle this for you giving you the typical IIS 404 error. The other way around IIS can also block code from being executed by .Net. An example of the last are mimetypes. Mimetypes determine the filetypes that are served to the users by IIS. If a font fails to load, one of the first things to check is whether the font is served by IIS. You can do this by requesting the font directly in the browser before you look into the application\solution.
The easiest way to understand the difference is that handlers handle mostly (they can do more) a complete range of extensions and modules do not. For example: you can create a handler that handels .aspx as well as a handler that handels images .png, .jpg files. Modules do modify the request flow that is provided by the application. You can create your own events and hook into existing application events like BeginRequest, EndRequest, AuthenticateRequest or Error events. Modules can have an influence before as well as after a handler fires depending on what you want to customize.
The existing modules and handlers do fine for any simple website and there really is no need for creating your own handlers and modules. It´s recommended to do some research first and see if there isn't allready a standard module or handler that you can simply hook into the application from the web.config. If you do create your own handlers or module, be aware that it can become very complex and has a high impact on your application most of the time. You should use automatic testing to make sure all works as expected.