what is the difference between .cer & pfx file

A .pfx includes both the public and private key for the associated certificate (NEVER share this outside your organization); it can be used for TLS/SSL on web site, for digitally signing messages or authorization tokens, or for authenticating to a partner system. A .cer file only has the public key (this is what you typically exchange with integration partners); it can be used to verify tokens or client authentication requests, and it is what is received by an HTTP client from a server in the SSL handshake.

As has been mentioned, the question is a bit of apples and oranges, as the cer file is just the public key but the pfx file contains both public and private keys.

So a more fair question would be when would you want to use a pfx file as opposed to a pem file. Given that pfx files have been criticized for being overly complex, a fair answer to your second question might be: you would only ever want to use a pfx file if you're running IIS and its configuration absolutely won't let you use anything else.

Source: https://en.wikipedia.org/wiki/PKCS_12 (Referenced footnote is an article from Peter Gutmann.)

2 x scenarios that work slightly differently:

SCENARIO 1:
Web Browser (Client) accessing Web Page (Server) over HTTPS using SSL.

The Server has the .PFX File containing both keys. The Client connects to a Website on the Server, and the Server sends a copy of its Public-Key (.CER file) to the Client as part of the SSL handshake. The Client then generates a "SESSION-Key" and encrypts it using the public-key received from the server. The Session-key is then sent back to the server and decrypted to confirm its authenticity. If successfully, both the Client and Server now share the "Session-Key" to communicate using symmetric encryption (i.e. both client and server, now both encrypt AND decrypt all messages between each other using the same session-key. All of this is being done behind the scenes in the background of the web browser, between the time of you entering the URL in the address bar, and seeing the web page appear.

SCENARIO 2:
Application (Client) connects to a FTP Site (Server)
or
Remote Desktop (Client to Server) using SSH
(both examples would apply)

In this scenario, both the Client and Server will have their own private and public key pairs
(in contrast to the other examples mentioned in this thread, that only explain when a server has both keys, and the client has the public key only)

Now, for explanation purposes - Lets label the Key pairs something like:
A1 and A2 = as the Servers Private and Public Keys Respectively
B1 and B2 = as the Clients Private and Public Keys Respectively

Using this model, previous posts in this thread were talking about when the Server has A1 and A2 (.PFX file), and shares only a copy of A2 (.CER) with clients

Whereas FTP, or SSH connections (there are other examples out there) consist of A1, A2, B1 and B2 Keys in the entire Client-Server Communication. For instance,
- Client connects to FTP Server.
- Server Sends copy of its public Key (A2) to the Client.
- Client sends its own public key (B2) back to the Server, completing the handshake.
- This will now be using asymmetric Encryption

Server now has A1, (its own Private), A2 (its own public), and copy of B2 (Client's Public)
Client now has B1, (its own Private), B2 (its own public), and Copy of A1 (Server's Public)

Client-To-Server Comms:
Client uses A2 (servers public key) to encrypt messages bound for the Server, Server decrpyts them using A1 (Server private key)

Server-To-client Comms:
Server uses B2 (clients public key) to encrypt message bound for the Client, Client Decrypts them using B1 (Client private key)

Regarding the .CER and .PFX file Types, the Server ill have its own .PFX that shouldn't be distributed outside your organisation, instead, you should distribute the .CER file out to Clients.

more info can be found here:
https://www.digicert.com/ssl-cryptography.htm

and here:
https://serverfault.com/questions/107433/why-does-a-ssh-public-key-sit-on-the-server-and-not-with-the-client