Cloud & Distributed Systems

Complete Interview Prep Guide

Topics · Study Notes · MCQs · YouTube Resources · Ratings · Bonus Topics

HOW TO USE THIS GUIDE CORE (Do fully — gives you 80% of marks): Topics 1-5 covering Cloud Computing, Virtualization
KVM/QEMU, Distributed Systems, Linux Admin, and IP Networking. Study notes + all MCQs. ADDITIONAL (Partial study — extra/bonus
marks): Topics 6-12 covering Scripting, Ansible, Docker/Kubernetes, CI/CD, Storage, Certifications, and Open Source. Read the notes
lightly. No need to go deep.
TOPIC RATINGS & STUDY PRIORITY

Core Topics — Study Fully

Topic Priority Rating Study Time

Cloud Computing Fundamentals Must-have ★★★★★ 5/5 2-3 weeks

Virtualization — KVM/QEMU Must-have ★★★★★ 5/5 1-2 weeks

Distributed Systems Must-have ★★★★★ 5/5 3-5 weeks

Linux / Unix Admin Must-have ★★★★★ 5/5 1-2 weeks

IP Networking Must-have ★★★★★ 5/5 2-3 weeks

Additional Topics — Light Study Only (Bonus Marks)

Topic Priority Rating Study Time

Scripting — Bash & Python Important ★★★★■ 4/5 1 week

Ansible / Config Management Important ★★★■■ 3/5 1 week

Docker & Kubernetes Important ★★★■■ 3/5 1-2 weeks

CI/CD Pipelines Important ★★★■■ 3/5 1 week

Storage Technologies Important ★★★■■ 3/5 1 week

Cloud Certifications Nice-to-have ★★■■■ 2/5 Optional

Open Source Contribution Nice-to-have ★★■■■ 2/5 Optional

BEST YOUTUBE RESOURCES

Hindi Channels (Primary)

Topic Channel / Video Language

Distributed Systems & System Shrayansh Jain — [Link]/@JainShrayansh CAP Theorem, Kafka,
Hindi
Design Consistent Hashing, Raft — all in Hindi. Best for this JD.

Gate Smashers — [Link]/c/GateSmashers Search: 'Computer

Computer Networks &
Networks Gate Smashers Hindi' — DNS, DHCP, Subnetting, Routing, Hindi
Subnetting
VLANs all covered.

Gate Smashers — Operating System playlist Process management, file

Linux & OS Concepts Hindi
systems, permissions. Search 'OS Gate Smashers Hindi'.

Shridhar Mankar — [Link]/watch?v=cjV4QWYElE0 'Introduction to

Distributed Systems Basics Hindi
Distributed Systems in Hindi' — good starting point.

Thapa Technical — [Link]/@ThapaThechnical Cloud concepts,

Cloud & DevOps Hindi
Docker, Kubernetes explained in Hindi.

English Channels (When Hindi not available)

Topic Channel / Video Language

NetworkChuck — [Link]/@NetworkChuck Cloud, Networking,

Cloud Fundamentals English
Linux — very engaging. Search 'NetworkChuck cloud computing'.

Martin Kleppmann Lectures — [Link] Search 'Martin Kleppmann

Distributed Systems (Deep) English
distributed systems Cambridge' — lectures by the DDIA book author.

LearnLinuxTV — [Link]/@LearnLinuxTV Search 'LearnLinuxTV

KVM / Virtualization English
KVM' — hands-on KVM setup and live migration demos.

Confluent YouTube — [Link]/@Confluent Search 'Kafka

Kafka English
fundamentals Confluent' — official Kafka tutorials.

TechWorld with Nana — [Link]/@TechWorldwithNana Best

Kubernetes English
Kubernetes tutorial. Search 'Kubernetes tutorial for beginners Nana'.

BOOK RECOMMENDATION: 'Designing Data-Intensive Applications' by Martin Kleppmann — covers 90% of the Distributed Systems
topic from this JD. Read chapters on replication, partitioning, transactions, and consistency. This one book is worth more than 10
YouTube playlists for distributed systems.
01 MAIN TOPIC 1: CLOUD COMPUTING FUNDAMENTALS

1.1 IaaS, PaaS, SaaS — Service Models

IaaS (Infrastructure as a Service): raw compute, storage, networking. You manage everything from OS upward.
Examples: AWS EC2, Google Compute Engine. Use when full OS control or custom kernel needed.

PaaS (Platform as a Service): platform manages OS, runtime, scaling. You only deploy code. Examples: Google App
Engine, Heroku. Use when team has no DevOps.

SaaS (Software as a Service): vendor manages everything. You manage only users and data. Examples: Gmail,
Salesforce, Slack.

Shared Responsibility: IaaS — you own OS, apps, data, network security. PaaS — you own apps and data. SaaS — you
own only your data and user access.

1.2 Public, Private, and Hybrid Cloud

Public cloud: shared infrastructure, pay-as-you-go, zero CapEx. AWS/GCP/Azure.

Private cloud: dedicated to one org. Full control, higher cost. Examples: OpenStack, VMware vSphere.
Hybrid cloud: on-premises + public cloud connected. Sensitive data on-prem, burst workloads on cloud. Most common
enterprise model.

Multi-cloud: multiple public cloud providers. Avoids vendor lock-in but increases complexity.

1.3 Elasticity, Scalability, HA, Fault Tolerance, Durability

Elasticity: auto-scale up on demand, release when done. Core cloud billing advantage.

Scalability: handle increased load. Vertical = bigger machine. Horizontal = more machines.

High Availability (HA): minimize downtime via redundancy and failover. Brief interruption possible. 99.99% = 52 min
downtime/year.

Fault Tolerance: zero interruption even on failure — requires fully redundant active systems.

Durability: data not lost. S3 = 11 nines durability (99.999999999%).

1.4 Regions, AZs, Edge Locations

Region: geographic area with multiple data centers. Data stays in region unless you configure otherwise.

Availability Zone: physically separate data center within a region — independent power, cooling, networking.

Edge Locations: CDN cache nodes worldwide. Serve static content close to users. Lower latency.

Rule: deploy across 2+ AZs for HA. Deploy across 2+ regions for DR.

1.5 Cloud Billing — On-demand, Reserved, Spot

On-demand: pay per hour/second. Most expensive per unit. No commitment. Good for unpredictable workloads.

Reserved: commit 1 or 3 years for up to 75% discount. Best for steady-state 24/7 workloads.

Spot/Preemptible: up to 90% discount on unused capacity. Can be terminated with 2 min notice. Good for batch jobs,
fault-tolerant workloads only.

MCQs — Cloud Computing

Q — Service Model Selection
Scenario: Startup needs Ubuntu 18.04 with custom kernel modules. CTO wants full OS control.

Which cloud service model is most appropriate?

A. SaaS — software delivered and managed by vendor
B. PaaS — platform manages OS, runtime, scaling
 C. IaaS — gives raw VMs where you manage OS and above ✓
D. FaaS — serverless functions triggered by events
Explanation: IaaS provides virtual machines with full OS access. You install OS, configure kernel modules, manage everything above
the hypervisor. PaaS would abstract away the OS making custom kernel modules impossible.

Q — Hybrid Cloud
Scenario: Bank must store PII on-premises (data sovereignty law) but wants cloud compute for non-sensitive analytics.

Which cloud deployment model fits?

A. Public cloud only
B. Private cloud only
C. Hybrid cloud — sensitive data on-premises, non-sensitive on public cloud ✓
D. Multi-cloud with no on-premises component
Explanation: Hybrid cloud connects on-premises infrastructure with public cloud. Sensitive data stays on-prem for compliance;
analytics workloads use public cloud scalability and cost benefits.

Q — Elasticity
Scenario: E-commerce platform: Black Friday drives 100x traffic for 6 hours, then drops to normal.

Which cloud property directly solves this without wasting money the rest of the year?
A. Durability — ensures data not lost during spike
B. Fault tolerance — keeps system running if servers fail
C. High availability — ensures minimal downtime during event
D. Elasticity — automatically scales resources up and releases them after ✓
Explanation: Elasticity is the ability to scale resources on-demand and release them when no longer needed — billing only for actual
usage. This is the core economic advantage of cloud over fixed-capacity infrastructure.

Q — Availability Zones
Scenario: Critical payment API requires 99.99% uptime. Architect says deploy across multiple AZs.

What does deploying across multiple AZs protect against?

A. Network latency between app and database
B. High cost of a single large instance
C. A single data center failure — each AZ is physically separate with independent power and networking ✓
D. Cross-region data replication delays
Explanation: Each AZ is one or more physically separate data centers with their own power, cooling, and networking. A failure in one
AZ does not affect others. Multi-AZ + load balancer = automatic failover with minimal downtime.

Q — HA vs Fault Tolerance
Scenario: Architect debate: payment system needs 99.99% uptime. One says HA, other says fault tolerance.

What is the correct difference?

A. They are the same — both mean system never goes down
B. HA is for databases only; fault tolerance is for web servers
C. HA minimizes downtime with automatic failover (brief interruption possible); fault tolerance = zero
interruption with fully active redundant systems ✓
D. Fault tolerance requires cloud; HA works only on-premises
Explanation: HA: load balancer detects failed server, reroutes — brief seconds possible. Fault tolerance: triple redundancy — all three
run simultaneously, failure of one causes zero interruption. Fault tolerance costs significantly more.
02 MAIN TOPIC 2: VIRTUALIZATION — KVM/QEMU

2.1 What is Virtualization

Creating software-based versions of physical resources. Multiple OS run simultaneously on one physical machine,
isolated from each other. Benefits: server consolidation, isolation, portability, fast provisioning.

Key components: Host (physical machine), Guest (VM), Hypervisor/VMM (creates and manages VMs).

2.2 Type-1 vs Type-2 Hypervisors

Type-1 (Bare-metal): runs directly on hardware. No host OS. Examples: KVM, VMware ESXi, Hyper-V, Xen. Used in
production. Better performance.

Type-2 (Hosted): runs on top of a host OS. Examples: VirtualBox, VMware Workstation. Used for dev/test.

KVM is special: a Linux kernel module that turns the Linux kernel itself into a Type-1 hypervisor. Classified as Type-1
even though Linux runs underneath.

2.3 KVM Architecture

KVM (Kernel-based Virtual Machine): kernel module ([Link]). Requires Intel VT-x or AMD-V CPU extensions — cannot
function without these.
CPU virtualization: VT-x/AMD-V lets guest OS run privileged instructions directly on CPU hardware (VMX non-root
mode). No slow software emulation.

Memory virtualization: Extended Page Tables (EPT/NPT) let guests manage their own memory without trapping to
hypervisor on every access.

QEMU: user-space app that emulates hardware devices (virtual disk, NIC, USB, display). KVM handles CPU/memory;
QEMU handles device emulation. Together = complete virtualization platform.

2.4 Memory Overcommit — Ballooning, KSM

Overcommit: allocate more virtual RAM to VMs than physical RAM exists. Works because VMs rarely all use peak RAM
simultaneously.

Memory ballooning: hypervisor inflates balloon driver inside guest — guest gives RAM back to hypervisor for other VMs.

KSM (Kernel Same-page Merging): Linux merges identical RAM pages across VMs (e.g. same kernel pages). One
physical page serves multiple VMs.

Risk: if all VMs demand peak RAM simultaneously — host OOM killer terminates VM processes.

2.5 Live Migration

Moving a running VM to another host with no perceptible downtime. Used for hardware maintenance, load balancing.

Process: (1) VM runs on source. (2) Memory pages copied iteratively to destination. (3) Dirty pages tracked and re-sent.
(4) Brief pause (ms to seconds) — final pages + CPU state transferred. (5) VM resumes on destination.

Requirements: shared storage, compatible CPU architecture, network between hosts, management layer (libvirt).

2.6 Snapshots vs Backups

Snapshot: point-in-time state capture. Original disk becomes read-only; writes go to delta file. Fast to take. NOT a
standalone backup.

Problems: performance degrades with long chains, dependent on base disk, delta files can fill storage.

Backup: full independent copy stored separately. True DR backup. Takes longer but survives base disk loss.

2.7 VirtIO — Paravirtualized Drivers

Fully emulated: QEMU emulates real hardware. Guest uses standard physical drivers. Slowest — every I/O involves
emulation overhead.
VirtIO: guest knows it's in a VM, uses optimized virtual drivers. Near-native performance. Always use in production.

Types: virtio-blk (disk), virtio-net (network), virtio-scsi, virtio-balloon. Linux has built-in VirtIO. Windows needs driver
package installed.

MCQs — Virtualization KVM/QEMU

Q — KVM Type & VT-x Requirement
Scenario: Junior engineer setting up KVM host. Server doesn't have Intel VT-x.

Is KVM Type-1 or Type-2? Does it work without VT-x?

A. Type-2 because Linux is host OS. Works without VT-x via software emulation.
B. Type-1 runs on bare metal. Works without VT-x using QEMU-only mode.
C. Type-1 — KVM turns Linux kernel into hypervisor. Requires Intel VT-x or AMD-V — cannot function without
it. ✓
D. Type-2 because QEMU is the actual hypervisor. VT-x is optional.
Explanation: KVM is a Linux kernel module making the kernel act as hypervisor — Type-1. Requires VT-x/AMD-V to run guest
privileged instructions natively. Without VT-x, only pure QEMU software emulation is possible (much slower).

Q — Memory Overcommit Risk

Scenario: KVM host: 64GB RAM. 8 VMs each with 20GB allocated (160GB total). Running fine for weeks. Suddenly 6 VMs start batch
jobs and fill their RAM.

What is most likely to happen?

A. Hypervisor automatically adds more physical RAM
B. All VMs pause gracefully until RAM is available
C. VMs that started last are throttled first
D. Host Linux OOM killer may terminate VM processes to reclaim RAM, potentially crashing some VMs ✓
Explanation: Memory overcommit relies on VMs not all needing peak RAM simultaneously. When they do, host runs out. KSM and
ballooning cannot compensate fast enough. Linux OOM killer terminates highest-memory processes — VM processes.

Q — Live Migration
Scenario: Production database VM must move from Host A to Host B for hardware maintenance. Database serves live traffic —
cannot stop.

What technology allows this and what is the key requirement?

A. VM cloning — create copy on Host B then switch traffic manually
B. VM backup and restore — backup to disk then restore on Host B
C. Live migration — iteratively copies memory to Host B while VM runs, requires shared storage and
compatible CPU ✓
D. Snapshot and export — take snapshot, export to Host B, resume there
Explanation: Live migration (pre-copy) iteratively copies RAM pages to destination while VM runs. Brief pause of ms to seconds for
final dirty pages and CPU state. Requires: shared storage, network connectivity, compatible CPU families.

Q — VirtIO Performance
Scenario: Database VM on KVM shows slow disk performance using default IDE controller.

What should you change and why?

A. Switch to SATA emulation — uses a faster emulated controller
B. Add more RAM — disk slowness is often a memory issue
C. Switch disk to VirtIO (virtio-blk) — paravirtualized driver eliminates emulation overhead and gives
near-native throughput ✓
D. Increase disk size — larger disks always perform faster
Explanation: Emulated IDE translates every I/O through a full hardware emulation layer. VirtIO is paravirtualized — guest knows it's in
a VM and uses optimized driver communicating directly with hypervisor. Performance improvement can be 3-5x.

Q — Snapshot Chain Degradation

 Scenario: Admin took VM snapshots before every weekly patch for 6 months, never merging. VM is now extremely slow. Disk chain
has 26 layers.

What is happening and what is the fix?

A. VM has too many running processes — restart it
B. Storage is full — add more disk capacity
C. Snapshot chain 26 levels deep — reads must traverse all layers. Merge (commit) all snapshots into the base
disk. ✓
D. Network is slow — snapshots cause network congestion
Explanation: Each snapshot adds a delta disk layer. Reading a block checks newest delta first, then works backward through all 26
layers. This multiplies I/O operations dramatically. Merge snapshots periodically. Snapshots are NOT backups.
03 MAIN TOPIC 3: DISTRIBUTED SYSTEMS FUNDAMENTALS
MOST IMPORTANT TOPIC IN THIS JD — spend 3-5 weeks here. Read: 'Designing Data-Intensive Applications' by Martin Kleppmann.

3.1 CAP Theorem

A distributed system can only guarantee 2 of 3 simultaneously:

• Consistency (C): every read gets the most recent write or an error. No stale reads.
• Availability (A): every request gets a response — but may not be the most recent data.
• Partition Tolerance (P): system continues even when network messages drop between nodes.
Key insight: in real distributed systems, network partitions WILL happen. P is non-negotiable. Real choice is C vs A
during a partition.

CP systems: during partition, choose consistency — some requests rejected rather than serve stale data. Examples:
Zookeeper, etcd, HBase.

AP systems: during partition, choose availability — all nodes serve requests, some may return stale data. Examples:
Cassandra, DynamoDB, DNS.

3.2 Consistency Models (Strongest to Weakest)

Linearizability (Strong): once write completes, all reads from any node return that value. Highest latency. Used by: etcd,
Zookeeper, Google Spanner.

Causal Consistency: causally related operations seen in correct order. If I post then edit, you never see the edit before
the original post.

Read-Your-Writes: after you write, you always see that write in your subsequent reads. Other clients may still see stale
data.

Eventual Consistency: all replicas will converge eventually. No guarantee on timing. Highest availability. Used by:
Cassandra, DynamoDB, S3.

3.3 Replication
Master-Slave: all writes to primary, replicates to replicas. Replicas handle reads. Simple. Problems: replication lag, single
point of failure for writes.

Replication lag: delay between write on primary appearing on replica — causes stale reads.

Multi-master: multiple nodes accept writes. Solves write availability but causes write conflicts. Conflict resolution:
last-write-wins, vector clocks, CRDTs.

Synchronous replication: primary waits for replica to confirm before acking. No data loss risk. Cost: write latency bounded
by slowest replica.

Asynchronous replication: primary acks immediately, replicates in background. Low latency. Risk: data loss if primary
crashes before replication.

3.4 Consensus — Raft & Paxos

Why consensus: nodes must agree on single value — who is leader, what is next log entry. Works even when nodes fail.

Raft: designed for understandability. Three sub-problems: leader election, log replication, safety. Used by: etcd
(Kubernetes), Consul, CockroachDB.

Quorum (majority): for N nodes, quorum = floor(N/2)+1. 3 nodes = quorum 2. 5 nodes = quorum 3. Always use odd
number of nodes.

Paxos: original algorithm. Proven correct but notoriously difficult to implement. Many practical details left undefined in
original paper.

3.5 Distributed Transactions — 2PC & Saga

2PC Phase 1 (Prepare): coordinator asks all participants if they can commit. Each locks resources and says YES/NO.

2PC Phase 2 (Commit/Rollback): if all YES — coordinator sends COMMIT. If any NO — sends ROLLBACK.

2PC blocking problem: if coordinator crashes after participants say YES but before COMMIT — participants stuck
indefinitely with locks held.

Saga pattern: sequence of local transactions. Each service commits locally and emits event. On failure — compensating
transactions undo previous steps (e.g. refund payment). No distributed lock. Gives eventual consistency.

3.6 Fault Tolerance — Split-Brain, Byzantine Faults

Network partition: failure splits system into groups that cannot communicate.

Split-brain: partition causes two node groups to each elect their own leader — both accept writes — data diverges.
Prevention: quorum elections, STONITH fencing, distributed locks.

Crash fault: node stops, sends nothing. Easy to detect via timeout.

Byzantine fault: node continues but sends wrong/malicious data. Requires 3f+1 nodes to tolerate f faults. Very expensive.
Used in blockchain.

3.7 Sharding & Consistent Hashing

Sharding: split data across multiple nodes. Each node holds a subset.
Modulo sharding: shard = hash(key) % N. Adding 1 shard changes denominator — almost all keys remap. Massive data
movement.

Consistent hashing: keys and nodes on a virtual ring. New node only takes keys in one arc — ~1/N data moves. Far
better for dynamic clusters.

Virtual nodes (vnodes): each physical node holds many ring positions — better distribution. Used by Cassandra,
DynamoDB.

Hot spot: one shard gets disproportionate traffic. Fix: composite shard key, read replicas for hot shard, Redis cache.

3.8 Message Queues — Kafka & RabbitMQ

RabbitMQ (traditional queue): push-based. Each message to ONE consumer then deleted. Good for task queues.

Kafka (log-based): pull-based. Messages retained on disk for configurable period. Multiple consumer groups read
independently at their own offsets. Enables replay. Good for event streaming.

Kafka delivery: at-most-once (auto-commit before processing — can lose messages). At-least-once (manual commit after
processing — may duplicate). Exactly-once (Kafka transactions + idempotent processing — complex).

Dead letter queue (DLQ): messages that repeatedly fail move here for manual investigation.

MCQs — Distributed Systems

Q — CAP Theorem — Partition Choice
Scenario: Two data centers lose connectivity. Writes still arriving. DB must choose: serve stale reads OR reject requests.

Under CAP theorem, what must you sacrifice?

A. Sacrifice Partition Tolerance — disable network partitions
B. Sacrifice Consistency or Availability — cannot have both during a partition ✓
C. Maintain all three with strong consensus algorithm
D. CAP only applies to single-node databases
Explanation: P (Partition Tolerance) is non-negotiable in real networks. During a partition the real choice is C vs A. CP: reject requests
to avoid stale data. AP: serve possibly stale data to remain available.

Q — CP vs AP — Practical
Scenario: Choose system for leader election (requires exact consensus) vs user session store (availability more important).

Cassandra is AP. Zookeeper is CP. How should you use them?

 A. Cassandra for leader election; Zookeeper for session store
B. Zookeeper for leader election (CP = consistent); Cassandra for sessions (AP = always available) ✓
C. Both interchangeable for any use case
D. CP systems are always faster than AP systems
Explanation: Leader election requires strict consistency — only one leader at a time (Zookeeper, etcd). Session stores tolerate stale
data for seconds — Cassandra AP model stays available even during partitions.

Q — Raft Quorum
Scenario: etcd cluster has 5 nodes. Two nodes crash simultaneously due to AZ power failure.

Can the cluster still elect a leader and accept writes?

A. No — any node failure prevents consensus
B. No — 2 failures break a 5-node cluster
C. Yes — quorum for 5 nodes is 3 (floor(5/2)+1). With 2 failures, 3 nodes remain — quorum met. ✓
D. Yes — etcd requires only 1 node to operate
Explanation: Raft quorum = floor(N/2)+1. N=5: quorum=3. 5-2=3 nodes remaining = exactly quorum. Cluster can still elect leader and
commit entries. If 3rd node failed, only 2 remain — below quorum — cluster stalls.

Q — 2PC Blocking Problem

Scenario: Microservices order system uses 2PC. Coordinator crashes after all four services reply YES in Phase 1, before sending
COMMIT.

What happens to the four services?

A. All four automatically roll back after timeout
B. All four automatically commit after timeout
C. All four stuck in blocked state — locks held, cannot decide without coordinator's COMMIT/ROLLBACK ✓
D. Services elect a new coordinator from among themselves
Explanation: 2PC blocking problem: participants are 'uncertain' after sending YES. They hold locks and wait for coordinator. If
coordinator crashes, system is blocked until it recovers. This is why 2PC is problematic across microservices.

Q — Split-Brain Prevention
Scenario: 2-node MySQL primary-replica cluster loses network between nodes. Both believe other failed. Both promote to primary and
accept writes.

What problem is this and how is it correctly prevented?

A. Replication lag — solved by synchronous replication
B. Byzantine fault — prevented by BFT algorithms
C. Split-brain — prevented by quorum-based elections and STONITH fencing to forcibly isolate old primary ✓
D. Crash fault — prevented by adding more replicas
Explanation: Split-brain: both nodes believe they are sole primary — both accept writes — data diverges. A 2-node cluster cannot use
quorum. Solutions: add 3rd quorum/arbiter node, use STONITH (node loses election gets power cut), or use etcd distributed lock as
tie-breaker.

Q — Consistent Hashing vs Modulo

Scenario: 4 DB shards using hash(user_id) % 4. Need to add a 5th shard for growth.

What is the problem with modulo sharding and what is the better alternative?
A. Cannot add shards to a modulo-based system
B. Only 25% of data needs to move
C. Almost all data must be remapped because hash % 5 assigns nearly every key differently than hash % 4.
Consistent hashing only moves ~1/N data when adding one node. ✓
D. Both approaches have identical data movement
Explanation: Modulo hash: adding 1 shard changes denominator — key % 4 vs key % 5 differs for most keys. Nearly all data must
move. Consistent hashing: new node only takes ownership of keys in one ring arc — about 20% for a 5th node.

Q — Kafka Offset — Prevent Message Loss

Scenario: Payment event consumer reads Kafka message, starts processing $500 transfer, then pod crashes before completing.
Which combination guarantees correctness?
A. Use auto-commit — offsets committed automatically, no redelivery
B. Commit offset before processing — marks message done immediately
C. Manual offset commit after processing + idempotent processing (check if transfer ID already exists before
applying) ✓
D. Increase Kafka replication factor — prevents duplicate processing
Explanation: Manual commit after processing = at-least-once delivery (crash before commit → redelivery). Idempotent processing:
before applying $500 transfer, check if transfer_id already exists — if yes, skip. Gives effectively-once semantics.
04 MAIN TOPIC 4: LINUX / UNIX — SYSTEM ADMINISTRATION

4.1 File System Hierarchy

/ — root. Everything starts here.
/bin — essential binaries (ls, cp, mv, cat)
/etc — all configuration files
/var — variable data: logs (/var/log), spool, mail
/tmp — temporary files, cleared on reboot
/home — user home directories
/proc — virtual filesystem: kernel & process info as files
/dev — device files (block: /dev/sda; char: /dev/null)
/usr — user programs (/usr/bin, /usr/lib)

4.2 File Permissions

Structure: rwxrwxrwx — three sets (owner, group, others). r=4, w=2, x=1.

chmod 755 = rwxr-xr-x. chmod 644 = rw-r--r--. chmod 600 = rw------- (private key files).
SUID (4000): executable runs as the owner's UID. Example: /usr/bin/passwd runs as root so any user can change
password.

Sticky bit (1000): on /tmp — only file owner can delete their own files.

4.3 Process Management

ps aux — list all processes. top / htop — interactive real-time viewer.

kill PID — SIGTERM (polite, process can clean up). kill -9 PID — SIGKILL (force, immediate, uncatchable).

systemctl: start/stop/restart/enable/disable/status servicename. journalctl -u service -f — follow service logs live.

journalctl --since '1 hour ago' -p err — filter errors in time window.

4.4 Key Networking Tools

ip addr — show interfaces and IPs. ip route — show routing table.

ss -tlnp — TCP listening sockets with process names (replaces netstat -tlnp).

tcpdump -i eth0 port 443 — capture HTTPS traffic. curl -v url — HTTP request with verbose headers.

dig domain — DNS query. dig domain @[Link] — query specific DNS server.

4.5 Log Analysis

Key log locations: /var/log/syslog (system), /var/log/[Link] (SSH/sudo), /var/log/nginx/ (web server).

grep 'ERROR' /var/log/syslog. tail -f log — follow live. grep -A 5 'segfault' — show 5 lines after match.

4.6 SSH
ssh -i ~/.ssh/[Link] user@host. Generate keys: ssh-keygen -t ed25519.

Install on remote: ssh-copy-id user@host. Production: set PasswordAuthentication no in /etc/ssh/sshd_config.

MCQs — Linux / Unix

Q — SUID Bit
Scenario: ls -la shows: -rwsr-xr-x 1 root root /usr/bin/passwd. Regular user runs passwd to change their password. /etc/shadow is
owned root with permissions 640.

How can a regular user successfully run passwd and write to /etc/shadow?
A. Regular users have hidden write access to /etc/shadow
 B. passwd binary runs as calling user who gets temporary root rights
C. SUID bit (s in owner execute position) causes passwd to run with root's privileges regardless of who calls it
✓
D. /etc/shadow permissions temporarily change to 666 during passwd execution
Explanation: SUID on executable: process gets the owner's UID (root) rather than calling user's UID. passwd needs root privileges to
write /etc/shadow. SUID grants this safely for this specific binary only.

Q — Process Termination Sequence

Scenario: Service 'dataprocessor' running but consuming 100% CPU. Need to gracefully stop it, forcefully kill only if needed.

What is the correct sequence?

A. kill -9 dataprocessor immediately
B. killall dataprocessor then ps aux to verify
C. ps aux | grep dataprocessor to get PID, then kill PID (SIGTERM — graceful), wait 30s, then kill -9 PID if still
running ✓
D. systemctl stop dataprocessor then kill -9 PID
Explanation: SIGTERM (kill PID): polite termination — process can catch it, flush buffers, clean up. SIGKILL (kill -9): immediate,
uncatchable. Always try SIGTERM first.

Q — Service Crash Investigation

Scenario: nginx stopped responding at 2 AM. systemctl shows it crashed. Need exact error that caused crash.

Which command gives the most useful diagnostic information?

A. cat /var/log/nginx/[Link] only
B. dmesg | tail only
C. ping localhost to check if server alive
D. journalctl -u nginx --since '01:50' --until '02:10' -p err — scoped time window, nginx unit, error level ✓
Explanation: journalctl -u nginx filters to nginx unit. --since/--until scopes to crash window. -p err shows only error severity and above.
Gives exact crash reason within the relevant time window.

Q — Port Not Listening

Scenario: curl localhost:3000 returns 'Connection refused'. [Link] app should be listening on port 3000.

What is the best diagnostic sequence?

A. Restart the server and try again
B. Check /etc/hosts for port 3000 entries
C. ss -tlnp | grep 3000 to check if anything listening, then ps aux | grep node to check if process running ✓
D. ping localhost:3000 to test connectivity
Explanation: 'Connection refused' means nothing is listening on that port. ss -tlnp shows all TCP listening ports with process names.
ps aux | grep node confirms whether process started at all. ping doesn't test ports.

Q — Disk Full Investigation

Scenario: Production server has run out of disk space on /var. Need to find cause and clear without rebooting.

What is the correct diagnostic and resolution sequence?

A. Delete /var/log immediately to free space
B. Run fsck /var to repair filesystem
C. df -h to confirm /var is full, then du -sh /var/* | sort -rh | head to find largest dirs, then clean (rotate logs, apt
clean) ✓
D. Unmount /var, resize partition, remount
Explanation: df -h confirms which filesystem is full. du -sh /var/* | sort -rh ranks directories by size. Then: journalctl
--vacuum-size=500M, apt clean, remove old logs. Never blindly delete — investigate first.
05 MAIN TOPIC 5: IP NETWORKING

5.1 Subnetting & CIDR

Usable hosts = 2^(32-prefix) - 2. Memorize these:

/24 = 254 usable hosts | /25 = 126 | /26 = 62 | /27 = 30 | /28 = 14 | /29 = 6 | /30 = 2

Private ranges: [Link]/8, [Link]/12, [Link]/16 — not routable on internet.

5.2 VLANs
VLAN: logical network segmentation at Layer 2. Devices on same VLAN communicate without a router.

802.1Q tagging: 4-byte VLAN tag added to Ethernet frames. VLAN IDs 1-4094.

Access port: one VLAN, no tagging visible to end device. Connect PCs, servers.

Trunk port: multiple VLANs with 802.1Q tags. Connect switch-to-switch or switch-to-router.

Inter-VLAN routing: need a Layer 3 device (router subinterface or L3 switch SVI). VLANs cannot talk without it.

5.3 DNS
Resolution: Client → Resolver cache → Root NS → TLD NS → Authoritative NS → A record → cached for TTL.
Key records: A (hostname → IPv4), AAAA (IPv6), CNAME (alias), MX (mail), NS (delegation), TXT (SPF/DKIM), PTR
(reverse DNS).

TTL: how long resolvers cache records. Before DNS migration: lower TTL to 300 (5 min), wait 24h, then change record.

5.4 DHCP — DORA

DORA: Discover (broadcast) → Offer (server responds) → Request (client accepts) → Acknowledge (IP assigned).

DHCP relay agent (ip helper-address): required when DHCP server and clients are on different VLANs. Forwards
broadcasts as unicast.

Lease: temporary assignment. Client renews at 50% of lease time. Expired lease — client stops using IP.

5.5 Load Balancing

L4 (TCP/UDP): routes based on IP and port only. Cannot inspect HTTP content. Very fast. Use: AWS NLB, HAProxy
TCP mode.

L7 (HTTP): inspects URL path, headers, cookies. Enables: content-based routing, SSL termination, sticky sessions. Use:
AWS ALB, nginx.

Algorithms: Round-robin, Least-connections (best for variable request time), IP hash (sticky without cookies).

Health checks: periodic probe — remove failed backends, re-add when healthy.

5.6 Firewall Principles

Stateless: evaluates each packet independently by rules (IP, port, protocol). No session memory. Fast but limited.

Stateful: tracks TCP connection state. Packet without matching state table entry is dropped. Default for all modern
firewalls.

iptables chains: INPUT (incoming to host), OUTPUT (outgoing), FORWARD (passing through). Rules evaluated
top-to-bottom — first match wins.

Cloud: Security Groups (stateful, per-VM). NACLs (stateless, per-subnet — must explicitly allow return traffic).

5.7 Routing
Longest prefix match: /28 route preferred over /24 route for matching IP.

Static: manually configured. Simple. Does not adapt to failures. Good for small networks.
OSPF: link-state, intra-AS, Dijkstra shortest path. Fast convergence. Used inside enterprises/data centers.

BGP: path-vector, inter-AS, internet routing. Policy-based. Used by ISPs and cloud providers.

MCQs — IP Networking
Q — Subnetting
Scenario: Network [Link]/24. Need 4 equal subnets, at least 50 usable hosts per subnet.

Which subnet mask works for both requirements?

A. /25 — gives 2 subnets of 126 hosts (not enough subnets)
B. /27 — gives 8 subnets of 30 hosts (not enough hosts)
C. /28 — gives 16 subnets of 14 hosts (not enough hosts)
D. /26 — gives 4 subnets (256/64=4), each with 62 usable hosts — meets both requirements ✓
Explanation: /26: 6 host bits = 64 IPs per subnet = 62 usable. 256/64 = 4 subnets from a /24. Both requirements met: 4 subnets
needed, 4 provided; 50 hosts needed, 62 provided.

Q — VLAN Routing Issue

Scenario: User in VLAN 30 (HR) cannot reach internet. VLAN 10 (Engineering) user can. DHCP works for VLAN 30.

What is the most likely cause?

A. Switch port for HR user is in wrong duplex mode
B. HR user's PC has a firewall blocking outbound traffic
C. VLAN 30 is missing inter-VLAN routing configuration (SVI or router subinterface) — DHCP works but no
route for VLAN 30 traffic to exit ✓
D. DHCP and internet routing use different VLANs so they cannot conflict
Explanation: DHCP relay works at Layer 3 independently of routing rules. If inter-VLAN routing configured for VLAN 10 but not VLAN
30, VLAN 30 clients get IPs but have no gateway to route traffic. Check SVI for VLAN 30 or router subinterface.

Q — DNS TTL & Migration

Scenario: Updated DNS A record for [Link]. Old TTL was 86400 (24 hours). 3 hours after change, some customers still hit
old IP.

Why and what should you have done before the change?
A. DNS change hasn't replicated to all authoritative servers yet
B. Need to flush all global DNS servers — contact each ISP
C. Resolvers that cached the record will serve old IP for up to 24 hours (TTL). Should have lowered TTL to 300
(5 min) and waited for old cache to expire first. ✓
D. Browsers ignore DNS TTL — always cache for 24 hours regardless
Explanation: TTL tells resolvers how long to cache. 86400 = 24 hours. Any resolver that cached before your change keeps serving old
IP for up to 24 hours. Best practice: lower TTL to 300 well before planned change, wait 24+ hours, then change record.

Q — DHCP Relay
Scenario: New server in VLAN 40 fails to get DHCP lease. DHCP server is in VLAN 1. DHCP scope defined for VLAN 40 subnet. All
other VLANs work fine.

What is almost certainly missing?

A. DHCP server needs a second NIC for VLAN 40
B. Server's MAC address must be registered in DHCP
C. DHCP scope needs to be activated on server
D. DHCP relay agent (ip helper-address) not configured on VLAN 40 router interface — DHCP Discover
broadcasts don't cross VLAN boundaries without it ✓
Explanation: DHCP Discover is a Layer 2 broadcast — cannot cross a router to reach DHCP server in VLAN 1. DHCP relay agent on
router's VLAN 40 interface forwards broadcast as unicast to DHCP server. Without it, server never sees Discover from VLAN 40.

Q — L4 vs L7 Load Balancing
Scenario: App returns different responses based on URL: /api/ → Python backends, /static/ → CDN origin.
Which load balancer type enables this routing?
A. L4 (TCP) load balancer — can route based on URL path
B. DNS round-robin — distributes by hostname
C. L7 (HTTP) load balancer — can inspect HTTP URL path and route /api/* to Python backends, /static/* to CDN
origin ✓
D. L3 (IP) load balancer — routes based on destination IP
Explanation: L4 load balancers only see TCP/IP headers — cannot read HTTP content. L7 load balancers (nginx, AWS ALB)
terminate HTTP connection, inspect headers and URLs, then forward to appropriate backend pool based on routing rules.

Q — Stateful vs Stateless Firewall

Scenario: Stateless firewall allows inbound TCP port 443. Attacker sends crafted TCP RST packets to port 443 with no prior
connection. They reset legitimate connections.

How does switching to a stateful firewall fix this?

A. Stateful firewalls block all RST packets regardless of connection state
B. Stateful firewalls block port 443 completely
C. Stateful firewalls maintain connection state table — RST with no matching established connection is
dropped automatically even if port 443 is allowed ✓
D. Stateful firewalls require VPN for all inbound connections
Explanation: Stateless: evaluates RST → port 443 allowed → passes. No memory that RST doesn't correspond to established
connection. Stateful: checks RST against state table → no matching SYN/SYN-ACK entry → drops packet as invalid.
06-12 ADDITIONAL TOPICS — BONUS MARKS (Light Study Only)
INSTRUCTION: For these topics, read the notes once and understand key concepts. You don't need to go deep. These give you
extra/bonus marks — not core marks. One MCQ per topic is enough to get the idea.

6. Scripting — Bash & Python (Important)

Bash essentials: set -e (exit on error), set -u (error on undefined var), set -o pipefail. Loops: for/while. Conditionals:
if/elif. Functions. Pipes. Exit codes.
Python essentials: [Link]() for HTTP calls. [Link]() for system commands. [Link]() for JSON. Open
file in 'a' mode to append to log.
Interview ask: 'Write a script that checks if nginx is running and restarts it if not.' Know this pattern in both Bash and
Python.

Q — Bash Strict Mode

Scenario: Deploy script runs: build_app && run_tests && deploy. If run_tests fails, deploy still runs.

How do you make the script exit immediately on any error?

A. Add 'exit 0' at the top
B. Add 'set -e' at the top — script exits immediately if any command returns non-zero ✓
C. Use 'set +e' to enable strict mode
D. Wrap every command in an if-statement manually
Explanation: 'set -e' (errexit): exit script immediately when any command fails. Combine with 'set -u' and 'set -o pipefail' for production
Bash scripts.

7. Configuration Management — Ansible (Important)

Ansible key concepts: idempotency (running playbook twice has same result as once), playbooks (YAML tasks), roles
(reusable task collections), inventory (list of hosts).
Focus: write one playbook that installs nginx and starts it. Understand roles vs tasks.

Q — Idempotency
Scenario: You run an Ansible playbook to install nginx. You run it a second time on same server.

What should happen?

A. Installs nginx again from scratch, overwriting existing install
B. Detects nginx already installed and makes no changes — system remains in desired state ✓
C. Fails because nginx is already installed
D. Uninstalls and reinstalls nginx every time
Explanation: Idempotency: running the same operation multiple times produces the same result as running it once. Ansible modules
check current state before acting. If nginx is already installed, task reports 'ok' and skips install.

8. Docker & Kubernetes (Important)

Docker: Image = immutable blueprint (class). Container = running instance (object) with writable layer. Volumes persist
data beyond container lifecycle.
Kubernetes: Pod = smallest deployable unit. Deployment = manages ReplicaSet = manages Pods (auto-restart).
Service = stable network endpoint for Pods.
etcd: stores ALL K8s cluster state. Without etcd the cluster cannot function.
kubectl apply -f [Link] flow: kubectl → API server (auth+validate) → etcd (store) → controller manager
(reconcile) → scheduler (assign node) → kubelet (run container).

Q — Docker Image vs Container

Scenario: Junior engineer: 'I deleted the container and lost my data — I thought images and containers were the same.'

What is the correct difference?

A. Images are running instances; containers are blueprints
 B. An image is read-only blueprint (layered filesystem); a container is a running instance with a writable layer
✓
C. They are identical — containers are just renamed images
D. Containers persist data permanently; images are temporary
Explanation: Image: immutable layered filesystem — like a class. Container: running instance with its own writable layer — like an
object. Deleting a container loses the writable layer unless volumes are used.

9. CI/CD — GitHub Actions, Jenkins, GitLab CI (Important)

Continuous Integration: every code commit triggers automated build + tests.
Continuous Delivery: every passing build is ready to deploy. Human approves prod deployment.
Continuous Deployment: every passing build automatically deploys to production — no manual gate.
GitHub Actions: YAML workflow files in .github/workflows/. Triggers: on: push, on: pull_request. Jobs have steps.

Q — CI/CD Difference
Scenario: Team A: deploy to prod manually after tests pass. Team B: deploy to prod automatically after every green build.

Which team has Continuous Deployment?

A. Team A has Continuous Deployment; Team B has Continuous Delivery
B. Team B has Continuous Deployment (automatic to prod); Team A has Continuous Delivery (manual gate to
prod) ✓
C. Both are the same — CD means same thing in both cases
D. Neither without a Jenkins server
Explanation: Continuous Delivery: every build is releasable, human approves prod deployment. Continuous Deployment: every
passing build auto-deploys to prod with no manual gate.

10. Storage Technologies (Important)

iSCSI: block storage over TCP/IP. Targets (servers) and initiators (clients). Higher latency due to SCSI + TCP
overhead.
NFS: shared file storage over network. Multiple clients mount same directory concurrently. Good for shared configs,
logs, home dirs.
Ceph: distributed storage across commodity servers. CRUSH algorithm. No single point of failure. Supports block
(RBD), file (CephFS), object (S3/Swift via RADOS GW).
NVMe-oF: NVMe over Fabrics (RDMA or TCP). Much lower latency than iSCSI. For latency-sensitive workloads like
NVMe SSDs over network.
Object storage (S3): HTTP-based key-value store. GET/PUT/DELETE entire objects. No POSIX filesystem. Cannot
run databases on it directly.

Q — Object Storage Limitation

Scenario: Engineer suggests storing PostgreSQL data files on S3 to save cost.

What is wrong with this?

A. S3 is too expensive for databases
B. Object storage has no filesystem semantics — no random read/write, no file locking, no POSIX compliance
needed by databases ✓
C. S3 only supports read operations, not writes
D. No problem — databases work fine on S3
Explanation: Databases require block storage with POSIX filesystem semantics: random read/write at byte level, file locking (fsync),
atomic updates. Object storage is HTTP-based key-value — PUT/GET entire objects. No partial writes, no locking. Databases must
run on block storage (EBS, local NVMe).

11 & 12. Certifications & Open Source (Nice-to-have)

Certifications: AWS Cloud Practitioner (foundational, 4-6 weeks prep) or Red Hat RHCSA (Linux admin, matches JD
directly). Mention any cert you have prominently in your resume.
Open source: even one GitHub PR to a project like Ansible, Kubernetes, or Ceph counts. Find issues tagged 'good first
issue' on GitHub. Shows genuine interest.
 Interview story: use STAR method (Situation → Task → Action → Result) for any technical problem you solved —
homelab, personal project, or coursework. Demonstrates analytical thinking.

QUICK REFERENCE SUMMARY

Topic Most Asked Interview Point Remember

Cloud IaaS vs PaaS vs SaaS + HA vs FT Elasticity = auto-scale

KVM/QEMU Type-1, VT-x required, VirtIO QEMU = devices, KVM = CPU/mem

Distributed CAP, Raft quorum, 2PC blocking, Kafka offsets P is non-negotiable in CAP

Linux SUID, journalctl, ss -tlnp, kill vs kill -9 set -e in Bash scripts

Networking Subnetting math, DHCP relay, L4 vs L7 LB /26 = 4 subnets, 62 hosts from /24

Bonus VirtIO, Ceph, Idempotency, CI vs CD Light study only

FINAL ADVICE: Do Core Topics (1-5) fully — that is your 80% marks. For Additional Topics (6-12), read notes once and understand the
one MCQ per topic — that gives you bonus marks. Best single resource: 'Designing Data-Intensive Applications' by Martin Kleppmann
for Distributed Systems. Best Hindi YouTube: Gate Smashers (Networks + Linux) and Shrayansh Jain (System Design + Distributed
Systems).