A password is something to be memorized by the user, and possibly also chosen by the user. In general, passwords have low entropy . >, that is, although the potential number of password candidates (ie all strings) is very large to infinity, "real" passwords - those that people tend to choose, or even think about - are much smaller . For this reason, it is estimated that users' passwords will have a "security" of X bits, and work under this assumption - even if individual users can choose stronger or weaker passwords.
A key is a sequence of bits used in a cryptographic procedure. Since each algorithm requires a key of predetermined size, a key of that exact size is required for use in that algorithm. For this reason, you can not use passwords directly as keys, you need to transform them according to any process, so that the resulting key is the correct size.
So answering your first question, password and key are different things.
The process that turns passwords into keys can vary widely, but one thing is certain: if the entry is the same password, the output will be the same key. Thus, if there are N distinct passwords that can be used, there will only be at most N distinct keys (may be less, since two different passwords may derive the same key). And if these N's, only M are "reasonable" passwords (i.e. that have any chance of being chosen by a user), then one can expect that there were M distinct keys, at least in 99% of cases.
In response to your second question, in fact, if the password is weak, the file becomes vulnerable. It should be noted, however, that using overly small (8-bit type) keys leaves the file vulnerable even when the password is strong, while using a larger key at least gives you the chance to use a password and have reasonable protection. The choice of key size should therefore be given by the characteristics of the chosen algorithm (eg a 256-bit ECC key has about the same security as a 3072-bit key for RSA).
As for your last question, programs like TrueCrypt and KeePass do not store the generated key anywhere - even if your computer was compromised, the attacker would only have to find the file with the key to decrypt your files ... Instead, the encryption key is derived from the password, and this is done again and again each time you want to gain access to your content. While you are using , however, the key is left in memory, being discarded only when you finish using it (eg you set up a TrueCrypt volume, it derived the key from your password, and saved the key in memory, you use this volume for a certain time, and when you decide to unmount it, the key is erased from memory). This may or may not be a risk, depending on how it was implemented (eg, whether the system has paged, or has given BSOD and a core dump was put on file, the key may be present on your hard drive without you even realizing it.)
Finally a note about the key derivation process: it is known that the passwords chosen by the user are usually weak, and little can be done about it (a # says that computers are getting faster and faster over time - allowing them to test more and more passwords in a short time - but our brains strong> are no better at remembering strong passwords, so it is inevitable that the relative strength of passwords will become worse and worse as time passes.) To counter this, we try to use key derivation processes that are purposely slow , that is, it takes several seconds (or even minutes) to generate the key from the same password in hardware . This ensures that even if the number of password candidates to be tested remains small, the time required to test all of them is quite large. This defense may not be enough to "save" a bad password, but is considered sufficient for "normal" passwords to still be viable in practice.