Ravindra BagaleCourses & study guides मराठी Track your progress

Chapter 2: The OSI Model and TCP/IP Model

Interview Questions

By Last updated:

These questions on OSI and TCP/IP come up in almost every networking interview. Reply in this order: layer name, PDU and one example.

Q1. Name the seven OSI layers and the PDU at layers 2, 3 and 4.
Physical, Data Link, Network, Transport, Session, Presentation, Application. PDUs: frame (L2), packet (L3), segment/datagram (L4).
Q2. Explain the TCP three-way handshake.
Client sends SYN, server replies SYN-ACK, client sends ACK. After this the connection is established and data can flow with sequence numbers and acknowledgements.
Q3. What is the difference between TCP and UDP? Give an example of each.
TCP is connection-oriented and reliable (HTTP, SSH, MySQL). UDP is connectionless and faster with no delivery guarantee (DNS, VoIP, video streaming).
Q4. At which layer do an AWS Application Load Balancer and a Network Load Balancer operate?
ALB works at Layer 7 (routes by host/path/headers). NLB works at Layer 4 (TCP/UDP, ports).
Q5. What happens when you type a URL in the browser?
URL parsing → DNS resolution → TCP handshake → TLS handshake → HTTP request → server/app/database processing → HTTP response → browser renders HTML/CSS/JS.
Q6. What is encapsulation?
Each layer adds its own header (and Layer 2 also a trailer) around the data from the layer above before passing it down; the receiver removes them in reverse order (decapsulation).

Extended teaching notes

Why this lesson matters

Cloud security is mostly IAM, network exposure, logging and secure defaults. The shared responsibility model means the provider patches the metal; you patch what you configure.

  • No public databases or public admin panels.
  • Roles / OIDC instead of long-lived access keys.
  • CloudTrail / Activity Logs / Audit Logs on and retained.
  • S3/Blob/GCS: Block Public Access; encrypt; least privilege.

Mini case study

Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.

Defender's worksheet (do this today)

  1. Write the lesson title, date and the exact lab target you are allowed to use.
  2. List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
  3. Run one safe check from the lesson on a lab system only. Paste the command and output.
  4. Write a two-sentence fix you would give a teammate.
  5. Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.

Indian workplace (sample data)

Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).

Global practice

Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.

Everyday analogy

Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.

Key terms

  • Control: a safeguard (patch, config, process, detection).
  • Finding: a weakness backed by evidence.
  • Remediation: the fix plus how you verified it.
  • Scope: systems you have written permission to touch.
  • Least privilege: only the access the task needs.
  • Defence in depth: several layers so one failure does not end the story.

Common mistakes

  • Skipping written permission "just for a quick scan".
  • Practising on hostel, office or public targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
  • Publishing screenshots that contain secrets, cookies or internal hostnames.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Fix > spectacle.

Extra depth

Re-read the original short section at the top of the page, then this expansion. Together they should exceed a solid lesson length. If anything still feels thin, add your own lab screenshot and a paragraph in your notebook — that personal evidence is what interviews ask for.

  • Permission before tools.
  • Patch and config before exploits.
  • Logs and backups before blame.
  • Teach one junior the warning from this page.