Episode 1 — Fundamentals / 1.4 — Understanding HTTP and HTTPS
Interview Questions: Understanding HTTP & HTTPS
Practice questions with model answers for HTTP versions, TLS/HTTPS, proxies, and VPN topics commonly asked in software engineering and DevOps interviews.
How to use this material (instructions)
- Read lessons in order —
README.md, then1.4.a→1.4.g. - Answer out loud before reading the model answer.
- Draw TLS + reverse proxy diagrams when possible.
- Pair with exercises —
1.4-Exercise-Questions.md. - Cheat sheet pass —
1.4-Quick-Revision.md.
Beginner (Q1–Q6)
Q1. What is the difference between HTTP and HTTPS?
Model answer:
HTTP transfers hypertext messages between client and server, historically often in cleartext (port 80). HTTPS is HTTP carried over TLS (commonly port 443), providing encryption, integrity, and server authentication via certificates. HTTPS prevents casual eavesdropping and tampering on the network path; it also enables browser features that require a secure context.
Q2. Explain HTTP/2 vs HTTP/3 at a high level.
Model answer:
HTTP/2 multiplexes many streams over one TCP connection with binary framing and header compression (HPACK). Loss still affects TCP, so streams can stall together due to TCP head-of-line blocking.
HTTP/3 uses QUIC over UDP, integrating TLS 1.3 in modern stacks, with stream-level reliability—reducing cross-stream blocking and improving handshake performance in many deployments.
Q3. Walk through common HTTP status codes: 200, 301, 404, 500.
Model answer:
- 200 OK: success with a body.
- 301 Moved Permanently: resource moved forever; caches/SEO should update to the new URL.
- 404 Not Found: no resource for that URL (or hidden as 404).
- 500 Internal Server Error: server failed despite a valid-looking request.
Q4. What is TLS and why do people still say “SSL certificate”?
Model answer:
TLS (Transport Layer Security) is the cryptographic protocol that secures HTTPS. SSL is the older predecessor and is deprecated/insecure in modern deployments. People say “SSL certificate” colloquially, but technically it’s an X.509 certificate used for TLS authentication.
Q5. What is a reverse proxy and why is Nginx often used as one?
Model answer:
A reverse proxy sits in front of origin servers, accepting client connections and forwarding them internally. It can provide TLS termination, load balancing, caching, compression, and routing rules. Nginx is popular because it’s fast, stable, and excellent as an edge reverse proxy in front of app servers.
Q6. What does a VPN do?
Model answer:
A VPN creates an encrypted tunnel from the client to a VPN server; traffic exits to the public internet from the VPN’s network location/IP. It can protect traffic on untrusted Wi‑Fi, bypass some local blocking, and shift trust from ISP to VPN provider. It is not complete anonymity by default.
Intermediate (Q7–Q10)
Q7. How does HTTPS provide a secure connection (TLS handshake overview)?
Model answer:
Client and server perform a TLS handshake: negotiate algorithms, exchange key material, authenticate the server with a certificate chain to a trusted CA, derive session keys, then encrypt application data with AEAD ciphers. After handshake, HTTP messages are protected for confidentiality and integrity, and the client has strong evidence of server identity (hostname must match cert).
Q8. 401 vs 403?
Model answer:
401 Unauthorized: authentication failed or missing—who are you? 403 Forbidden: authenticated or not, but policy forbids the action—you can’t do this. APIs sometimes misuse codes; strong candidates mention RFC intent and real-world inconsistency.
Q9. Forward proxy vs reverse proxy — who sees what IP?
Model answer:
A forward proxy is configured by the client/org; the origin may see the proxy egress IP instead of each user’s IP. A reverse proxy is configured by the site owner; clients connect to the proxy hostname/IP, and origins typically see internal connections from the proxy to app servers.
Q10. What are the risks of HTTPS interception in a corporate network?
Model answer:
If the enterprise installs a custom root CA on devices and proxies decrypt TLS, users’ HTTPS is visible to the proxy appliance. Risks include privacy, compliance, misconfiguration (broken cert validation), and single point of compromise if the inspection infrastructure leaks keys/logs.
Quick-fire
| Question | Answer |
|---|---|
| Does HTTPS hide the destination IP from your ISP? | No (IP still visible; payload encrypted) |
| Does HTTPS stop XSS? | No (app-layer bug) |
| Is HTTP/3 TCP-based? | No (QUIC/UDP) |
Interview tips
- Separate transport security (TLS) from application security (authZ, XSS, SQLi).
- Mention certificate hostname validation when discussing MITM.
- For proxies, start with traffic direction (inbound vs outbound).