Is it possible to use tokens in files? How to link to files?

Katie, you should post to Products, which (albeit confusingly) is the user-to-user tech support section, as opposed to Marketing Central, which as I understand it is for marketing discussions that are not bound to the Marketo product line.  So if you could move the post there it would be great.

To your question: Marketo itself will not be able to populate tokens inside documents of any kind (other than HTML documents, which can technically be saved to .HTM/.HTML files but doubtless will not suffice for anyone who wants something familiar like a DOCX or PDF).

However, there are a couple of ways you could accomplish what you want with Marketo's assistance.  One would be to call an outside service (using a webhook in a flow), passing it your lead tokens and getting the URL of a personalized document in return.  The URL is then saved to a lead field and you can include that field as a token -- like {{my.LastCertificateURL}} -- in an email.

Another way, and really the way I would prefer since you have to find or build the back-end document personalization service anyway, is to link to a URL at which a document will by dynamically generated and sent back to the user's browser. In this case you'd include a URL like this in the email: mydocumentservice.com/makedoc?fn={{Lead.First Name}}&ln={{Lead.Last Name}}&dateCompleted={{Lead.DateCompleted}}.  Or you could have that link in the LP itself if you want them to have the extra confirmation step.  Either way, when the lead clicks the URL, the service dynamically renders a DOCX/PDF/whatever for them to download.  You could make something pretty slick this way.

Interestingly -- or maybe not, since I'm always getting excited about and eventually trashing experiments like this -- last year I played with building a PDF personalization service that would allow for quotes or suchlike (which would include certificates like in your case) to be personalized based on lead info passed in the URL + a static PDF. Truth is, dynamic PDF rendering is pretty darn resource intensive (I already knew this from using a great product named abcPDF at a couple of clients) and the idea of thousands of render jobs going on simultaneously (as would happen with a big, successful campaign) was pretty intimidating.  One cause is that PDFs are -- well, here I'm probably getting more technical than you'd like -- not efficient at "random seeks," jumping to tokens in the PDF to replace with dynamic data. Or, maybe more accurately, it's difficult to find efficient technology if you don't commit to a whole PDF lifecycle thing (with "real" PDF templates/forms).

Anyway, the above disquisition is all meant to suggest that continuing with the DOCX format is going to make this project a lot easier.  DOCX files are, IIRC, zipped sets of XML files, so it's easy to index them and seek tokens to replace.