Entropy in physics and in information science is just the logarithm (typically natural log in physics; base-2 log in computer science) of the number of equally likely possibilities, because it's generally easier to deal and think about with the logarithm of these exceptionally large number of possibilities than the possibilities directly.
If I randomly generated 128-bit as my random AES-128 key (that I store somewhere), it's easy to see there are 2128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 possible keys I could have used (2 equally-likely choices for each bit; and probabilities multiply). When talking about informational complexity, it's just simpler to talk about the key having 128-bits of entropy than saying about 340 x 1036 or 340 undecillion (short scale), especially if you want to compare it against say a 256-bit key with 2256=115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possibilities.
Now if I hand you a random user's password, technically it's not possible to uniquely assign an entropy to it.
You can only assign an entropy to a model of generating passwords. So if you are asked to estimate an entropy for a password, your task is to assume the model that might have generated that password.
If I gave you a password like
P[rmDrds,r you might assume I randomly chose 10 characters from a set of 95 printable ASCII characters and to brute-force you would have to go through 9510 ~ 265.7 possibilities and it would have an entropy of 65.7 bits. However, it's just a very weak password
OpenSesame where I shifted my hands on the keyboard over to the right one letter (which is probably one of say 2^6 ~ 64 common ways to alter typing an easy to remember low-entropy password). If you could find
OpenSesame on a list of say the 1,000 (1000 ~ 210) most common passwords then in fact the entropy of
P[rmDrds,r is closer to 16-bits (possibilities of 210 x 26), when the password generation is pick one of 64 common ways to obscure a password and then choose a password off a list of 1000 common passwords. Thus after about 64,000 attempts a sophisticated brute forcer who tried this avenue of attack could arrive at
P[rmDrds,r, so it's more accurate to estimate it's entropy as about 16 bits than 65.7 bits, which is 265.7-16 ~ 249.7 ~ 914 trillion times times easier to brute-force than the 65.7 bit password.
Now, obviously some less-sophisticated brute force attacker might have ignored the possibility of shifting characters over on the keyboard one space to the left while going through common password lists. But to be safe you ignore dumb attackers and assume very sophisticated attacker has considered all of your methods of password generation (Kerckhoffs's principle says avoid security by obscurity; assume the enemy has considered your secret technique among many other methods). So when someone says you need a high-entropy password, your goal isn't a password that appears to be highly random (and some simple password tester labels it as high-entropy). You want a random password that was built off of lots of random choices being input into your password generation procedure. You should not pick meaningful words to you and make up a password for it with obscure tricks like shifting letters around or leetspeak substitutions. For a strong password, you should rely on 80+ bits of non-human randomness being input into your procedure. You should note that one bit of entropy in a password generation procedure is equivalent to a two-option decision (e.g., something that could be determined by a coin flip).
And again, with very small likelihood you can randomly generate a password with a lot of random choices and it ends up a very weak password; e.g., it's technically possible that you randomly choose 12 characters and get
dddddddddddd. In practice, that's a possibility though it's unlikely to happen (e.g., if you use a procedure that generates an 90-bit password, the chance that it generated a password that also could have been generated with a simpler procedure with only 34-bits is 234/290 = 1 in 256 which is roughly the odds of buying exactly two Mega Millions tickets in a row and winning the jackpot both times).