Does HTTPS fully prevent man-in-the-middle attacks?

The confident "yes, HTTPS stops MITM" is the trap. HTTPS is designed to stop MITM, but its guarantees depend on assumptions that real-world attackers routinely break.

When HTTPS actually does prevent MITM

If the client validates the certificate chain up to a CA it genuinely trusts, and the certificate matches the hostname, then an attacker in the path cannot impersonate the server or read the traffic. That is the intended, strong case — and it usually holds.

The three ways it fails

1. A rogue but trusted CA. Corporate TLS-inspection proxies and some malware install their own root certificate into the trust store. Now the attacker can mint a valid-looking cert for any site and the browser shows no warning. Trust is the whole foundation; subvert the trust store and HTTPS is transparent to the attacker.
2. Ignored warnings. If validation fails and the user clicks "proceed anyway," they have manually accepted the attacker's certificate. Defenses like HSTS exist precisely to remove that click-through option.
3. SSL stripping. The victim's first request is often plain HTTP. An on-path attacker intercepts it and keeps the user on HTTP, talking HTTPS only to the real server. TLS is never established with the victim, so there is nothing to break. HSTS and HTTPS-only redirects mitigate this.

Layered defenses

HSTS (force HTTPS, no click-through), certificate pinning, and CA monitoring (CT logs) harden the baseline.

What interviewers look for

A qualified "no, not by itself," naming at least SSL stripping and the rogue-CA problem, and ideally HSTS/pinning as the hardening answer. Absolutism is the failure mode.