DEV Community: Yashvi Kothari

Lovable Data Leak 2026: 24,664 AI Apps Exposed 80,000+ User Records via Supabase

Yashvi Kothari — Tue, 03 Nov 2026 21:46:58 +0000

The $0 Security Breach: How 24,664 AI-Built Apps Leaked Your Passport Number

A Cloud Security Analysis of the Lovable/Supabase Data Exposure

The Hook

In November 2026, security researchers scanned 159,041 AI-generated web applications.

They didn't hack anything.

They didn't use zero-days.

They simply knocked on doors that were left wide open—and found 80,000+ user profiles, unencrypted passport numbers, payment details, and 200,000 private chat messages sitting in plain sight.

The culprit? A "no-code" promise that made building easy and securing optional.

This is the story of how AI democratized software creation—and accidentally democratized data breaches.

The Setup: When "Easy" Becomes "Exposed"

Lovable is a Swedish AI startup that turns plain English into working web applications. Type "build me a customer portal," and it appears. No code. No technical knowledge required.

The marketing is seductive. The terms and conditions? Less so—they quietly place all security responsibility on the user.

Here's the gap: Non-technical founders built production apps with sensitive data. They didn't know they needed to secure the backend. And nobody forced them to learn.

The result was predictable.

The Technical Autopsy: What Actually Happened

Researchers focused on Supabase—the open-source Firebase alternative that Lovable integrates for database functionality. Of the 159,041 projects analyzed:

· 34,545 used Supabase
· 24,664 leaked database records immediately upon page load
· 7,403 exposed email addresses across 10,560 tables

The Root Cause: Row Level Security (RLS) Turned Off

Supabase uses a client-side JavaScript library. Your frontend holds a public anon key—by design. That key is meant to be public.

But here's the catch: That public key can only access what your database policies allow.

When RLS is disabled or misconfigured:

· Anyone with browser DevTools can see your anon key
· Anyone with that key can query your database
· Anyone can read every row in every table

The researchers didn't brute-force passwords. They opened Chrome, inspected network traffic, grabbed the key, and queried tables like profiles, messages, and payments.

One request. Full access.

The DevSecOps Nightmare: AI Code Uniformity

Here's where it gets worse.

AI generates code using recurring architectural patterns. Lovable apps follow predictable structures:

· Same Supabase initialization
· Same client-side key exposure
· Same missing RLS configurations

This uniformity is a gift to attackers.

A single automated script that detects "Supabase + Lovable" can scan thousands of applications simultaneously. What worked against one app works against all of them.

The scale of exploitation is now a function of AI's consistency, not attacker sophistication.

The Damage Report

The exposed data wasn't abstract. It included:

Data Type Example
Identity Documents 1,000+ records with passport numbers, expiration dates, nationalities
User Profiles 80,000+ full names, emails, birthdates, gender
Private Communications 200,000+ chat messages, internal WhatsApp threads
Financial Records Invoices, payment details, ticket codes
Business Intelligence AI-generated email summaries about tenants, owners, partners

One provider leaked 280,000 customer emails.

This is phishing fuel. Identity theft raw material. Fraud starter kit.

The Fix: Row Level Security in Supabase

If you're building on Supabase—with or without AI—here's the non-negotiable first step:

Step 1: Enable RLS on Every Table

ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;
ALTER TABLE messages ENABLE ROW LEVEL SECURITY;
ALTER TABLE payments ENABLE ROW LEVEL SECURITY;

Do this before you add data. Not after.

Step 2: Write Explicit Access Policies

-- Users can only read their own profile
CREATE POLICY "Users read own profile"
ON profiles
FOR SELECT
USING (auth.uid() = user_id);

-- Users can only read their own messages
CREATE POLICY "Users read own messages"
ON messages
FOR SELECT
USING (auth.uid() = sender_id);

Step 3: Test Like an Attacker

Open your app in an incognito window
Open DevTools → Network tab
Find your Supabase API calls
Copy the anon key
Use curl to query a table you shouldn't access

curl 'https://your-project.supabase.co/rest/v1/profiles?select=*' \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

If you see data you shouldn't, you're exposed.

The DevSecOps Checklist for AI-Built Apps

Before any AI-generated app touches real data:

Check Why It Matters
✅ RLS enabled on all tables Blocks unauthorized row access
✅ Explicit SELECT, INSERT, UPDATE, DELETE policies RLS alone isn't enough
✅ anon key limited to intended public data Never allow it to bypass RLS
✅ API response payloads inspected See what the frontend actually receives
✅ Automated fuzzing of database endpoints Catch what manual review misses
✅ IAM/RBAC validated before production Defense in depth

The Lesson: AI Doesn't Remove Responsibility. It Redistributes It.

Lovable's marketing promises ease. Its terms require expertise.

Between those two lies a chasm—and 7,403 applications fell into it.

The uncomfortable truth: AI can write your backend, but it can't own your security posture. That responsibility remains human. It requires understanding access control, database policies, and the difference between "it works" and "it's safe."

Cloud security isn't a feature you bolt on later. It's a decision you make before the first user signs up.

The Closing Thought

The researchers didn't exploit a vulnerability.

They exploited a pattern—a predictable, repeatable, AI-generated pattern that said: "We didn't know we needed to lock this door."

The fix is simple. The lesson is expensive.

Enable RLS. Write policies. Test like an attacker.

And the next time an AI offers to build your app in four minutes, ask it one question:

"Did you enable Row Level Security?"

If it doesn't know the answer, neither do you.

Did this help you understand the Lovable/Supabase exposure? Share it with someone building their first AI-generated app. The knowledge gap is the vulnerability.

Reference Research Report:
https://www.crissyfield.de/research/lovable-en/

How a Marketing Manager Deployed a Production Data Leak in 4 Minutes (And Why Your Scanner Missed It)

Yashvi Kothari — Tue, 03 Nov 2026 20:54:34 +0000

Code is Now Free. Security Architecture is Still Expensive.

AI lets anyone ship to production on Vercel in minutes. Learn why passing a build scan isn't enough and how CNAPP and CSPM stop shadow deployment leaks.

How do you secure multi-team deployments on platforms like Vercel at scale?

Securing rapid PaaS deployments requires moving beyond single-team application scans to centralized Cloud Native Application Protection Platforms (CNAPP) and SaaS Security Posture Management (SSPM). Key controls include enforcing authentication on production URLs, storing API keys as write-only secrets rather than readable config variables, strictly enforcing SAML SSO across all sub-teams, and rotating access tokens older than 90 days.

In 2016, deploying an application to production required a Linux sysadmin, a Terraform state file, an IAM role review, and a three-day change-management ticket.

Today, it requires a prompt and a credit card.

AI coding assistants and frictionless deployment platforms like Vercel have collapsed the distance between an idea and a live production URL. A marketing manager can prompt an internal customer portal into existence at 9:00 AM and deploy it to the global edge by 9:15 AM.

Creation has been democratized. Security has not.

When deployment friction drops to zero, shadow IT mutates into Shadow Production. And it introduces a terrifying blind spot for Cloud Operations and Security engineers: Your application passed its built-in security scan. Everything is green. Yet your customer database is wide open.

Let’s break down why a successful deployment is not a secure deployment—and how we architect visibility when every department becomes a software team.

The Anatomy of a 15-Minute Breach

Imagine this scenario—inspired by real-world enterprise findings recently highlighted by Orca Security.

A growth manager needs a quick portal to analyze customer support conversations. Waiting on the core engineering sprint takes three weeks. So they open an AI code generator, connect a frontend template to a production database containing customer names and support transcripts, and push it to Vercel.

The build succeeds.
The automated dependency scanner passes. (Zero critical CVEs in package.json!)
The URL goes live.

To the creator, the job is done. To a Cloud Security engineer, four silent alarms just went off—except no one can hear them because the deployment happened in an isolated team workspace outside the central AWS or GCP security perimeter.

The 4 Silent Misconfigurations of Rapid PaaS Deployments

When non-security practitioners—or fast-moving product teams—spin up isolated deployment environments, four architectural failures show up almost immediately.

[AI Prompt / Code] 
       │
       ▼
[Vercel / PaaS Deployment] ──► Passed Dependency Scan (Green Checkmark!)
       │
       ├── ❌ 1. Public Prod URL (No Auth Layer)
       ├── ❌ 2. API Keys in Plaintext Config (Not Write-Only Secrets)
       ├── ❌ 3. SAML Connected, Never Enforced (Bypassed IdP)
       └── ❌ 4. Zombie Tokens (>90 Days Unused, No Expiry)
       │
       ▼
[Production Database / AWS Backend] ──► SILENT DATA EXPOSURE

1. Public Production URLs Without Authentication

AI tools optimize for working code, not defensive code. When you deploy a preview or production branch on modern PaaS platforms, it generates a live, publicly routable URL immediately. Unless authentication middleware or deployment protection is explicitly wired in, anyone who guesses, scrapes, or discovers that URL via certificate transparency logs has direct access to the portal.

2. Secrets Stored as Readable `Config` Instead of `Secret`

There is a massive architectural difference between a Configuration Variable and a Secret.

Config variables are readable in plaintext by anyone with project dashboard access.
Secrets are write-only—injected at runtime and hidden from the UI.

When someone pastes a database connection string or an AWS IAM access key into a standard readable config field, every contractor, intern, or compromised developer account in that workspace can copy-paste your production credentials in two clicks.

3. The SAML Illusion (Connected vs. Enforced)

Security teams love checking the "SSO Integrated" box. An organization connects Okta or Entra ID via SAML to their deployment platform and moves on. Here is the trap: connecting an Identity Provider (IdP) is not the same as enforcing it. If SAML enforcement isn't toggled on, users can bypass your corporate IdP entirely and log in via standard email/password or unmonitored social logins—circumventing your MFA and conditional access policies.

4. Zombie Access Tokens

To hook up CI/CD pipelines or third-party integrations, teams generate personal or team access tokens. Often, these tokens are created with "No Expiration" and forgotten. Six months later, the project is abandoned, the token sits unused for over 90 days, and it remains a live, unmonitored backdoor into your deployment infrastructure.

The CloudOps Blind Spot: Why Single-Team Dashboards Fail

If you have one Vercel team, you can audit these four settings before your morning coffee cools.

What happens when your enterprise has 40 teams?

A platform’s native dashboard shows you the posture of one workspace at a time. It does not correlate how a readable API key in a rogue Vercel project connects to an over-permissive IAM role in your core AWS environment, or a storage bucket in GCP or Azure.

To solve this, you have to stop treating deployment platforms like isolated developer toys and start treating them as extensions of your cloud control plane. Here is how modern security domains map to this problem:

Security Domain	Core Function	What It Solves in Shadow Deployments
CSPM (Cloud Security Posture Management)	Misconfiguration detection	Flags public production URLs and disabled firewall rules automatically.
CIEM (Cloud Infrastructure Entitlement Management)	Identity & permission visibility	Identifies who has admin access across 50 fragmented team workspaces and enforces SAML.
Secrets Management	Credential exposure prevention	Detects sensitive keys stored in readable config metadata without exposing the secret value itself.
SSPM (SaaS Security Posture Management)	SaaS configuration hygiene	Audits zombie access tokens (>90 days dormant) and unmonitored team creations.
AppSec (Application Security)	Code & dependency scanning	Catches vulnerabilities inside the code (necessary, but blind to infrastructure exposure).
CNAPP (Cloud Native Application Protection Platform)	Cross-environment risk correlation	The Endgame: Connects the exposed Vercel config variable to the exact AWS/GCP database it unlocks.

The Engineering Takeaway: Audit Metadata, Not Just Code

The most elegant takeaway from how platforms like Orca Security approach this problem is agentless, read-only metadata auditing.

You don't need to install heavy agents on serverless edge functions, and your security tool shouldn't actually read the plaintext values of your secrets. By querying the platform's API in read-only mode, a strong CloudOps architecture continuously inventories:

Every newly spun-up team (eliminating manual registration).
Environment variable metadata (verifying how a variable is stored—Config vs. Secret—without reading what it is).
Cross-cloud blast radius (viewing PaaS deployment risks right next to your AWS CloudTrail and IAM findings).

Your Monday Morning CloudOps Checklist:

If your organization uses rapid deployment platforms alongside AWS, Azure, or GCP, run this mental audit today:

Inventory the sprawl: How many independent team workspaces exist across your organization right now?
Check SAML state: Is SSO merely connected, or is it strictly enforced?
Audit variable types: Are database URLs and API keys stored as readable environment configs?
Kill dormant tokens: Revoke any CLI or API token that hasn't seen traffic in 90 days.

AI made building software effortless. That means our job in Cloud Operations is no longer gatekeeping the build—it is securing the blast radius.

What Is the Storm-3168 Azure Service Principal Attack and How Do You Detect It?

Yashvi Kothari — Tue, 03 Nov 2026 20:01:31 +0000

Storm-3168: How One Compromised Service Principal Can Put an Entire Cloud Environment at Risk

Storm-3168 used one leaked service principal secret to destroy Azure workloads in 7 minutes. Here's how to detect it and reduce your blast radius.

If one of my workload identities was compromised right now, what would I check first?

That question is the entire article. Not the threat actor. Not the timeline. Not the press release.

Storm-3168 is a reminder that the most dangerous identity in your cloud isn't a human with a password. It's a service principal nobody watches, holding permissions nobody reviewed, using a secret somebody pasted into GitHub.

Here's what happened, and here's what I'd do about it.

What Happened in Storm-3168

In June 2026, Microsoft tracked a campaign it calls Storm-3168 (linked to JADEPUFFER). Two compromised Azure service principals from the same tenant executed a devastating sequence: 15.5 hours of quiet reconnaissance, a 7-minute destruction window, and a credential-harvesting phase that followed .

The numbers matter because they show intent and automation:

· 300+ successful read operations during reconnaissance
· 100+ storage account deletion attempts
· 30+ successful ListKeys requests after the destruction

The first service principal spent over fifteen hours mapping subscriptions, VMs, and resource groups. The second enumerated two subscriptions in five seconds, then began deleting storage accounts, Key Vaults, Function Apps, and App Service plans. It also tried to remove Azure Site Recovery and Backup protection locks—not random vandalism, but a deliberate attempt to disable recovery .

The initial access vector? A client ID, client secret, and tenant ID posted in plaintext in a public GitHub issue. The issue was later edited to remove the secret, but the edit history preserved it .

That's it. That's the whole entry point.

How Service Principal Credentials Get Compromised

Service principals are the workhorses of cloud automation. They don't have MFA. They don't have a device posture. They often don't have a human owner who notices when something's wrong .

The compromise paths are boringly predictable:

Public code exposure. The Storm-3168 vector. A secret pasted into an issue, a commit, a gist. The edit history is forever.

Over-permissioned app owners. Anyone who can add a credential to an application can authenticate as that application. If the app holds Directory.ReadWrite.All, the attacker just became a directory admin without touching a password .

Standing privilege with no expiry. A service principal created for a migration project in 2024 still holds Owner on the subscription in 2026. The attacker's window equals the credential's lifetime .

Unmonitored sign-in logs. Service principal sign-ins often bypass the alerting that human sign-ins receive. An attacker with a valid secret looks exactly like your CI/CD pipeline—until they don't.

How Excessive Azure RBAC Permissions Increase the Blast Radius

Here's the uncomfortable truth: Storm-3168 didn't exploit a vulnerability. It used the permissions the service principals already had .

The reconnaissance identity could enumerate the entire tenant. The destructive identity could delete storage accounts, Key Vaults, and Function Apps. That's not a misconfiguration in the traditional sense. That's the default outcome of granting broad roles because "it's just an automation account" .

Blast radius isn't abstract. It's the answer to: If this identity's secret leaked right now, what's the worst an attacker could do before anyone notices?

For a service principal with Owner at subscription scope, the answer is: everything in that subscription. For a principal with Contributor plus ListKeys permissions on storage, the answer is: delete the data, then harvest the keys to whatever survives .

The Storm-3168 attackers specifically targeted backup and Site Recovery controls. They understood that destroying production is loud, but destroying recovery options is what makes the damage permanent .

How Attackers Misuse Legitimate Cloud APIs

There's no malware in Storm-3168. No endpoint compromise. No lateral movement through VMs.

Just python-requests/2.34.2 calling Azure Resource Manager APIs .

The API calls themselves are documented, supported, and expected:

· ListKeys on storage accounts is how applications retrieve access keys. The attackers used it 30+ times to harvest credentials after destruction .
· Resource deletion APIs are how Terraform cleans up. The attackers used them 100+ times in seven minutes .
· Enumeration APIs are how inventory tools work. The attackers used them for 15 hours before anyone noticed .

This is the core lesson of cloud-native attacks: the API doesn't know your intent. It only knows your token. If the token is valid and the permission is present, the action succeeds.

The one thing that broke the attack wasn't a security control. It was a version mismatch—the attackers used an unsupported API version for SQL deletion, and those attempts failed . Don't count on that.

How to Detect Suspicious Activity Using Entra ID and Azure Activity Logs

If I suspect a workload identity is compromised, I'm not opening a dashboard. I'm running queries.

Entra ID sign-in logs:
Look for service principal sign-ins from IPs not seen in the last 30 days. The Elastic detection rule for rare service principal activity from multiple IPs is a good starting point: it surfaces principals performing low-frequency actions from multiple source IPs, which often indicates stolen credentials or token replay .

Azure Activity Logs:
Filter for Delete operations initiated by service principals. Then look for ListKeys calls in the same time window. The Storm-3168 pattern—destruction followed by key harvesting—is detectable if you correlate the two.

A practical KQL approach for Activity Logs:

AzureActivity
| where OperationNameValue has_any ("DELETE", "LISTKEYS")
| where Caller contains "service principal name or object ID"
| project TimeGenerated, OperationNameValue, ResourceGroup, Caller, CallerIpAddress
| sort by TimeGenerated desc

The one detection that would have caught Storm-3168 early: A service principal performing ListKeys on a storage account it has never touched before, from an IP that isn't your build agent's egress range. That's not automation. That's reconnaissance or harvesting .

For credential additions specifically, alert on Update application – Certificates and secrets management outside your secrets rotation pipeline. If a human added a secret to a high-privilege app at 3 AM, that's worth a page .

AWS IAM Roles, Least Privilege, and CloudTrail: A Useful Mirror

I don't write about AWS to pad word count. I write about it because AWS's model exposes what Azure teams often miss.

In AWS, long-term access keys are the exception, not the default. IAM roles with temporary credentials via STS are the norm. A compromised role session expires. A leaked Azure service principal secret—unless you built rotation—doesn't .

CloudTrail's strength isn't that it's magic. It's that the events are structured around who assumed what role, from where, and what did they do with it. AssumeRole chains create an audit trail that links a session back to its origin. Azure's equivalent—service principal sign-ins correlated with Activity Log operations—is possible, but fewer teams build the correlation .

The least-privilege comparison is equally sharp. AWS permission boundaries and IAM Access Analyzer can surface escalation paths before an attacker finds them. In Azure, the equivalent discipline is scoped RBAC assignments plus Privileged Identity Management for anything that doesn't need to be always-on .

The gap isn't technical. It's cultural. AWS teams grew up with temporary credentials. Many Azure teams grew up with a secret in a config file.

Five Practical Lessons for Cloud Security and DevOps Engineers

Audit every service principal secret. Right now.
Search your GitHub organization's issue and commit history for client_secret, AZURE_CLIENT_SECRET, and tenant IDs. Rotate anything you find. The Storm-3168 entry vector was an edited issue—the secret remained in the edit history .
Treat ListKeys as a sensitive operation.
Storage account key retrieval is credential access. Alert when a service principal that normally runs Get or List operations suddenly calls ListKeys, especially after a burst of deletions .
Scope RBAC to the resource, not the subscription.
If a service principal only needs to manage one storage account, give it Storage Account Contributor on that account. Not Contributor on the resource group. Not Owner on the subscription. The blast radius shrinks with every scope reduction .
Use PIM for workload identities that don't need standing access.
Most automation needs persistent permissions. Some doesn't. For the service principals that only run during deployments, use just-in-time activation. The secret, if leaked, is useless outside the activation window .
Correlate identity logs with resource logs.
The Storm-3168 detection window exists because two log sources tell one story. Entra ID tells you who authenticated. Azure Activity Logs tell you what they did. If you're only watching one, you're watching half the attack .

The ghost of Storm-3168 isn't a sophisticated adversary. It's a forgotten secret in a public edit history and a service principal with permissions nobody questioned.

What would I check first?

The service principal secrets my team hasn't rotated. The RBAC assignments nobody can justify. The ListKeys calls in the Activity Log from an IP we don't recognize.

Start there. Then fix what you find.

Binance Hack: DevSecOps Lessons from the $6.34B Breach

Yashvi Kothari — Tue, 03 Nov 2026 18:15:18 +0000

A Poisoned Homebrew Install, a Fake Job Interview, and a $6.34 Billion Lesson in Cloud Operations

On Thursday, October 29, 2026, attackers moved roughly $6.34 billion in digital assets out of Binance’s hot wallets. As of Binance’s November 3 report, about $2.85 billion had been frozen or intercepted (subject to reconciliation and market price volatility), and by October 31, Binance had replenished 98% of the affected token assets from its own reserves.

Still, moving $6.34 billion out the door didn't happen because someone cracked a 256-bit cryptographic key. It didn't happen because a zero-day exploit melted a hardware firewall.

According to Binance’s initial incident report published November 3, it started months earlier with a poisoned package install, escalated through a fake job interview on a work laptop, and pivoted through an internal AI tool.

When you manage cloud infrastructure or DevSecOps, it is easy to obsess over the perimeter. We spend millions on Web Application Firewalls, Multi-Party Computation (MPC), and automated threat detection. Yet this incident reminds us of a brutal, timeless truth:

Your security architecture is never defined by whether a human makes a mistake. It is defined by the blast radius of their local environment when they do.

Let’s dissect how a months-long social engineering campaign bypassed multi-billion-dollar defenses, why an internal AI tool became a critical pivot point, and what every Cloud Operations engineer needs to fix in their stack today.

Act I: The Anatomy of a $6.34 Billion Breach

Great heists don’t happen in five minutes. They happen slowly, then all at once.

According to a Saturday alert from the FBI, state-sponsored attackers linked to North Korea (DPRK) were behind the campaign. As detailed in Binance’s initial report, the attackers didn't brute-force the front door. They spent five months mapping the humans inside the building.

1. The Reconnaissance (June 2026)
An engineer on the Wallet DevOps team ("Engineer A") wanted to install a popular AI coding tool. They searched for it on a search engine and downloaded a tampered Homebrew installation.

Binance’s security team caught the anomaly, replaced the device, and rotated related credentials. Case closed? Not quite. Before the device was replaced, the attackers got the one thing you cannot rotate: the org chart. Engineer A’s role and their colleagues on the wallet infrastructure team were now exposed to the attackers.

2. The Hook (September 2026)
Enter "Engineer B." According to Binance's report, an individual posing as a Project Director contacted Engineer B on a job-hunting platform where their profile referenced their Binance experience, setting up a two-round interview process. The first round was a live video interview with a fake "HR representative" who shared a personal social media account to build trust. Then came a second-round interview on a social chat app with an individual claiming to be the CEO of a fictitious company.

Near the end of the chat, Engineer B was instructed to download an interview "assignment" containing a code repository onto their work computer. During the setup process, malicious code inside the repo quietly executed.

3. The Sleight of Hand
That setup script didn't just build an app. It quietly hijacked the local Python version manager (pyenv) inside /opt/homebrew/, swapping the legitimate 3,344-byte pyenv wrapper script with a 3,414-byte malicious version:

CREATE  /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv_
MODIFY  pyenv_ -> 3,414 B
DELETE  .../libexec/pyenv (3,344 B)      (remove the valid pyenv)
RENAME  pyenv_ -> pyenv (3,414 B)        (replace with malicious version)
DELETE  /opt/homebrew/bin/pyenv
ln (create a new symlink) + spawn zsh

No endpoint detection alerts fired. The attacker was inside and communicating with an external server.

4. The AI Springboard (October 20, 2026)
How do you jump from a general software engineer’s laptop to the fortified Wallet DevOps team? Binance says the attackers used an internal AI tool from Engineer B’s compromised machine as a springboard to gain control over Wallet DevOps Engineer A and another Wallet Software Engineer ("Engineer C"). Sitting on Engineer A’s computer was the golden ticket: a container deployment permission token.

5. The Execution (October 29, 2026)
Between 17:15 and 19:56 UTC, the attackers logged onto Engineer C’s computer, used the credentials stolen from Engineer A, deployed a container, and triggered a malicious script targeting the internal wallet signing service.

At 20:05 UTC, the drain began. Across multiple networks, hot wallets started pouring out assets. On-chain trackers estimate roughly $3.8 billion was drained on Ethereum alone, alongside 18,270 BTC, 233.46 million XRP, 970,500 SOL, and 44.2 million OP reported by Binance.

Act II: When the Kill Switch Fails

Here is the part that should keep every Cloud Architect and SecOps engineer awake at night.

When Binance’s internal alerts triggered, the team hit the emergency brakes. They suspended withdrawals, shut down hot wallet services, and coordinated with industry partners to freeze assets (for example, Circle froze impacted USDC around 21:04 UTC, nearly an hour after the initial transfers began, contributing to the $2.85 billion frozen or intercepted as of the November 3 report).

Yet unauthorized transfers kept happening on Ethereum anyway.

To understand why, you have to separate the root compromise from the persistence mechanism. As blockchain intelligence firm TRM Labs points out, the other nine chains were drained using ordinary signed transfers, meaning the compromised internal signing service itself was signing transactions for the attacker.

On Ethereum, however, the attackers went a step further and used that signing access to build a persistence layer that outlived the server shutdown: Ethereum’s EIP-7702 authorization mechanism.

EIP-7702 allows an account to delegate certain execution rights to a smart contract without exposing the private key. On-chain analysts found a batch of about 50 authorizations tied to different nonce values, a tactic Odaily calls "nonce spraying" where only one authorization needed to land. That delegation gave an attacker-controlled smart contract partial execution rights over a Binance hot wallet.

Once those authorizations existed on-chain, they operated independently of Binance’s normal withdrawal infrastructure. Shutting down internal signing servers stopped the bleeding on other chains, but it couldn't invalidate a delegation already written into the Ethereum blockchain state.

Worse, because the hot wallet relied on Multi-Party Computation (MPC), there was no single private key an engineer could grab to immediately revoke the malicious EIP-7702 authorizations. The team had to build and execute a specialized procedure to revoke them while assets remained at risk. The final unauthorized transfer of 2,961.9 ETH finalized at 23:56 UTC, and Binance finally cleared the delegation code by authorizing to the zero address at 00:10 UTC on October 30, four hours after the drain started.

Act III: The CloudOps & DevSecOps Playbook

It is easy to point fingers at an engineer taking a side-hustle interview on a work MacBook. Anyone who has worked in operations knows that blaming the human is a lazy post-mortem.

Humans will always click links. Humans will always want a higher-paying job. Humans will always take shortcuts to install a shiny new AI tool.

If a single cloned Git repository on a developer's laptop can cascade into a rogue container deploying to a production signing environment, the failure isn't human. The failure is architectural.

Here are the five operational laws this incident proves we cannot ignore:

1. Contain the Blast Radius of Internal AI Tools

Binance hasn't disclosed the exact technical mechanism that allowed an internal AI tool to become a springboard between Engineer B, Engineer A, and Engineer C. Whatever the specific mechanism was, the architectural lesson is clear: internal AI tools, agentic workflows, and shared developer assistants sit at a privileged intersection of your engineering org.

The Fix: Treat internal AI infrastructure as Tier-0 assets. Isolate their execution environments, enforce strict least-privilege RBAC on what an AI service can query or execute, and ensure an internal AI tool can never execute commands or pass state across separate developer workstations.

2. Long-Lived Tokens on Laptops Are Ticking Time Bombs

Engineer A had a container deployment permission token sitting on their computer. In modern cloud operations, static or long-lived deployment tokens on local disks shouldn't exist.

The Fix: Enforce Zero Trust and Just-In-Time (JIT) access. Container deployments into sensitive environments should only happen via immutable CI/CD pipelines triggered by hardware-backed, short-lived OIDC sessions, never from a persistent token stored on a developer endpoint.

3. Move Local Dev Environments out of User-Owned Host Paths

Look closely at why replacing /opt/homebrew/bin/pyenv was so effortless. On Apple Silicon Macs, /opt/homebrew is owned by the local user account by default. That means any user-level malware triggered by a setup.py or npm install can silently overwrite developer binaries and scripts without ever triggering a sudo password prompt.

The Fix: Stop doing raw development on the host OS of corporate machines. Move coding workflows to ephemeral Cloud Development Environments (CDEs) or isolated DevContainers. If a developer runs an untrusted repo inside a sandboxed environment with no access to host paths or corporate tokens, the blast radius shrinks sharply.

4. Package Managers Need an Allowlist, Not Search Engines

Engineer A got compromised in June by searching for an AI tool online and running a poisoned Homebrew installation. Engineer B got compromised in September via a malicious repo modifying pyenv.

The Fix: Lock down endpoint package management. Engineers with access to production systems shouldn't pull arbitrary packages from the open internet or unverified taps. Route package installations through an internal, verified artifact registry with strict binary and script attestation.

5. Game-Day Your "Un-Revocable" Architecture

Binance used MPC to eliminate single points of failure. Irony struck when that exact complexity slowed them down from rapidly revoking malicious on-chain EIP-7702 delegations. Security controls designed to slow down an attacker can also slow down the defender during an active incident.

The Fix: Don't just run chaos engineering on server uptime; run chaos engineering on credential and state revocation. Ask your team today: "If an attacker modifies an IAM trust policy, registers a rogue OIDC provider, creates a persistent access key, or delegates smart contract execution rights right now, how many minutes does it take us to revoke it, and is that playbook pre-scripted?"

The Takeaway

Security isn't a product you buy. It is a series of friction points you design so that when someone makes a human mistake at 4:00 PM on a Thursday, the system absorbs the shock without collapsing.

Attackers aren't breaking encryption anymore. They are hacking trust, hijacking developer workflows, and turning our own automation against us.

Audit your endpoints. Lock down your AI tooling. Delete your local tokens.

Because in cloud operations, clarity in your architecture is the only thing standing between a routine Thursday and a $6.34 billion headline.

Let’s connect and talk Cloud, DevSecOps, and Infrastructure on LinkedIn: @yashvikothari

29 Notable Cloud & DevOps Professionals from India to Follow in 2026

Yashvi Kothari — Tue, 29 Sep 2026 20:36:01 +0000

India has one of the world's largest and fastest-growing cloud, DevOps, Kubernetes, and cloud-native communities.

There is no single official organization that maintains a definitive ranking of India's "Top 50 Cloud Engineers." Therefore, this list is not intended as a ranking or a claim that one professional is better than another.

Instead, it highlights 29 notable professionals based on publicly documented community leadership, open-source contributions, cloud certifications, ambassador/hero programs, technical education, and contributions to the cloud-native ecosystem.

Yash Pimple

CNCF Ambassador based in Mumbai, India. His CNCF profile highlights his work with Kubernetes, Kyverno, K8sGPT and Keptn, as well as his involvement in the Cloud-native Thane community.

Vyom Yadav

CNCF Ambassador from Chandigarh, with contributions involving Kubernetes, Kyverno, KubeArmor and other cloud-native projects.

Swastik Gour

CNCF Ambassador from Alwar, India, with project experience across Kubernetes, Helm, Cilium, Argo, KubeVela and K8sGPT.

Sreejith Anujan

CNCF Ambassador and Red Hat professional from Kerala, with extensive experience across Kubernetes, OpenShift, Helm, Kubeflow, OPA and other cloud-native technologies.

Kunal Kushwaha

Cloud-native educator, community builder and CNCF Ambassador known for his work in developer education and the WeMakeDevs community.

Saiyam Pathak

CNCF Ambassador and cloud-native community leader known for Kubernetes education, advocacy and technical evangelism.

Sangam Biradar

Cloud-native community contributor associated with Docker and CNCF communities.

Arun Gupta

A long-time open-source and cloud technology leader with experience across enterprise technology and developer communities.

Ayyanar Jeyakrishnan

AWS Machine Learning Hero based in Bengaluru, recognized by AWS for community contribution and expertise around machine learning and AWS technologies.

Gaurav Chhabra

Cloud and enterprise technology professional with a focus on cloud architecture and community contribution.

Yashvi Kothari

AWS Community Builder with a focus on Cloud Operations, Cloud Security and DevSecOps. Her public profiles document experience and learning across AWS, Azure, Digital Ocean and Oracle Cloud Infrastructure, along with cloud-security technologies and technical writing.

Piyush Sachdeva

Cloud engineering and community professional associated with cloud infrastructure and operations.

Gaurav Sen

Systems and cloud architecture educator and founder of InterviewReady, known for technical content around system design and distributed systems.

Sandeep Dinesh

Cloud and developer technology professional with experience in cloud architecture and developer advocacy.

Sathish VJ

Multi-cloud architecture professional and technology community contributor.

Rohan Shetty

Cloud-native and Kubernetes infrastructure professional.

Rupesh Sharma

Cloud and solutions architecture professional.

Prateek Jain

Cloud security and DevSecOps professional with a focus on security architecture and cloud infrastructure.

Venkatesh Iyer

Enterprise cloud solutions professional working around cloud architecture and enterprise technology.

Ankit Jain

Cloud infrastructure and SRE professional.

Bhavani Ravi

Software and cloud architecture professional.

Shubham Londhe

Cloud and DevOps educator and community mentor associated with TrainWithShubham.

Praveen Singampalli

DevOps and SRE educator associated with HeyDevOps and cloud/DevOps career education.

Abhishek Veeramalla

Cloud and DevOps engineer and technical educator known for practical DevOps and cloud learning content.

Aman Sharma

Cloud and systems engineering professional.

Sagar Utekar

Cloud operations and automation professional.

Sahil B.

Independent DevOps practitioner and technical community contributor.

Abhishek Singh N.

Independent DevOps practitioner.

Karthikeyan V.

Independent cloud and DevOps practitioner.

Methodology

This is a curated list, not an official ranking.

Inclusion can be based on publicly verifiable factors such as:

Official AWS Hero or Community Builder recognition
CNCF Ambassador status
Open-source contributions
Cloud-native community leadership
Technical education and mentorship
Public technical writing
Cloud architecture and infrastructure work
Contributions to developer communities

Because the Indian cloud ecosystem includes a very large number of skilled professionals, this list should not be interpreted as an exhaustive list of India's best cloud engineers.

The purpose is simply to provide readers with a starting point for discovering professionals, educators and community contributors working across India's cloud and DevOps ecosystem.

Phase 1 HTML

Yashvi Kothari — Tue, 22 Sep 2026 10:37:56 +0000

Phase 1 HTML
Don't spend months here.
Learn enough to create a webpage without copying a template.
Learn:
html
head
body
h1-h6
p
div
span
a
img
ul / ol / li
table
form
input
textarea
select
button
label
Also understand:
attributes
id
class
forms
links
images
semantic HTML
Practice project #1
Build:
Simple Airbnb Listing Page

Example:

Beautiful Apartment

[ IMAGE ]

Ahmedabad, Gujarat

₹3,000 / night

2 bedrooms
1 bathroom
WiFi
Kitchen

[ Reserve ]

No JavaScript.
No database.
No backend.

Just HTML.

Setup VSCode on your system.

Install both live server

First HTML Page

HTML Comments

When writing HTML, you may want to leave notes for yourself or other developers.

These notes are called comments.

Comments are useful for:

Explaining what a section of code does
Providing context for other developers
Leaving reminders
Making code easier to understand and maintain

The important part is:

Comments are not displayed on the webpage.

The browser reads them but ignores them when rendering the page.

HTML Comment Syntax

An HTML comment starts with .

<!-- This is a simple comment -->

Anything written between these two markers is treated as a comment.

For example:

<p>Welcome to my website!</p>

<!-- This paragraph displays a welcome message -->

The webpage will only display:

Welcome to my website!

The comment will not appear on the rendered page.

Multiline Comments

HTML comments can also span multiple lines.

<!--
This is a multiline comment.
The browser will ignore everything
written inside these comment markers.
-->

This can be useful when you want to explain a larger section of HTML.

Are HTML Comments Completely Hidden?

Not exactly.

Although comments don't appear on the rendered webpage, they are still present in the HTML source sent to the browser.

Anyone can inspect them.

To view the source of a webpage:

Open the webpage in your browser.
Right-click anywhere on the page.
Select View Page Source.

Or use the keyboard shortcut:

Ctrl + U

On macOS:

Cmd + U

You can then search the source code and find the comments.

Important

Don't put passwords, API keys, private information, or secrets inside HTML comments.

For example, never do this:

<!--
Database password: MySecretPassword123
-->

The comment isn't visible on the webpage, but it can still be seen in the page source.

Practice Exercise

Now let's see HTML comments in action.

Task

Open the provided HTML page.
Find the paragraph <p> tag.
Add an HTML comment below the paragraph tag.

For example:

<p>This is my paragraph.</p>

<!-- This is my first HTML comment -->

Save the HTML file.
Open the rendered webpage in your browser.
Right-click the page and select View Page Source.
Find the comment you added.

Notice the difference:

Rendered webpage:

This is my paragraph.

Page source:

<p>This is my paragraph.</p>

<!-- This is my first HTML comment -->

The browser doesn't display the comment, but the comment is still present in the source.

Lab Note

The goal isn't just to know the syntax.

The goal is to understand what the browser does with HTML comments.

Tags in HTML

Tags are fundamental building block of HTML file which tell browser how webpage should appear and behave.

Let's go to example.com website and view page source.

Blue one's are HTML Tags.

Only Information browser is getting from remote computer is a text document but it has to construct UI which might have favicon,title,animations,layout,colors etc.

So we need to deliver a lot of information like what is animation/colors/content/font-size,font-family,font-type/link & where link is pointing to ?

Thus we use HTML.

Eg:
title tag is responsible for:

we have lot of tags. p tag for pargraph. div tag for division,etc.

Say Hello to HTML Elements

Your First HTML Element

You’ll begin by creating a simple web page using HTML. You can write and edit your code directly in the code editor provided on this page.

Look at the code in your editor:

<h1>Hello</h1>

This is an HTML element.

Most HTML elements have two parts:

An opening tag
A closing tag

Opening Tag

An opening tag looks like this:

<h1>

Closing Tag

A closing tag looks like this:

</h1>

The main difference is the forward slash / in the closing tag.

So:

<h1>Hello</h1>

means:

<h1> → opening tag
Hello → element content
</h1> → closing tag

Complete the Challenge

For this challenge, modify the existing <h1> element so that its text says:

Hello World

Your final code should be:

<h1>Hello World</h1>

That’s it. You’ve just created your first HTML element with the correct content.

Create a Headline with the `h2` Element

In the next few tasks, we’ll build an HTML5 CatPhotoApp step-by-step, adding new elements and features as we go.

Understanding the `h2` Element

The h2 element is used to create a level-two heading on a web page.

HTML headings help organize the structure of your webpage.

A common heading structure looks like this:

<h1>Main Heading</h1>
<h2>Subheading</h2>
<h3>Another Subheading</h3>

The h1 element is generally used for the main heading, while h2 is commonly used for subheadings.

HTML also provides:

h3
h4
h5
h6

These elements represent different levels of headings and subheadings.

Complete the Challenge

You already have an h1 element containing:

<h1>Hello World</h1>

Now, add an h2 element directly below it.

The h2 should contain the text:

CatPhotoApp

Your final code should look like this:

<h1>Hello World</h1>
<h2>CatPhotoApp</h2>

This creates your second HTML element and adds a level-two heading to the page.

Anchor Tag

The <a> element, also called the anchor element, is used to create hyperlinks in HTML.

It can link to:

Web pages
Files
Email addresses
A specific location on the same page
Other destinations that can be accessed through a URL

The `href` Attribute

The href attribute specifies where the link should take the user.

For example:

<a href="https://example.com">Visit Example</a>

Here:

<a> → opening anchor tag
href="https://example.com" → destination of the link
Visit Example → clickable text
</a> → closing anchor tag

The content inside the <a> element should clearly describe where the link will take the user.

If an href attribute is present, the link can also be activated using the Enter key when the anchor element has keyboard focus.

Write an anchor tag below linking to https://google.com

<a href="https://google.com">Google</a>

Block-Level and Inline Tags in HTML

The <p> element is commonly used to display paragraph text on a webpage.

The letter p stands for "paragraph."

Creating a Paragraph

You can create a paragraph element like this:

<p>I'm a p tag!</p>

A paragraph element has:

<p> → opening tag
I'm a p tag! → paragraph content
</p> → closing tag

Complete the Challenge

You already have an h2 element on your webpage.

Now, create a <p> element directly below the h2 element.

The paragraph should contain the text:

Hello Paragraph

Your code should look like this:

<h2>CatPhotoApp</h2>
<p>Hello Paragraph</p>

HTML Naming Convention

As a standard convention, HTML tags are written in lowercase.

Use:

<p></p>

Instead of:

<P></P>

Following lowercase conventions makes your HTML code consistent and easier to read.

Why HTML tags exist?

Button Tag. You can go ahead and click on screen.

We can pretty much customize almost every single aspect of HTML tags through CSS.When we use CSS we can make h6 tag as big as h1 & h1 tag as small as h6.We can reverse behaviour right away with CSS.
We can create div as button and button as div. Button is also inline element because text continues.

why don't we have all tag as div only ? because HTML was built to have semantics. Visually it can be identified which is largest heading, which is smallest heading ? but code should also be able to tell that without actually being parsed into webpage.Why so? because of accessibility reasons.

when you have h1 on page that means that is important heading.Your browser knows that accessibility readers or people who are disable
know that it is important heading.

similarly for button your accessibility reader know that it can be clicked.your browser won't be able to tell that to reader.

Lot of interactivity can be added with button with javascript.

we can attach event handlers. when we click on button turn h1 tag to red or h2 tag should disappear or h3 tag should change to bigger font size.

Image Tag

Images are integral part of communication and how we perceive the world.
So HTML allows to embed image directly with ease of single HTML tag.

img tag is inline and self-closing tag.

width and height attribute in html image tag works for legacy reasons but it's good if it's done with CSS.

With HTML few tags are deprecated. eg: center tag highlighting has stopped working.Browsers till support it so text got in center.Instead of using this HTML tag, CSS should be used.

Video (video) tag

Support of videos were very bad in terms of how browser could play them.Images and text were fine.You had to install/download adobe flash player/codex around 2005-2006.

since then there are new standards of video that allows us to transfer video more effeciently.

But support of video in browsers have majorly improved.
Browsers now allow you to embed video natively.

Unlike image tag, video tag are not self closing.

Embed this video
https://www.w3schools.com/html/mov_bbb.mp4

it almost look like image and we can't do anything no play pause button.
write attribute controls and not necessary to give it value.

Now video plays.

raw mp4 video link was embedded this is not case with youtube link. Youtube link is link of webpage it cannot play it.

for youtube link copy embedded snippet whole iframe thing.

Table (table) tag

organization of data in proper way

now for understanding purpose using css for border

Fun part of table is you can spawn certain cells to have multiple rows or coloumn

so remove 1 td in this tr.

now remove third value td of next row tr

You can scale upto page size,pretty awsome layouts can be created with sidebar,content area and header.Problem with it is it is very much hard to make it responsive.
Responsive webpage is adjusting its layout automatically with screen size.it works properly on desktops,mobile phones and tablets.

Thus table tag should not use for creating layouts but ony when tabular representation is needed.

Create a Text Field

Now let’s start creating a web form.

The <input> element is used to collect information from users.

Creating a Text Input

To create a text field, use the input element with the type attribute set to text:

<input type="text">

The type="text" attribute tells the browser that you want a field where the user can enter text.

Unlike many HTML elements, the <input> element does not need a separate closing tag. It is a self-closing element.

Complete the Challenge

Create an <input> element with the type set to text.

Place it below your lists in the HTML code.

Your code should include:

<input type="text">

This will add a text field where users can enter information.

Add Placeholder Text to a Text Field

Placeholder text is the text displayed inside an <input> field before the user enters any information.

You can add placeholder text using the placeholder attribute:

<input type="text" placeholder="this is placeholder text">

Here:

type="text" creates a text input field.
placeholder specifies the text shown before the user types anything.

Note: The <input> element does not require a closing tag.

Complete the Challenge

Set the placeholder value of your text input to:

cat photo URL

Your final code should look like this:

<input type="text" placeholder="cat photo URL">

This will display "cat photo URL" inside the text field until the user enters their own text.

Declare the Doctype of an HTML Document

So far, we’ve focused on individual HTML elements and what they do. Now, let’s look at a few elements that provide the overall structure of an HTML document.

These elements are commonly included in every HTML page.

Declare the HTML Version

At the beginning of an HTML document, you need to tell the browser which version of HTML the page uses.

HTML has evolved over time, and different versions have been released. Most modern browsers support the latest standard, HTML5.

For HTML5, declare the document type using:

```html id="y3t9u1"
<!DOCTYPE html>




This should always be placed on the **first line** of the HTML document.

The `!` and uppercase `DOCTYPE` are important, particularly for compatibility with older browsers. The `html` part is not case-sensitive.

## The `<html>` Element

After the `<!DOCTYPE html>` declaration, the rest of your HTML code should be placed inside the **`<html>`** element.

The opening tag:



```html id="z4o6q7"
<html>

goes directly below the doctype declaration.

The closing tag:

```html id="2n7k8p"




goes at the end of the document.

A basic HTML structure looks like this:



```html id="c7x2mp"
<!DOCTYPE html>
<html>
  <!-- Your HTML code goes here -->
</html>

Complete the Challenge

In the blank HTML document, complete the following steps:

Add the <!DOCTYPE html> declaration at the top.
Add an opening <html> tag below it.
Add a closing </html> tag at the end.
Place an <h1> element inside the <html> element.
The <h1> should be the only child element inside <html>.
The <h1> can contain any text.

Your structure should look like this:

```html id="8b4q1s"
<!DOCTYPE html>

Hello World




This gives your HTML document its basic structure and declares that it uses HTML5.

![ ](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/7e8ejcp7iaetluk0walp.png)
---
# Define the Head and Body of an HTML Document

Now that you know how to structure an HTML document with the `<html>` element, you can organize it further using the **`<head>`** and **`<body>`** elements.

## The `<head>` Element

The **`<head>`** element contains information about the webpage that is not displayed as the main page content.

Metadata elements such as:

* `<link>`
* `<meta>`
* `<title>`
* `<style>`

are typically placed inside the `<head>` element.

## The `<body>` Element

The **`<body>`** element contains the actual content of the webpage that users see in their browser.

For example, headings, paragraphs, images, and other visible page content belong inside the `<body>`.

A basic HTML document structure looks like this:



```html id="8k2mqp"
<!DOCTYPE html>
<html>
  <head>
    <!-- metadata elements -->
  </head>
  <body>
    <!-- page contents -->
  </body>
</html>

Complete the Challenge

Edit the existing HTML markup so that it includes both a <head> and a <body>.

Follow these requirements:

The <head> should contain only the <title> element.
The <body> should contain only the <h1> and <p> elements.

The structure should look like this:

```html id="q7v4nz"
<!DOCTYPE html>

Page Title

Hello World

Hello Paragraph




This separates the page's **metadata** from its **visible content** and gives your HTML document a clear structure.

![ ](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/uobeu7yz7tbosm3rfb2l.png)


![ ](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/sahgfwo818kdlyz36gxy.png)

---

# HTML (The Skeleton of Every Webpage)

> [!NOTE]
> HTML is NOT a programming language. It's a **markup language** — it tells the browser *what* things are (heading, paragraph, image, link), not *how* they behave. Think of it as **labeling** content.

---

## What is HTML?

**HTML** = **H**yper **T**ext **M**arkup **L**anguage

It's the **skeleton** of every webpage. Without HTML, there is no webpage.

| Analogy | Role |
|---|---|
| HTML | The **skeleton** and **organs** — structure |
| CSS | The **skin, hair, clothes** — appearance |
| JavaScript | The **muscles and brain** — behavior |

Right now, we're ONLY building the skeleton. It will look ugly. **That's fine.**

---

## How HTML Works

HTML uses **tags** to wrap content and tell the browser what each piece is.



```html
<tagname>Content goes here</tagname>

<tagname> = opening tag
</tagname> = closing tag (has a /)
Everything between = the content

Some tags are self-closing (no content inside):

<img src="photo.jpg" />
<br />
<hr />
<input type="text" />

1. The Basic Structure — `html`, `head`, `body`

Every HTML file has this skeleton:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My First Page</title>
</head>
<body>
    <!-- Everything visible goes here -->
</body>
</html>

Tag	What it does
`<!DOCTYPE html>`	Tells the browser "this is HTML5" (always include it)
`<html>`	The root — everything lives inside this
`<head>`	Invisible info — title, metadata, links to CSS files
`<title>`	The text shown on the browser tab
`<body>`	Visible content — everything the user sees

Analogy:

<head> = The label on a shipping box — info about the content, but not the content itself
<body> = The stuff inside the box — what you actually see

2. Headings — `h1` through `h6`

Headings define titles and hierarchy. h1 is the biggest, h6 is the smallest.

<h1>Main Title (use only ONE per page)</h1>
<h2>Section Title</h2>
<h3>Sub-section Title</h3>
<h4>Sub-sub-section</h4>
<h5>Rarely used</h5>
<h6>Almost never used</h6>

Rules:

Every page should have exactly one <h1>
Don't skip levels (don't jump from h1 to h4)
Headings are for hierarchy, not for making text big (that's CSS's job)

Analogy: Think of a book:

h1 = Book title
h2 = Chapter titles
h3 = Section within a chapter

3. Paragraph — `p`

For blocks of text.

<p>This is a paragraph. It automatically adds space above and below.</p>
<p>This is another paragraph. Each one starts on a new line.</p>

[!TIP]
Extra spaces and line breaks in your code are ignored by the browser. To force a line break, use <br />. But most of the time, just use separate <p> tags.

4. Division & Span — `div` and `span`

These are generic containers — they don't mean anything on their own. They're used to group things together.

`<div>` — Block-level container

Takes up the full width. Starts on a new line.

<div>
    <h2>Property Details</h2>
    <p>2 bedrooms, 1 bathroom</p>
</div>

`<span>` — Inline container

Stays in the same line as surrounding text.

<p>The price is <span>₹3,000</span> per night.</p>

Analogy:

<div> = A cardboard box — groups things together, takes up a row
<span> = A highlighter — marks a piece of text within a line

5. Links — `a` (Anchor)

Links take you to another page (or another part of the same page).

<!-- Link to another website -->
<a href="https://www.google.com">Go to Google</a>

<!-- Link opens in a new tab -->
<a href="https://www.google.com" target="_blank">Go to Google (new tab)</a>

<!-- Link to another page on your site -->
<a href="about.html">About Us</a>

<!-- Link to a section on the same page -->
<a href="#contact">Jump to Contact</a>

Attribute	Purpose
`href`	The URL to go to (required)
`target="_blank"`	Open in a new tab

6. Images — `img`

Displays an image. Self-closing tag (no </img>).

<img src="apartment.jpg" alt="Beautiful apartment in Ahmedabad" width="600" />

Attribute	Purpose
`src`	Path to the image file or URL (required)
`alt`	Description of the image (for accessibility & if image fails to load) (required)
`width`	Width in pixels (optional)
`height`	Height in pixels (optional)

Where can src point to?

<!-- Local file (same folder) -->
<img src="photo.jpg" alt="..." />

<!-- Local file (in a subfolder) -->
<img src="images/photo.jpg" alt="..." />

<!-- Image from the internet -->
<img src="https://example.com/photo.jpg" alt="..." />

[!IMPORTANT]
Always include the alt attribute. It helps blind users (screen readers read it aloud) and helps SEO. Never leave it empty for meaningful images.

7. Lists — `ul`, `ol`, `li`

Unordered List (bullet points)

<ul>
    <li>WiFi</li>
    <li>Kitchen</li>
    <li>Air conditioning</li>
</ul>

Output:

WiFi
Kitchen
Air conditioning

Ordered List (numbered)

<ol>
    <li>Search for a property</li>
    <li>Check availability</li>
    <li>Book and pay</li>
</ol>

Output:

Search for a property
Check availability
Book and pay

Tag	Meaning
`<ul>`	Unordered List (bullets)
`<ol>`	Ordered List (numbers)
`<li>`	List Item (goes inside `ul` or `ol`)

8. Tables — `table`

For displaying tabular data (rows and columns).

<table>
    <thead>
        <tr>
            <th>Feature</th>
            <th>Details</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Bedrooms</td>
            <td>2</td>
        </tr>
        <tr>
            <td>Bathrooms</td>
            <td>1</td>
        </tr>
    </tbody>
</table>

Tag	Meaning
`<table>`	The table container
`<thead>`	Table header group
`<tbody>`	Table body group
`<tr>`	Table Row
`<th>`	Table Header cell (bold, centered by default)
`<td>`	Table Data cell

[!WARNING]
Never use tables for page layout! Tables are ONLY for tabular data. Use CSS for layout (you'll learn this in Phase 2).

9. Forms — `form`, `input`, `textarea`, `select`, `button`, `label`

Forms collect user input. This is how login pages, search bars, and contact forms work.

The `<form>` container

<form action="/submit" method="POST">
    <!-- form fields go here -->
</form>

Attribute	Purpose
`action`	Where to send the data (URL)
`method`	How to send it (`GET` or `POST`)

`<label>` — Describes a form field

<label for="username">Username:</label>
<input type="text" id="username" name="username" />

The for attribute connects the label to the input's id. Clicking the label focuses the input.

`<input>` — The Swiss Army Knife

<!-- Text input -->
<input type="text" name="username" placeholder="Enter your name" />

<!-- Password (hidden characters) -->
<input type="password" name="password" placeholder="Enter password" />

<!-- Email (validates email format) -->
<input type="email" name="email" placeholder="you@example.com" />

<!-- Number -->
<input type="number" name="guests" min="1" max="10" />

<!-- Date -->
<input type="date" name="checkin" />

<!-- Checkbox -->
<input type="checkbox" name="wifi" id="wifi" />
<label for="wifi">WiFi</label>

<!-- Radio buttons (pick one) -->
<input type="radio" name="type" value="entire" id="entire" />
<label for="entire">Entire place</label>
<input type="radio" name="type" value="room" id="room" />
<label for="room">Private room</label>

<!-- Submit button -->
<input type="submit" value="Reserve" />

`<textarea>` — Multi-line text

<label for="message">Message:</label>
<textarea id="message" name="message" rows="5" cols="40" placeholder="Write your message..."></textarea>

`<select>` — Dropdown

<label for="guests">Number of guests:</label>
<select id="guests" name="guests">
    <option value="">-- Select --</option>
    <option value="1">1 Guest</option>
    <option value="2">2 Guests</option>
    <option value="3">3 Guests</option>
    <option value="4">4+ Guests</option>
</select>

`<button>` — A clickable button

<button type="submit">Reserve Now</button>
<button type="button">Save to Wishlist</button>
<button type="reset">Clear Form</button>

Type	Behavior
`submit`	Sends the form data
`button`	Does nothing by default (needs JS)
`reset`	Clears all form fields

10. Attributes — The Extra Info on Tags

Attributes provide extra information about an element. They go inside the opening tag.

<tag attribute="value">Content</tag>

Common Attributes (work on ALL elements)

Attribute	Purpose	Example
`id`	Unique identifier (only ONE element can have a specific id)	`<div id="header">`
`class`	Group identifier (many elements can share a class)	`<p class="highlight">`
`style`	Inline CSS (avoid using this; use CSS files)	`<p style="color: red;">`
`title`	Tooltip text on hover	`<p title="Extra info">`

`id` vs `class`

<!-- ID: unique, like your Aadhaar number — only ONE element -->
<div id="main-header">Welcome</div>

<!-- Class: shared, like a school house name — MANY elements -->
<p class="amenity">WiFi</p>
<p class="amenity">Kitchen</p>
<p class="amenity">Pool</p>

	`id`	`class`
Uniqueness	Must be unique on the page	Can be reused on many elements
Usage	One specific element	Group of similar elements
CSS selector	`#main-header`	`.amenity`

11. Semantic HTML

Semantic = "meaning." Semantic HTML uses tags that describe what the content IS, not just how it looks.

❌ Non-Semantic (tells you nothing)

<div id="header">
    <div class="nav">...</div>
</div>
<div id="main">...</div>
<div id="footer">...</div>

✅ Semantic (tells you everything)

<header>
    <nav>...</nav>
</header>
<main>...</main>
<footer>...</footer>

Semantic Tags You Should Know

Tag	Meaning	Use for
`<header>`	Top section	Logo, navigation, title
`<nav>`	Navigation	Menu links
`<main>`	Main content	The primary content of the page
`<section>`	Thematic group	A section of related content
`<article>`	Self-contained content	Blog post, news article, listing card
`<aside>`	Side content	Sidebar, related info
`<footer>`	Bottom section	Copyright, contact info, links
`<figure>`	Media with caption	Image + caption
`<figcaption>`	Caption for `<figure>`	Description of the image

Why bother?

Screen readers use these to help blind users navigate
Search engines (Google) understand your page better → better SEO
Other developers can read your code faster
You can read your own code 6 months later

[!TIP]
Rule of thumb: If there's a semantic tag that fits, use it instead of <div>. Ask yourself: "Is this a navigation? Use <nav>. Is this a footer? Use <footer>."

Quick Reference — All Tags You Learned

Tag	Purpose	Self-closing?
`<html>`	Root of the document	No
`<head>`	Metadata container	No
`<body>`	Visible content	No
`<h1>`–`<h6>`	Headings	No
`<p>`	Paragraph	No
`<div>`	Block container	No
`<span>`	Inline container	No
`<a>`	Link	No
`<img>`	Image	✅ Yes
`<ul>`	Unordered list	No
`<ol>`	Ordered list	No
`<li>`	List item	No
`<table>`	Table	No
`<tr>`	Table row	No
`<th>`	Table header cell	No
`<td>`	Table data cell	No
`<form>`	Form container	No
`<input>`	Input field	✅ Yes
`<textarea>`	Multi-line text input	No
`<select>`	Dropdown	No
`<option>`	Dropdown option	No
`<button>`	Button	No
`<label>`	Label for form field	No
`<br>`	Line break	✅ Yes
`<hr>`	Horizontal rule (line)	✅ Yes
`<header>`	Page/section header	No
`<nav>`	Navigation	No
`<main>`	Main content	No
`<section>`	Content section	No
`<article>`	Self-contained content	No
`<footer>`	Page/section footer	No
`<figure>`	Media container	No
`<figcaption>`	Caption for figure	No

Now let's build the Airbnb listing page! →

Phase 1 Airbnb Listing Project in HTML Walkthrough

What was built

A complete Airbnb-style property listing page using only HTML — no CSS, no JavaScript, no backend. The page is intentionally "ugly" because styling is Phase 2's job.

Project location

[index.html]

<!DOCTYPE html>
<!--
    DOCTYPE tells the browser: "This is an HTML5 document."
    Always put this on the very first line.
-->

<html lang="en">
<!--
    <html> is the ROOT element — everything lives inside it.
    lang="en" tells browsers and screen readers the language is English.
-->

<head>
    <!--
        <head> contains INVISIBLE information about the page.
        Nothing here shows up on the screen.
    -->

    <meta charset="UTF-8" />
    <!--
        charset="UTF-8" allows the page to display characters from
        any language, including ₹ (rupee symbol), é, ñ, 中文, etc.
        Without this, special characters might show as garbage: â‚¹
    -->

    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <!--
        This makes the page look good on mobile phones.
        Without it, the page would appear tiny on a phone screen.
    -->

    <title>Beautiful Apartment in Ahmedabad — Airbnb</title>
    <!--
        <title> sets the text on the browser tab.
        Also what Google shows as the page title in search results.
    -->
</head>


<body>
    <!--
        <body> contains EVERYTHING the user sees on the page.
        This is where all our content goes.
    -->


    <!-- ============================================ -->
    <!--                  HEADER                       -->
    <!-- ============================================ -->
    <header>
        <!--
            <header> is a SEMANTIC tag — it tells the browser
            "this is the top section of the page" (logo, nav, etc.)
            We could use <div> instead, but <header> is more meaningful.
        -->

        <h1>Airbnb</h1>
        <!--
            <h1> = the MOST IMPORTANT heading on the page.
            Rule: Only ONE <h1> per page.
            Here it's the brand name / logo text.
        -->

        <nav>
            <!--
                <nav> = SEMANTIC tag for navigation links.
                Tells screen readers "these are navigation links."
            -->
            <a href="#listing">Listing</a>
            <!--
                <a> = Anchor tag = a LINK.
                href="#listing" means "scroll to the element with id='listing' on this page."
                The # means "look on THIS page" (not another website).
            -->
            <span> | </span>
            <!--
                <span> is an INLINE container. We're using it here just
                to add a separator "|" between the nav links.
                It doesn't start a new line (unlike <div>).
            -->
            <a href="#amenities">Amenities</a>
            <span> | </span>
            <a href="#reviews">Reviews</a>
            <span> | </span>
            <a href="#reserve">Reserve</a>
        </nav>
    </header>


    <hr />
    <!--
        <hr> = Horizontal Rule = a dividing line.
        It's self-closing (no </hr> needed).
        Visually separates sections of content.
    -->


    <!-- ============================================ -->
    <!--                MAIN CONTENT                   -->
    <!-- ============================================ -->
    <main>
        <!--
            <main> = SEMANTIC tag for the primary content of the page.
            There should be only ONE <main> per page.
        -->


        <!-- ====== LISTING SECTION ====== -->
        <section id="listing">
            <!--
                <section> = SEMANTIC tag for a thematic group of content.
                id="listing" gives this section a UNIQUE identifier.
                The nav link href="#listing" scrolls to THIS section.

                Remember: 'id' must be UNIQUE on the entire page.
            -->

            <h2>Beautiful Apartment in Ahmedabad</h2>
            <!--
                <h2> = Second-level heading.
                This is the property title. Under the page's <h1>, so h2 is correct.
            -->

            <p>
                <!--
                    <p> = Paragraph.
                    Contains a brief location/host description.
                -->
                <span>⭐ 4.9</span>
                <!--
                    <span> wraps the rating inline (doesn't break to a new line).
                    Later with CSS, we could style this differently.
                -->
                <span> · </span>
                <a href="#reviews">128 reviews</a>
                <span> · </span>
                <span>Ahmedabad, Gujarat, India</span>
            </p>
        </section>


        <hr />


        <!-- ====== PROPERTY IMAGE ====== -->
        <section id="photos">
            <h2>Photos</h2>

            <figure>
                <!--
                    <figure> = SEMANTIC tag for media content (image, diagram, etc.)
                    with an optional caption. Better than a plain <div>.
                -->

                <img
                    src="https://images.unsplash.com/photo-1522708323590-d24dbb6b0267?w=800"
                    alt="Spacious living room with modern furniture, large windows letting in natural light, and a comfortable sofa"
                    width="700"
                />
                <!--
                    <img> = Image tag. Self-closing.

                    src = Source of the image. Can be:
                        - A local file:  src="images/photo.jpg"
                        - A URL:         src="https://example.com/photo.jpg"

                    alt = Alternative text. VERY IMPORTANT:
                        - Displayed if the image fails to load
                        - Read aloud by screen readers for blind users
                        - Helps Google understand your images (SEO)
                        - Should DESCRIBE the image, not just say "photo"

                    width = Width in pixels. We set 700 to keep it reasonable.
                -->

                <figcaption>
                    Living room — bright and spacious with modern decor
                </figcaption>
                <!--
                    <figcaption> = Caption for the <figure>.
                    Displayed below the image as descriptive text.
                -->
            </figure>

            <br />

            <figure>
                <img
                    src="https://images.unsplash.com/photo-1540518614846-7eded433c457?w=800"
                    alt="Cozy bedroom with a king-size bed, white linens, and warm lighting"
                    width="700"
                />
                <figcaption>
                    Master bedroom — king-size bed with premium linens
                </figcaption>
            </figure>
        </section>


        <hr />


        <!-- ====== PROPERTY DETAILS ====== -->
        <section id="details">
            <h2>Property Details</h2>

            <p>
                Entire apartment hosted by <strong>Yash</strong>
                <!--
                    <strong> = SEMANTIC tag meaning "strong importance."
                    Browsers display it as bold.
                    Don't use <b> — <strong> carries meaning, <b> is just visual.
                -->
            </p>

            <p>
                2 bedrooms · 1 bathroom · 4 guests · 1 bed
            </p>

            <p>
                <em>Self check-in with lockbox</em>
                <!--
                    <em> = SEMANTIC tag meaning "emphasis."
                    Browsers display it as italic.
                    Don't use <i> — <em> carries meaning, <i> is just visual.
                -->
            </p>
        </section>


        <hr />


        <!-- ====== DESCRIPTION ====== -->
        <section id="description">
            <h2>About This Place</h2>

            <p>
                Welcome to our beautiful apartment in the heart of Ahmedabad!
                This spacious 2-bedroom apartment is perfect for families,
                couples, or business travelers looking for a comfortable stay.
            </p>

            <p>
                Located just 10 minutes from Sabarmati Ashram and walking
                distance to the famous Law Garden night market, you'll have
                the best of Ahmedabad at your doorstep.
            </p>

            <p>
                The apartment features modern amenities, a fully equipped
                kitchen, high-speed WiFi, and a stunning city view from
                the balcony.
            </p>
        </section>


        <hr />


        <!-- ====== PRICE ====== -->
        <section id="pricing">
            <h2>Pricing</h2>

            <table>
                <!--
                    <table> = Creates a table with rows and columns.
                    Use tables ONLY for tabular data, never for page layout.
                -->

                <thead>
                    <!--
                        <thead> = Table Header group.
                        Contains the column headings.
                    -->
                    <tr>
                        <!--
                            <tr> = Table Row.
                            Each <tr> is one horizontal row.
                        -->
                        <th>Item</th>
                        <!--
                            <th> = Table Header cell.
                            Displayed bold and centered by default.
                        -->
                        <th>Price</th>
                    </tr>
                </thead>

                <tbody>
                    <!--
                        <tbody> = Table Body group.
                        Contains the data rows.
                    -->
                    <tr>
                        <td>Per night</td>
                        <!--
                            <td> = Table Data cell.
                            A regular cell containing data.
                        -->
                        <td>₹3,000</td>
                    </tr>
                    <tr>
                        <td>Cleaning fee</td>
                        <td>₹500</td>
                    </tr>
                    <tr>
                        <td>Service fee</td>
                        <td>₹400</td>
                    </tr>
                    <tr>
                        <th>Total (1 night)</th>
                        <!--
                            Using <th> here to make the total row bold,
                            since it's a summary/header-like cell.
                        -->
                        <th>₹3,900</th>
                    </tr>
                </tbody>
            </table>
        </section>


        <hr />


        <!-- ====== AMENITIES ====== -->
        <section id="amenities">
            <h2>Amenities</h2>

            <h3>Essentials</h3>
            <ul>
                <!--
                    <ul> = Unordered List (bullet points).
                    Each item inside is an <li> (List Item).
                -->
                <li>WiFi</li>
                <li>Air conditioning</li>
                <li>Heating</li>
                <li>Iron</li>
                <li>Hair dryer</li>
            </ul>

            <h3>Kitchen &amp; Dining</h3>
            <!--
                &amp; is an HTML ENTITY for the & symbol.
                Some characters have special meaning in HTML, so we use entities:
                    &amp;   = &
                    &lt;    = <
                    &gt;    = >
                    &quot;  = "
                    &copy;  = ©
            -->
            <ul>
                <li>Full kitchen</li>
                <li>Refrigerator</li>
                <li>Microwave</li>
                <li>Coffee maker</li>
                <li>Dishes and silverware</li>
            </ul>

            <h3>Safety</h3>
            <ul>
                <li>Smoke detector</li>
                <li>Fire extinguisher</li>
                <li>First aid kit</li>
            </ul>

            <h3>Not Available</h3>
            <ul>
                <li><s>Swimming pool</s></li>
                <li><s>Gym</s></li>
                <!--
                    <s> = Strikethrough text.
                    Shows that these amenities are NOT available.
                -->
            </ul>
        </section>


        <hr />


        <!-- ====== HOUSE RULES ====== -->
        <section id="rules">
            <h2>House Rules</h2>

            <ol>
                <!--
                    <ol> = Ordered List (numbered).
                    The browser automatically numbers each <li>.
                -->
                <li>Check-in: After 2:00 PM</li>
                <li>Checkout: Before 11:00 AM</li>
                <li>No smoking inside the apartment</li>
                <li>No parties or loud music after 10:00 PM</li>
                <li>Maximum 4 guests allowed</li>
                <li>Pets are <strong>not</strong> allowed</li>
            </ol>
        </section>


        <hr />


        <!-- ====== REVIEWS ====== -->
        <section id="reviews">
            <h2>Reviews</h2>
            <p>⭐ 4.9 average · 128 reviews</p>

            <article>
                <!--
                    <article> = SEMANTIC tag for self-contained content.
                    Each review is an independent piece of content — perfect for <article>.
                -->
                <h3>Priya</h3>
                <p><em>September 2026</em></p>
                <p>
                    Amazing apartment! Super clean, great location, and Yash was
                    a wonderful host. The kitchen was fully equipped — we cooked
                    every day. Highly recommend!
                </p>
            </article>

            <article>
                <h3>Rahul</h3>
                <p><em>August 2026</em></p>
                <p>
                    Perfect for our family trip to Ahmedabad. The kids loved the
                    spacious living room. WiFi was fast and reliable. Only
                    suggestion: a few more pillows would be nice.
                </p>
            </article>

            <article>
                <h3>Ananya</h3>
                <p><em>July 2026</em></p>
                <p>
                    Stayed here for a week for work. The location is unbeatable —
                    close to restaurants and transport. The apartment felt like
                    home. Will definitely book again!
                </p>
            </article>
        </section>


        <hr />


        <!-- ====== LOCATION ====== -->
        <section id="location">
            <h2>Location</h2>
            <p>
                <strong>Ahmedabad, Gujarat, India</strong>
            </p>
            <p>
                Navrangpura area — one of the most vibrant neighborhoods
                in Ahmedabad. Walking distance to:
            </p>
            <ul>
                <li>Law Garden Night Market — 5 min walk</li>
                <li>Sabarmati Ashram — 10 min drive</li>
                <li>Sardar Vallabhbhai Patel International Airport — 25 min drive</li>
                <li>Ahmedabad Railway Station — 15 min drive</li>
            </ul>
        </section>


        <hr />


        <!-- ============================================ -->
        <!--            RESERVATION FORM                   -->
        <!-- ============================================ -->
        <section id="reserve">
            <h2>Reserve This Property</h2>

            <p><strong>₹3,000</strong> / night</p>

            <form action="/submit-reservation" method="POST">
                <!--
                    <form> = Container for all form fields.

                    action="/submit-reservation"
                        Where to send the data when submitted.
                        Since we have no backend, this will just reload the page.

                    method="POST"
                        HOW to send the data:
                        - GET  = data goes in the URL (visible)
                        - POST = data goes in the request body (hidden)
                        For forms that send sensitive data, always use POST.
                -->


                <!-- NAME FIELD -->
                <div>
                    <!--
                        Wrapping each label+input pair in a <div> puts each
                        field on its own line (since <div> is a block element).
                    -->

                    <label for="fullname">Full Name:</label>
                    <!--
                        <label> tells the user what to type.
                        for="fullname" LINKS this label to the input with id="fullname".
                        Benefit: clicking the label focuses the input field.
                    -->

                    <br />

                    <input
                        type="text"
                        id="fullname"
                        name="fullname"
                        placeholder="Enter your full name"
                        required
                    />
                    <!--
                        <input> = Self-closing. No </input> needed.

                        type="text"     → A single-line text box
                        id="fullname"   → UNIQUE identifier (connects to the label's 'for')
                        name="fullname" → The KEY when data is sent to server
                                          Server receives: fullname=Yash+Verma
                        placeholder     → Gray hint text shown when field is empty
                        required        → Form won't submit if this is empty
                                          (this is an attribute with NO value — just its presence matters)
                    -->
                </div>

                <br />


                <!-- EMAIL FIELD -->
                <div>
                    <label for="email">Email Address:</label>
                    <br />
                    <input
                        type="email"
                        id="email"
                        name="email"
                        placeholder="you@example.com"
                        required
                    />
                    <!--
                        type="email" → Browser validates that it looks like an email.
                        If you type "abc" and hit submit, it'll say "enter a valid email."
                    -->
                </div>

                <br />


                <!-- PHONE FIELD -->
                <div>
                    <label for="phone">Phone Number:</label>
                    <br />
                    <input
                        type="tel"
                        id="phone"
                        name="phone"
                        placeholder="+91 98765 43210"
                    />
                    <!--
                        type="tel" → On mobile phones, this opens the NUMBER keyboard
                        instead of the full keyboard. Nice UX touch!
                        Not marked 'required' — it's optional.
                    -->
                </div>

                <br />


                <!-- CHECK-IN DATE -->
                <div>
                    <label for="checkin">Check-in Date:</label>
                    <br />
                    <input
                        type="date"
                        id="checkin"
                        name="checkin"
                        required
                    />
                    <!--
                        type="date" → Shows a date picker calendar!
                        No JavaScript needed — the browser provides it.
                    -->
                </div>

                <br />


                <!-- CHECK-OUT DATE -->
                <div>
                    <label for="checkout">Check-out Date:</label>
                    <br />
                    <input
                        type="date"
                        id="checkout"
                        name="checkout"
                        required
                    />
                </div>

                <br />


                <!-- NUMBER OF GUESTS -->
                <div>
                    <label for="guests">Number of Guests:</label>
                    <br />
                    <select id="guests" name="guests" required>
                        <!--
                            <select> = Dropdown menu.
                            Each <option> is one choice in the dropdown.
                        -->
                        <option value="">-- Select --</option>
                        <!--
                            value="" with required means this "placeholder" option
                            won't be accepted — the user must pick a real option.
                        -->
                        <option value="1">1 Guest</option>
                        <option value="2">2 Guests</option>
                        <option value="3">3 Guests</option>
                        <option value="4">4 Guests</option>
                    </select>
                </div>

                <br />


                <!-- PROPERTY TYPE — RADIO BUTTONS -->
                <div>
                    <p><strong>Booking Type:</strong></p>

                    <input type="radio" id="entire" name="booking_type" value="entire" checked />
                    <label for="entire">Entire place</label>
                    <!--
                        type="radio" → Round buttons where you can pick ONLY ONE.
                        All radio buttons with the SAME 'name' form a group.
                        Here all 3 have name="booking_type", so only one can be selected.

                        checked → This option is selected by default.

                        id="entire" connects to the <label for="entire">,
                        so clicking "Entire place" text also selects the radio button.
                    -->

                    <br />

                    <input type="radio" id="private" name="booking_type" value="private" />
                    <label for="private">Private room</label>

                    <br />

                    <input type="radio" id="shared" name="booking_type" value="shared" />
                    <label for="shared">Shared room</label>
                </div>

                <br />


                <!-- ADD-ONS — CHECKBOXES -->
                <div>
                    <p><strong>Add-ons:</strong></p>

                    <input type="checkbox" id="airport" name="addons" value="airport_pickup" />
                    <label for="airport">Airport pickup (₹800)</label>
                    <!--
                        type="checkbox" → Square boxes. Can select MULTIPLE.
                        Unlike radio buttons, checkboxes are independent.
                    -->

                    <br />

                    <input type="checkbox" id="breakfast" name="addons" value="breakfast" />
                    <label for="breakfast">Daily breakfast (₹300/day)</label>

                    <br />

                    <input type="checkbox" id="tour" name="addons" value="city_tour" />
                    <label for="tour">Guided city tour (₹1,500)</label>
                </div>

                <br />


                <!-- SPECIAL REQUESTS — TEXTAREA -->
                <div>
                    <label for="requests">Special Requests:</label>
                    <br />
                    <textarea
                        id="requests"
                        name="requests"
                        rows="4"
                        cols="50"
                        placeholder="Any special requirements? (e.g., early check-in, extra pillows, dietary needs)"
                    ></textarea>
                    <!--
                        <textarea> = Multi-line text input.
                        Unlike <input>, this is NOT self-closing — it needs </textarea>.

                        rows="4"  → Height (4 lines tall)
                        cols="50" → Width (50 characters wide)

                        NOTE: The closing tag must come RIGHT AFTER the opening tag
                        (no space/newline) if you don't want default text inside.
                    -->
                </div>

                <br />


                <!-- TERMS CHECKBOX -->
                <div>
                    <input type="checkbox" id="terms" name="terms" value="agreed" required />
                    <label for="terms">
                        I agree to the
                        <a href="https://www.airbnb.com/terms" target="_blank">Terms of Service</a>
                    </label>
                    <!--
                        required on a checkbox = user MUST check this box to submit.
                        Perfect for "agree to terms" checkboxes.

                        target="_blank" on the link = opens in a new tab,
                        so the user doesn't lose their form progress.
                    -->
                </div>

                <br />


                <!-- SUBMIT & RESET BUTTONS -->
                <div>
                    <button type="submit">Reserve Now</button>
                    <!--
                        type="submit" → Clicking this sends the form data.
                        The browser validates all 'required' fields first.
                    -->

                    <button type="reset">Clear Form</button>
                    <!--
                        type="reset" → Clicking this clears all form fields
                        back to their default values.
                    -->
                </div>
            </form>
        </section>


        <hr />


        <!-- ====== HOST INFO ====== -->
        <section id="host">
            <h2>Meet Your Host</h2>

            <p><strong>Hosted by Yash</strong></p>
            <p>Joined in January 2024</p>

            <ul>
                <li>⭐ 128 Reviews</li>
                <li>🏅 Superhost</li>
                <li>✅ Identity verified</li>
            </ul>

            <p>
                Hi! I'm Yash, a software developer based in Ahmedabad.
                I love hosting guests and sharing the beauty of Gujarat.
                I'm available 24/7 for any questions during your stay!
            </p>

            <p>
                <strong>Response rate:</strong> 100%
                <br />
                <strong>Response time:</strong> within an hour
            </p>

            <p>
                <a href="mailto:yash@example.com">Contact Host</a>
                <!--
                    mailto: is a special URL scheme.
                    Clicking this opens the user's email app with
                    yash@example.com pre-filled in the "To" field.
                -->
            </p>
        </section>

    </main>


    <hr />


    <!-- ============================================ -->
    <!--                  FOOTER                       -->
    <!-- ============================================ -->
    <footer>
        <!--
            <footer> = SEMANTIC tag for the bottom section of the page.
            Usually contains copyright, links, and legal info.
        -->

        <p>
            &copy; 2026 Airbnb Clone — Practice Project
            <!--
                &copy; = © (copyright symbol). It's an HTML entity.
            -->
        </p>

        <nav>
            <a href="#listing">Back to Top</a>
            <span> | </span>
            <a href="https://www.airbnb.com" target="_blank">Real Airbnb</a>
            <span> | </span>
            <a href="mailto:yash@example.com">Contact</a>
        </nav>

        <p>
            <small>
                This is a practice project for learning HTML.
                Not affiliated with Airbnb, Inc.
            </small>
            <!--
                <small> = Text in a smaller font size.
                Often used for disclaimers, fine print, copyright.
            -->
        </p>
    </footer>

</body>
</html>

Page Structure — Section by Section

┌──────────────────────────────────────┐
│  HEADER                              │  <header>, <h1>, <nav>, <a>
│  Airbnb logo + navigation links      │
├──────────────────────────────────────┤
│  LISTING                             │  <section>, <h2>, <p>, <span>, <a>
│  Title + rating + location            │
├──────────────────────────────────────┤
│  PHOTOS                              │  <section>, <figure>, <img>, <figcaption>
│  Property images with captions        │
├──────────────────────────────────────┤
│  DETAILS                             │  <section>, <h2>, <p>, <strong>, <em>
│  Bedrooms, bathrooms, guests          │
├──────────────────────────────────────┤
│  DESCRIPTION                         │  <section>, <h2>, <p>
│  About the property                   │
├──────────────────────────────────────┤
│  PRICING                             │  <table>, <thead>, <tbody>, <tr>, <th>, <td>
│  Price breakdown table                │
├──────────────────────────────────────┤
│  AMENITIES                           │  <h3>, <ul>, <li>, <s>
│  Feature lists (essentials, kitchen)  │
├──────────────────────────────────────┤
│  HOUSE RULES                         │  <ol>, <li>, <strong>
│  Numbered rules list                  │
├──────────────────────────────────────┤
│  REVIEWS                             │  <article>, <h3>, <p>, <em>
│  Guest reviews                        │
├──────────────────────────────────────┤
│  LOCATION                            │  <section>, <ul>, <li>
│  Nearby landmarks                     │
├──────────────────────────────────────┤
│  RESERVATION FORM                    │  <form>, <label>, <input>, <select>,
│  Full booking form                    │  <option>, <textarea>, <button>,
│                                       │  radio, checkbox, date picker
├──────────────────────────────────────┤
│  HOST INFO                           │  <section>, <ul>, <li>, <a href="mailto:">
│  Host profile                         │
├──────────────────────────────────────┤
│  FOOTER                              │  <footer>, <nav>, <small>, &copy;
│  Copyright + links                    │
└──────────────────────────────────────┘

Every Concept → Where It's Used

Concept	Tags Used	Where in the Page
Page structure	`html`, `head`, `body`	The skeleton wrapping everything
Headings	`h1`, `h2`, `h3`	Airbnb title (h1), section titles (h2), amenity groups (h3)
Paragraphs	`p`	Descriptions, details, host info
Div	`div`	Wrapping each form field pair
Span	`span`	Rating star, separator dots, inline pieces
Links	`a`	Nav links, review link, mailto link, terms link
Images	`img`	Two property photos (from Unsplash)
Unordered list	`ul`, `li`	Amenities, host badges, nearby locations
Ordered list	`ol`, `li`	House rules (numbered)
Table	`table`, `thead`, `tbody`, `tr`, `th`, `td`	Pricing breakdown
Form	`form`	Reservation form
Input types	`text`, `email`, `tel`, `date`, `radio`, `checkbox`	Name, email, phone, dates, booking type, add-ons
Textarea	`textarea`	Special requests
Select/dropdown	`select`, `option`	Number of guests
Button	`button`	Reserve Now, Clear Form
Label	`label`	Every form field has a connected label
Attributes	`id`, `class`, `href`, `src`, `alt`, `required`, `placeholder`, `for`, `name`, `value`, `type`, `target`	Used throughout
Semantic HTML	`header`, `nav`, `main`, `section`, `article`, `footer`, `figure`, `figcaption`	Page structure
HTML entities	`©`, `&`	Copyright symbol, ampersand
Special links	`href="#id"`, `href="mailto:"`	In-page scrolling, email link

🧪 Practice Challenges — Try These Yourself

Now that you've seen the full page, modify it to practice. Open the file in a text editor and try these(Will try to Ans in comment or edit this blog later):

Easy

[ ] Change the property title to your own
[ ] Change the price from ₹3,000 to ₹5,000
[ ] Add a 3rd photo using any image URL from Unsplash
[ ] Add 2 more amenities to the list
[ ] Change the host name to yours

Medium

[ ] Add a new review (copy the <article> pattern)
[ ] Add a new house rule to the ordered list
[ ] Add a new column to the pricing table ("Per Week" pricing)
[ ] Add a type="number" input for "Number of Nights" in the form
[ ] Create a new section: "What guests are saying" with a quote

Challenge

[ ] Create a second HTML page called about.html with info about the host
[ ] Add a link in index.html to navigate to about.html and vice versa
[ ] Add a <table> comparing this apartment with a competing listing
[ ] Create a contact form page (contact.html) with name, email, subject, and message fields

[!TIP]
How to edit: Open index.html in any text editor (Notepad, VS Code, etc.), make changes, save the file, and refresh the browser. That's the full workflow!

What This Page is Missing (On Purpose)

Missing	Why	When you'll learn it
No styling (looks ugly)	CSS hasn't been learned yet	Phase 2 — CSS
No interactivity	JavaScript hasn't been learned yet	Phase 3 — JavaScript
Form doesn't actually submit	No backend server	Phase 4+ — Backend
No real data	No database	Phase 5+ — Database
Images from internet	No image hosting set up	Later

[!IMPORTANT]
The page looks plain and ugly. That's a SUCCESS. You built a complete, well-structured HTML document with correct semantic tags. The visual design comes in Phase 2 (CSS). Never use HTML to try to make things look pretty — that's CSS's job.

✅ Phase 1 Checklist — Can You...

[ ] Create an HTML file from scratch with the correct structure?
[ ] Use headings (h1–h6) with proper hierarchy?
[ ] Add paragraphs, links, and images?
[ ] Build ordered and unordered lists?
[ ] Create a table with headers and data?
[ ] Build a form with text inputs, dropdowns, radio buttons, checkboxes, and a submit button?
[ ] Connect <label> to <input> using for and id?
[ ] Explain the difference between id and class?
[ ] Use semantic tags (header, main, section, article, footer) instead of div everywhere?

Phase 0 Understanding how websites work

Yashvi Kothari — Thu, 17 Sep 2026 08:42:41 +0000

Phase 0 Understand how websites work
Before writing code, understand these concepts.
Learn:
What is a website?
Browser vs server
Frontend vs backend
Database
HTTP
Request
Response
URL
Domain
IP address
HTTP vs HTTPS
GET vs POST
Client-server architecture
You should be able to understand:
You
↓
Chrome
↓
Internet
↓
Server
↓
Application
↓
Database
↓
Server
↓
Chrome
↓
You

Practice
Open browser DevTools → Network tab.
Visit a website and observe:
Request
Response
Status Code
Method
URL
Headers
Response
Don't worry about understanding everything yet.

Phase 0 — How Websites Work

[!NOTE]
You don't need to memorize any of this. Read it, understand the big picture, and come back as a reference. Everything will become clearer once you start writing code.

1. What is a Website?

A website is a collection of files (text, images, code) stored on a computer somewhere in the world. When you "visit" a website, your browser downloads those files and displays them on your screen.

Think of it like a restaurant:

Restaurant	Website
You (the customer)	You (the user)
The menu you see	The webpage you see (HTML, CSS)
The kitchen	The server
The recipe book	The application code
The pantry/fridge	The database
The waiter	HTTP (the protocol carrying requests & responses)

Key takeaway: A website isn't a single magical thing — it's files on someone else's computer, delivered to your computer over the internet.

2. Browser vs Server

Browser (Client)

The browser is the app on your device — Chrome, Firefox, Edge, Safari. Its job is to:

Send requests — "Hey, give me google.com"
Receive files — HTML, CSS, JavaScript, images
Render (display) those files as a visual webpage

The browser is also called the client — the one asking for something.

Server

A server is a computer (usually in a data center) that is always on and always connected to the internet, waiting to respond to requests.

Its job is to:

Listen for incoming requests
Process the request (look up data, run logic)
Send back a response (usually an HTML page, JSON data, or files)

Real-world analogy:

Browser = You calling a pizza shop on the phone
Server = The pizza shop answering the phone, making your pizza, and delivering it

[!TIP]
Your own laptop can act as a server! When you learn backend development, you'll run a "local server" on your machine. It's just a program that listens and responds.

3. Frontend vs Backend

Frontend (Client-Side)

Everything the user sees and interacts with in the browser:

The layout of the page (HTML)
The colors, fonts, spacing (CSS)
Buttons that do things, animations, pop-ups (JavaScript)

Technologies: HTML, CSS, JavaScript, React, Angular, Vue

Analogy: The dining area of a restaurant — what customers see.

Backend (Server-Side)

Everything that happens behind the scenes on the server:

Processing login credentials
Fetching your order history from a database
Sending emails
Payment processing

Technologies: Node.js, Python (Django/Flask), Java, Go, PHP, Ruby

Analogy: The kitchen of a restaurant — customers can't see it, but that's where the real work happens.

How They Connect

┌──────────────┐         ┌──────────────┐         ┌──────────────┐
│   FRONTEND   │  ────►  │   BACKEND    │  ────►  │   DATABASE   │
│  (Browser)   │  ◄────  │   (Server)   │  ◄────  │  (Storage)   │
│              │         │              │         │              │
│ HTML/CSS/JS  │         │ Node/Python  │         │ MySQL/Mongo  │
│ What you SEE │         │ Logic/Rules  │         │ Where data   │
│              │         │              │         │ LIVES        │
└──────────────┘         └──────────────┘         └──────────────┘

4. Database

A database is organized storage for data. Think of it as a super-powered Excel spreadsheet.

When you sign up on Instagram:

Your username, email, password → stored in a database
Your posts, likes, followers → stored in a database
When you log in → the server reads from the database to check your password

Types of Databases

Type	Examples	Data looks like...
Relational (SQL)	MySQL, PostgreSQL	Tables with rows & columns (like Excel)
Non-Relational (NoSQL)	MongoDB, Firebase	Flexible documents (like JSON files)

Example — A "users" table in SQL:

id	username	email	password_hash
1	yash123	yash@email.com	a1b2c3...
2	priya456	priya@email.com	d4e5f6...

[!NOTE]
You don't need to learn databases right now. Just understand: data has to live somewhere, and that somewhere is the database.

5. HTTP — The Language of the Web

HTTP = Hyper Text Transfer Protocol

It's the set of rules that browsers and servers use to talk to each other. Think of it as the language the waiter speaks.

Every time you visit a website, your browser speaks HTTP to the server.

6. Request

A request is what your browser sends to the server when you want something.

When you type https://www.google.com and hit Enter, your browser sends an HTTP request that looks roughly like this:

GET / HTTP/1.1
Host: www.google.com
User-Agent: Chrome/120
Accept: text/html

Breaking it down:

Part	Meaning
`GET`	The method — "I want to GET (read) something"
`/`	The path — "Give me the homepage"
`HTTP/1.1`	The version of HTTP
`Host: www.google.com`	Which server to talk to
`User-Agent: Chrome/120`	"I'm using Chrome"
`Accept: text/html`	"I want HTML back"

7. Response

A response is what the server sends back to your browser.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 14523

<!DOCTYPE html>
<html>
  <head><title>Google</title></head>
  <body>... the Google homepage ...</body>
</html>

Breaking it down:

Part	Meaning
`200 OK`	Status code — "Everything went well, here's your page"
`Content-Type: text/html`	"I'm sending you an HTML file"
`<html>...`	The actual content (the webpage)

Common Status Codes

Code	Meaning	When you see it
200	✅ OK	Page loaded successfully
301	↪️ Moved Permanently	Website redirected you
404	❌ Not Found	Page doesn't exist
500	💥 Internal Server Error	Server crashed or has a bug
403	🚫 Forbidden	You don't have permission

8. URL — The Address of a Webpage

URL = Uniform Resource Locator — it's the address that tells the browser exactly where to go.

https://www.example.com:443/products/shoes?color=red&size=10#reviews
  │        │              │       │              │              │
  │        │              │       │              │              └─ Fragment (scroll to this section)
  │        │              │       │              └─ Query params (filters/search)
  │        │              │       └─ Path (which page)
  │        │              └─ Port (which door on the server)
  │        └─ Domain (which server)
  └─ Protocol (how to communicate)

Part	Example	Purpose
Protocol	`https://`	How to talk (securely)
Domain	`www.example.com`	Which server to contact
Port	`:443`	Which "door" (usually hidden)
Path	`/products/shoes`	Which specific page
Query	`?color=red&size=10`	Extra info / filters
Fragment	`#reviews`	Scroll to a section on the page

9. Domain & IP Address

IP Address

Every computer on the internet has a unique IP address — a number like 142.250.190.46. This is the real address of a server.

Domain Name

Since nobody wants to remember 142.250.190.46, we use domain names like google.com as human-friendly aliases.

DNS — The Phonebook of the Internet

DNS (Domain Name System) translates domain names to IP addresses:

You type: google.com
     ↓
DNS lookup: "google.com → 142.250.190.46"
     ↓
Browser connects to: 142.250.190.46

Analogy:

IP address = A house's GPS coordinates (27.1751, 78.0421)
Domain name = The house's street address ("Taj Mahal, Agra")
DNS = Google Maps converting the address to coordinates

10. HTTP vs HTTPS

	HTTP	HTTPS
Full form	HyperText Transfer Protocol	HyperText Transfer Protocol Secure
Encryption	❌ None — data sent as plain text	✅ Encrypted with SSL/TLS
Security	Anyone on the network can read your data	Data is scrambled, unreadable to snoopers
Port	80	443
URL	`http://...`	`https://...`
Use today	Almost never (browsers warn you)	Everywhere — the standard

Why it matters:
If you log into a website over HTTP, someone on the same Wi-Fi can literally read your password. With HTTPS, everything is encrypted.

[!CAUTION]
Never enter passwords or credit cards on a site that shows http:// (no 's'). Modern browsers show a "Not Secure" warning for these sites.

11. GET vs POST

These are the two most common HTTP methods — they tell the server what kind of action you want.

GET — "Give me something"

Purpose: Read / retrieve data
When it happens: Loading a page, searching, clicking a link
Data location: In the URL (visible) → ?q=cats&page=2
Safe to repeat? Yes — nothing changes on the server

Examples:

Visiting google.com → GET
Searching google.com/search?q=cats → GET
Loading your Twitter feed → GET

POST — "Here, take this data"

Purpose: Send / submit data to the server
When it happens: Submitting a form, logging in, uploading a file
Data location: In the request body (hidden from URL)
Safe to repeat? No — might create duplicates (e.g., double purchase)

Examples:

Submitting a signup form → POST
Posting a tweet → POST
Uploading a photo → POST

Comparison Table

	GET	POST
Purpose	Read data	Send/create data
Data in URL?	✅ Yes (visible)	❌ No (in body)
Cacheable?	✅ Yes	❌ No
Bookmarkable?	✅ Yes	❌ No
Can be repeated safely?	✅ Yes	❌ No
Example	Loading a page	Submitting a form

[!TIP]
There are other methods too — PUT (update), DELETE (remove), PATCH (partial update). You'll learn these when building APIs. For now, just know GET and POST.

12. Client-Server Architecture

This is the fundamental pattern of how the web works:

  ┌─────────┐                              ┌─────────┐
  │ CLIENT  │  ──── Request ──────────►    │ SERVER  │
  │(Browser)│  ◄─── Response ────────────  │         │
  └─────────┘                              └─────────┘

The client (your browser) initiates communication by sending a request
The server processes the request and sends back a response
The server never contacts you first (in basic HTTP) — it only responds

This is like a restaurant:

You (client) call the waiter and place an order (request)
The kitchen (server) prepares the food and the waiter brings it back (response)
The kitchen never randomly walks up to your table with food you didn't order

13. The Full Journey — Step by Step

This is the flow you need to understand. Let's trace what happens when you open Instagram:

 YOU                    "I want to see Instagram"
  ↓
 CHROME (Browser)       Types instagram.com, hits Enter
  ↓
 DNS                    Converts "instagram.com" → 157.240.1.174
  ↓
 INTERNET               Your request travels through cables/wifi
  ↓
 SERVER                  Instagram's server receives your request
  ↓
 APPLICATION             Instagram's code runs:
                         "This user is logged in, fetch their feed"
  ↓
 DATABASE                Queries: "Get latest 20 posts from
                         people this user follows"
  ↓
 APPLICATION             Formats the data into an HTML page / JSON
  ↓
 SERVER                  Sends the response back
  ↓
 INTERNET                Response travels back through cables/wifi
  ↓
 CHROME (Browser)        Receives HTML/CSS/JS, renders the page
  ↓
 YOU                     See your Instagram feed! 🎉

Timing

This entire journey happens in ~200-500 milliseconds (less than half a second). That's how fast the internet is.

14. 🧪 Practice Exercise — Using Browser DevTools

This is your first hands-on practice. No coding needed — just observation.

Step 1: Open DevTools

Open Chrome (or any browser)
Press F12 or Ctrl + Shift + I (Windows) / Cmd + Option + I (Mac)
Click the "Network" tab at the top

Step 2: Visit a Website

Make sure the Network tab is open and recording (there should be a red circle ● at the top-left)
Type https://httpbin.org/get in the address bar and hit Enter
You'll see lines appear in the Network tab — each line is one request

Step 3: Observe the First Request

Click on the first item in the list (usually named get).

You'll see panels showing:

✅ What to look for:

What	Where to find it	Example value
URL	In the "Headers" section → Request URL	`https://httpbin.org/get`
Method	In the "Headers" section	`GET`
Status Code	In the "Headers" section	`200 OK`
Response Headers	In the "Headers" section → Response Headers	`Content-Type: application/json`
Response Body	Click the "Response" or "Preview" tab	JSON data

Step 4: Try a POST Request

Open a new tab
Open DevTools (F12) → Network tab
Paste this into the address bar: https://httpbin.org/post
You'll get an error (because browsers send GET by default) — that's expected!
This tells you: the server only accepts POST at this URL, but your browser sent GET

Step 5: Observe Multiple Requests

Go to https://www.google.com with DevTools Network tab open
Notice there are dozens of requests — not just one!
Each image, CSS file, JavaScript file, and font is a separate request

[!IMPORTANT]
A single webpage often makes 30-100+ HTTP requests to load completely. The HTML is just the skeleton — it then triggers requests for all the images, styles, and scripts.

Step 6: Status Codes in Action

Try visiting these URLs and check the status code in DevTools:

https://httpbin.org/status/200 → Should show 200 (OK)
https://httpbin.org/status/404 → Should show 404 (Not Found)
https://httpbin.org/status/500 → Should show 500 (Server Error)

15. Summary Cheat Sheet

Concept	One-Line Summary
Website	Files on a server, displayed by your browser
Browser	The app that requests and displays web pages
Server	A computer that listens for and responds to requests
Frontend	What the user sees (HTML, CSS, JS)
Backend	Logic that runs on the server (Node, Python, etc.)
Database	Where data is stored (like a smart spreadsheet)
HTTP	The rules/language browsers and servers speak
Request	What the browser sends ("give me this page")
Response	What the server sends back (the page + status)
URL	The address of a webpage
Domain	Human-friendly name for a server (google.com)
IP Address	The real numeric address of a server
HTTPS	HTTP + encryption = secure communication
GET	"Read/fetch something"
POST	"Send/submit data"
Client-Server	Client asks → Server responds. Always.

✅ Phase 0 Checklist

Before moving to Phase 1, make sure you can answer:

[ ] What happens when I type a URL and press Enter?
[ ] What's the difference between frontend and backend?
[ ] What does a database do?
[ ] What's a request? What's a response?
[ ] What's the difference between GET and POST?
[ ] What does a 404 error mean? What about 500?
[ ] Why is HTTPS better than HTTP?
[ ] I've opened DevTools and seen real requests/responses

[!TIP]
You do NOT need to understand everything perfectly. If you can explain the restaurant analogy to someone — you're ready for Phase 1. Understanding deepens as you build things.

Hands-On Lab Guide: L1 Support Engineer Skills

Yashvi Kothari — Mon, 17 Aug 2026 09:36:54 +0000

🛠️ Hands-On Lab Guide: L1 Support Engineer Skills

Lab 1: Windows Server + IIS Setup (Core L1 Skill)

Objective

Launch a Windows Server EC2, install IIS, deploy a test website, and practice troubleshooting.

Step-by-Step

1. Launch a Windows EC2 Instance

AWS Console → EC2 → Launch Instance

Name:              L1-Lab-Windows-IIS
AMI:               Microsoft Windows Server 2022 Base
Instance type:     t3.medium
Key pair:          Create new → "l1-lab-key" → Download .pem
Security Group:    Create new with these rules:
                   - RDP (port 3389) → My IP
                   - HTTP (port 80) → 0.0.0.0/0
                   - HTTPS (port 443) → 0.0.0.0/0

Click "Launch Instance"

2. Connect via RDP

Password:
6xr&;(LfLeaZyayHGSpjA9c@!OgA$xBF
Private IP address
172.31.7.190

1. Select your instance → Click "Connect"
2. Go to "RDP Client" tab
3. Click "Get password" → Upload your .pem key file → Decrypt
4. Download the RDP file
5. Open it with Remote Desktop Connection
6. Enter the decrypted password
7. You're now on a Windows Server!

3. Install IIS (Internet Information Services)

Open PowerShell as Administrator on the Windows Server:

# Install IIS with management tools
Install-WindowsFeature -Name Web-Server -IncludeManagementTools

# Verify IIS is running
Get-Service W3SVC

# Check IIS is serving the default page
Invoke-WebRequest -Uri http://localhost -UseBasicParsing | Select-Object StatusCode

4. Deploy a Test Website

# Navigate to the default website directory
cd C:\inetpub\wwwroot

# Backup the default page
Rename-Item .\iisstart.htm .\iisstart.htm.bak

# Create a custom test page
@"
<!DOCTYPE html>
<html>
<head><title>L1 Lab - Test Application</title></head>
<body>
    <h1>L1 Support Lab - Application Running</h1>
    <p>Server: $(hostname)</p>
    <p>Time: <span id="time"></span></p>
    <p>Status: <span style="color:green;">HEALTHY</span></p>
    <script>
        document.getElementById('time').textContent = new Date().toISOString();
    </script>
</body>
</html>
"@ | Out-File -FilePath .\index.html -Encoding UTF8

5. Verify — Open a browser and navigate to your EC2 Public IP:

http://<your-ec2-public-ip>

You should see your test page. ✅

🔥 Troubleshooting Exercises

Exercise A: Simulate "Website Down" (IIS Stopped)

# Stop IIS
Stop-Service W3SVC

# Now try accessing the website in browser — it fails!
# This simulates a P1 incident: "Website is down"

# How to diagnose:
Get-Service W3SVC  # Shows "Stopped"

# How to fix:
Start-Service W3SVC

# Verify:
Invoke-WebRequest -Uri http://localhost -UseBasicParsing | Select-Object StatusCode

Exercise B: Simulate "Port Blocked"

# Block port 80 in Windows Firewall
New-NetFirewallRule -DisplayName "Block HTTP" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Block

# Website now unreachable from outside, but IIS is running!
# This simulates: "IIS is running but website not accessible"

# Diagnose:
Get-NetFirewallRule -DisplayName "Block HTTP"

# Fix:
Remove-NetFirewallRule -DisplayName "Block HTTP"

Exercise C: Check Event Viewer for Errors

# View recent IIS-related events
Get-EventLog -LogName System -Source "IIS*" -Newest 10

# View application errors
Get-EventLog -LogName Application -EntryType Error -Newest 20

# This is how you find error evidence for incident reports

Lab 2: Linux Server + Log Analysis (Core L1 Skill)

Objective

Launch a Linux EC2, practice essential commands, analyze logs, and simulate issues.

Step-by-Step

1. Launch a Linux EC2 Instance

AWS Console → EC2 → Launch Instance

Name:              L1-Lab-Linux
AMI:               Amazon Linux 2023
Instance type:     t3.micro (save your t3.medium for IIS)
Key pair:          Use same "l1-lab-key"
Security Group:    Allow SSH (port 22) from My IP

Click "Launch Instance"

2. Connect via SSH

From your local terminal (or use EC2 Instance Connect in the browser):

# If using terminal (convert .pem permissions first on Linux/Mac)
ssh -i "l1-lab-key.pem" ec2-user@<your-linux-public-ip>

# Or: AWS Console → Select Instance → Connect → EC2 Instance Connect → Connect

3. Essential L1 Commands — Practice Each One

# ===== SYSTEM INFORMATION =====

# Check who you are
whoami

# Check server hostname
hostname

# Check OS version
cat /etc/os-release

# Check uptime (how long server has been running)
uptime

# ===== CPU & MEMORY =====

# Check CPU usage (press 'q' to exit)
top

# Check memory usage
free -m

# Detailed memory info
cat /proc/meminfo | head -5

# ===== DISK SPACE =====

# Check disk usage (human-readable)
df -h

# Check which directories are using most space
du -sh /var/log/*

# ===== PROCESSES =====

# List all running processes
ps aux

# Find a specific process
ps aux | grep httpd

# Count running processes
ps aux | wc -l

# ===== NETWORK =====

# Check network interfaces
ip addr show

# Check open ports
ss -tlnp

# Test if a remote service is reachable
curl -I http://google.com

4. Log Analysis — The Core L1 Skill

# ===== VIEWING LOGS =====

# View system logs
sudo cat /var/log/messages | tail -50

# Follow logs in real-time (CRITICAL L1 SKILL)
sudo tail -f /var/log/messages
# (Press Ctrl+C to stop)

# Search logs for errors
sudo grep -i "error" /var/log/messages

# Search for specific timestamps
sudo grep "Aug 17" /var/log/messages

# Count how many errors occurred
sudo grep -ic "error" /var/log/messages

# ===== JOURNALCTL (systemd logs) =====

# View recent logs
sudo journalctl -n 50

# View logs since a specific time
sudo journalctl --since "1 hour ago"

# View logs for a specific service
sudo journalctl -u sshd -n 20

# Follow logs live
sudo journalctl -f

5. Simulate and Analyze Errors

# Create a fake application log for practice
sudo bash -c 'cat > /var/log/test-app.log << EOF
2026-08-17 10:00:01 INFO  Application started successfully
2026-08-17 10:00:02 INFO  Database connection established
2026-08-17 10:05:15 WARN  Slow query detected: 3200ms on /api/users
2026-08-17 10:05:16 WARN  Connection pool usage at 85%
2026-08-17 10:10:30 ERROR Database connection timeout after 30000ms
2026-08-17 10:10:31 ERROR java.sql.SQLException: Cannot acquire connection from pool
2026-08-17 10:10:32 ERROR HTTP 500 returned for GET /api/users/123
2026-08-17 10:10:33 ERROR HTTP 500 returned for POST /api/orders
2026-08-17 10:10:34 WARN  Retry attempt 1 for database connection
2026-08-17 10:10:35 WARN  Retry attempt 2 for database connection
2026-08-17 10:10:36 ERROR All retry attempts exhausted. Service degraded.
2026-08-17 10:15:00 INFO  Database connection re-established
2026-08-17 10:15:01 INFO  Service recovered. All endpoints healthy.
EOF'

# Now practice analysis:

# Find all errors
grep "ERROR" /var/log/test-app.log

# Find when errors started
grep "ERROR" /var/log/test-app.log | head -1

# Find when service recovered
grep "recovered" /var/log/test-app.log

# Count errors vs warnings
echo "Errors: $(grep -c 'ERROR' /var/log/test-app.log)"
echo "Warnings: $(grep -c 'WARN' /var/log/test-app.log)"

# Find the root cause pattern
grep -E "timeout|connection" /var/log/test-app.log

[!TIP]
Practice narrating your findings out loud:
"Errors started at 10:10:30. The root cause appears to be database connection timeout. The connection pool was already at 85% utilization at 10:05. This caused HTTP 500 errors on multiple endpoints. Service auto-recovered at 10:15 after database connection was re-established."
This is exactly how you'd communicate during a P1 bridge call.

Lab 3: AWS CloudWatch Monitoring (Monitoring Skill)

Objective

Set up CloudWatch dashboards and alarms for your EC2 instances.

Step-by-Step

1. View Default EC2 Metrics

AWS Console → CloudWatch → Metrics → All metrics

Click: EC2 → Per-Instance Metrics

Find your instances. Select:
  ✅ CPUUtilization
  ✅ NetworkIn
  ✅ NetworkOut
  ✅ StatusCheckFailed

Click "Graphed metrics" tab to see the charts

2. Create a CloudWatch Dashboard

CloudWatch → Dashboards → Create Dashboard

Name: "L1-Lab-Monitoring"

Add Widget → Line chart → Select:
  - EC2 > Per-Instance > CPUUtilization (for both instances)

Add Widget → Number → Select:
  - EC2 > Per-Instance > StatusCheckFailed

Add Widget → Line chart → Select:
  - EC2 > Per-Instance > NetworkIn + NetworkOut

Save Dashboard

3. Create a CloudWatch Alarm (P1 Simulation)

CloudWatch → Alarms → Create Alarm

Select Metric: EC2 → Per-Instance → CPUUtilization
Select your Windows IIS instance

Conditions:
  Threshold type: Static
  Greater than: 80
  Period: 1 minute
  Datapoints: 1 out of 1

Notification:
  Create new SNS topic: "L1-Lab-Alerts"
  Email: your-email@example.com

Alarm name: "High-CPU-IIS-Server"
Description: "CPU above 80% on IIS production server"

Create Alarm

4. Trigger the Alarm (Simulate High CPU)

RDP into your Windows Server and run:

# Simulate CPU load (will spike CPU to ~100%)
# Run this in PowerShell:
$cores = (Get-WmiObject Win32_Processor).NumberOfLogicalProcessors
1..$cores | ForEach-Object {
    Start-Job -ScriptBlock {
        $end = (Get-Date).AddMinutes(3)
        while ((Get-Date) -lt $end) { [math]::Sqrt(12345) | Out-Null }
    }
}

# Watch CPU spike in Task Manager
# Check CloudWatch — the alarm should trigger within 2-3 minutes

# Stop the load after testing:
Get-Job | Stop-Job
Get-Job | Remove-Job

5. Check the Alarm

CloudWatch → Alarms → "High-CPU-IIS-Server"

State should change: OK → In alarm

This is exactly what happens in production.
You'd see this alarm, investigate CPU usage, and open an incident.

[!NOTE]
In real-world L1 support, you'd receive this alarm via email/Slack/PagerDuty, investigate the cause (runaway process? traffic spike? deployment?), and either fix it or escalate.

Lab 4: REST API Troubleshooting with Postman + curl

Objective

Test APIs, understand HTTP status codes, and diagnose API failures.

Step-by-Step (No EC2 needed — use your local machine)

1. Install Postman
Download from: https://www.postman.com/downloads/

2. Test a Public API

Method: GET
URL: https://jsonplaceholder.typicode.com/posts/1

Click Send

Expected:
  Status: 200 OK
  Body: JSON with a post object (userId, id, title, body)

3. Test Different Status Codes

# 200 - Success
GET https://jsonplaceholder.typicode.com/posts/1

# 404 - Not Found
GET https://jsonplaceholder.typicode.com/posts/99999

# Test another API for different codes:
GET https://httpstat.us/200    → Returns 200
GET https://httpstat.us/401    → Returns 401 Unauthorized
GET https://httpstat.us/403    → Returns 403 Forbidden
GET https://httpstat.us/500    → Returns 500 Internal Server Error
GET https://httpstat.us/502    → Returns 502 Bad Gateway
GET https://httpstat.us/503    → Returns 503 Service Unavailable

4. Test POST Request

Method: POST
URL: https://jsonplaceholder.typicode.com/posts
Headers:
  Content-Type: application/json
Body (raw JSON):
{
  "title": "Test from L1 Lab",
  "body": "Testing API creation",
  "userId": 1
}

Click Send

Expected:
  Status: 201 Created
  Body: JSON with id: 101

5. Using curl from Command Line

# GET request
curl -v https://jsonplaceholder.typicode.com/posts/1

# POST request
curl -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title":"Test","body":"Testing","userId":1}'

# Check only status code
curl -s -o /dev/null -w "%{http_code}" https://jsonplaceholder.typicode.com/posts/1

# Check response headers
curl -I https://jsonplaceholder.typicode.com/posts/1

# Test timeout behavior (useful for troubleshooting)
curl --max-time 5 https://httpstat.us/200?sleep=10000
# This will timeout after 5 seconds — simulates API timeout

6. Practice Scenario: "Client reports API not working"

Client says: "The /users endpoint is returning errors"

Your investigation steps:

1. Test the endpoint:
   GET https://jsonplaceholder.typicode.com/users

2. Check status code — is it 200, 401, 500, 503?

3. Check response time — Headers tab in Postman shows duration

4. Check response body — any error messages?

5. Test with different parameters:
   GET https://jsonplaceholder.typicode.com/users/1
   GET https://jsonplaceholder.typicode.com/users?email=Sincere@april.biz

6. Document your findings:
   "Tested /users endpoint at 14:30 UTC. 
    Status: 200 OK. 
    Response time: 245ms. 
    Data returned correctly for all test cases.
    Unable to reproduce client's issue.
    Requesting client to share:
    - Exact URL they're hitting
    - Request headers (especially Authorization)
    - Screenshot of the error
    - Browser/client they're using"

Lab 5: Writing an Incident Report + RCA

Objective

Practice writing a real incident report from the issues you simulated.

Template

# Incident Report

**Incident ID:** INC-2026-0817-001
**Priority:** P2 - High
**Status:** Resolved

## Summary
IIS web server on production EC2 instance became unreachable 
at 10:10 UTC on August 17, 2026. Root cause identified as 
IIS service failure. Service restored at 10:25 UTC.
Total downtime: 15 minutes.

## Timeline
| Time (UTC) | Event |
|------------|-------|
| 10:10 | CloudWatch alarm triggered: StatusCheckFailed |
| 10:12 | L1 engineer acknowledged the incident |
| 10:13 | Client notification sent: "Investigating reported downtime" |
| 10:15 | RDP to server confirmed IIS service stopped |
| 10:16 | Event Viewer checked — unexpected service termination logged |
| 10:18 | IIS service restarted |
| 10:20 | Website verified accessible |
| 10:22 | CloudWatch alarm returned to OK state |
| 10:25 | Client notified: "Service restored, monitoring for stability" |

## Root Cause
The IIS (W3SVC) service stopped unexpectedly due to [cause].
Event Viewer logs showed [specific error details].

## Impact
- All users accessing the web application were affected
- Duration: 15 minutes
- No data loss occurred

## Resolution
IIS service was restarted manually via PowerShell:
`Start-Service W3SVC`

## Preventive Measures
1. Configure IIS service auto-recovery (restart on failure)
2. Add CloudWatch alarm for W3SVC service status
3. Investigate root cause of service termination
4. Add automated health check endpoint monitoring

## Lessons Learned
- Need automated service recovery configuration
- CloudWatch alarm detected issue 2 minutes before client report
- Communication template was used effectively

[!TIP]
Write at least 3 RCA reports using different scenarios from these labs. This is a frequently asked skill in L1 support interviews.

Lab Checklist — Track Your Progress

#	Lab	Skill	Done?
1	Windows EC2 + IIS	Server management, IIS administration	☐
2	Linux EC2 + Logs	CLI commands, log analysis	☐
3	CloudWatch Monitoring	Metrics, dashboards, alarms	☐
4	Postman + curl	API testing, status codes	☐
5	Incident Report + RCA	Documentation, communication	☐

Quick Reference: Key Commands

Windows (PowerShell)

Get-Service W3SVC                    # Check IIS status
Start-Service W3SVC                  # Start IIS
Stop-Service W3SVC                   # Stop IIS
Restart-Service W3SVC                # Restart IIS
Get-EventLog -LogName System -Newest 20   # Recent system events
Get-Process | Sort-Object CPU -Desc | Select -First 10  # Top CPU processes
Test-NetConnection google.com -Port 443   # Test network connectivity

Linux (Bash)

top                    # CPU/Memory usage (live)
free -m                # Memory usage
df -h                  # Disk space
ps aux                 # Running processes
tail -f /var/log/messages   # Follow logs
grep "ERROR" logfile   # Search for errors
journalctl -f          # Follow system logs
ss -tlnp               # Open ports
curl -I url            # Check HTTP response
systemctl status httpd # Check service status

AWS CLI (Bonus)

# Describe your instances
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,State.Name,PublicIpAddress]' --output table

# Get CloudWatch CPU metric
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=YOUR_INSTANCE_ID \
  --start-time 2026-08-17T00:00:00Z \
  --end-time 2026-08-17T23:59:59Z \
  --period 300 \
  --statistics Average

[!IMPORTANT]
Sandbox Time Management: sandbox sessions expire. Prioritize:

Lab 1 (IIS) — takes ~30 min

Lab 2 (Linux) — takes ~20 min

Lab 3 (CloudWatch) — takes ~15 min

Labs 4 and 5 don't need the sandbox. Do them on your local machine anytime.

The L1 Support Engineer Nobody Talks About (But Every Company Desperately Needs)

Yashvi Kothari — Mon, 17 Aug 2026 08:52:29 +0000

The L1 Support Engineer Nobody Talks About (But Every Company Desperately Needs)

How to become the person who keeps the internet running at 3 AM — and why that's a career superpower.

Here's a truth most tech influencers won't tell you:

The fastest path into tech isn't learning to code. It's learning to troubleshoot.

While thousands of people are grinding LeetCode, a quieter army of L1 Support Engineers is keeping production systems alive for millions of users. They're the first responders of the digital world. No glory. No fanfare. Just a Slack notification at 2 AM and a client in London who can't access their dashboard.

And here's the kicker — the best ones get promoted faster than most junior developers.

What Is an L1 Support Engineer, Really?

Strip away the jargon. An L1 Support Engineer is a technical detective with a customer-service heart.

You're not writing the code. You're figuring out why the code broke. You're the person who:

Reads the error log when everyone else panics
Asks the right questions when the client says "everything is down"
Knows the difference between "the server is slow" and "the database connection pool is exhausted"

Naval would say: "An L1 engineer is leveraged. One person, monitoring systems that serve thousands."

Ogilvy would say: "The consumer isn't a moron. She's your client. Treat her with respect, even at 3 AM."

The 7 Skills That Separate Good L1 Engineers From Great Ones

1. You Understand the Stack (Even If You Didn't Build It)

You don't need to build a web application. You need to understand how one works:

Client (Browser) → DNS → Load Balancer → Web Server (IIS/Nginx) → Application → Database

When a client says "the app is broken," a great L1 engineer mentally walks this chain. Where did it break?

Practical Step: Set up a Windows Server on AWS with IIS. Deploy a simple web app. Break it intentionally. Fix it. That's the entire training.

2. You Can Read Logs Like a Detective Reads Crime Scenes

Logs are your evidence. Every error tells a story.

[2026-08-17 03:14:22 ERROR] System.Data.SqlClient.SqlException: 
Timeout expired. The timeout period elapsed prior to completion 
of the operation or the server is not responding.

A junior reads this and says: "Database error."
A great L1 reads this and says: "The database query is timing out — could be a long-running query, connection pool exhaustion, or the DB server itself is under load. Let me check CloudWatch metrics for the RDS instance."

Practical Step: SSH into a Linux server. Run tail -f /var/log/syslog. Break something. Watch the logs scream. Learn to hear what they're saying.

3. You Speak REST API

Every modern application talks in APIs. You need to understand the conversation.

Method	Purpose	Example
GET	Retrieve data	`GET /api/users/123`
POST	Create data	`POST /api/orders`
PUT	Update data	`PUT /api/users/123`
DELETE	Remove data	`DELETE /api/orders/456`

Status codes are your vocabulary:

200 — All good
401 — Authentication failed (wrong credentials)
403 — Forbidden (right credentials, wrong permissions)
404 — Resource not found
500 — Server broke internally
502 — Bad Gateway (upstream server failed)
503 — Service unavailable (server overloaded or down)

Practical Step: Open Postman. Hit a public API like https://jsonplaceholder.typicode.com/posts. Change the endpoint to something that doesn't exist. Observe the status codes. Now you speak the language.

4. You Know Enough SQL to Be Dangerous (In a Good Way)

You're not writing stored procedures. You're running SELECT queries to verify data.

-- Check if a user exists
SELECT * FROM Users WHERE Email = 'client@example.com';

-- Check recent orders
SELECT TOP 10 * FROM Orders ORDER BY CreatedDate DESC;

-- Check for failed transactions in the last hour
SELECT * FROM Transactions 
WHERE Status = 'FAILED' 
AND CreatedDate >= DATEADD(HOUR, -1, GETDATE());

Practical Step: Install SQL Server Management Studio (SSMS). Connect to a local or cloud database. Write 10 SELECT queries. You'll use these daily.

5. You Understand Environments (And Never Confuse Them)

This is where careers are saved or destroyed:

Development → QA/Testing → UAT (User Acceptance) → Staging → Production

The golden rule: You NEVER make changes directly in Production. Ever.

Each environment has its own:

Server/URL
Database
Configuration
Access controls

A real-world scenario: Client reports a bug. You reproduce it in UAT. You confirm it exists in Production. You do NOT fix it in Production. You log it, escalate it, and the fix flows through the pipeline.

6. You Master the Incident Priority Matrix

Not all fires are equal. Knowing which fire to fight first is the job.

Priority	Description	Example	SLA Response
P1	Critical — System down, all users affected	Production app completely inaccessible	15 minutes
P2	High — Major feature broken, many users affected	Payment processing failing	30 minutes
P3	Medium — Feature degraded, workaround exists	Reports loading slowly	4 hours
P4	Low — Minor issue, cosmetic or enhancement	Button color wrong on one page	24 hours

The communication framework during a P1:

1. Acknowledge → "We are aware of the issue and investigating."
2. Update (every 15-30 min) → "Root cause identified. The team is working on a fix."
3. Resolution → "The issue has been resolved. Services are restored."
4. RCA (within 24-48h) → "Root Cause Analysis report with preventive measures."

Practical Step: Write a mock RCA report. Take a real-world outage (AWS, Azure, any public postmortem) and rewrite their RCA in your own words. This is how you build the muscle.

7. You Monitor Before Things Break

The best L1 engineers don't wait for the phone to ring. They watch the dashboards.

Key metrics to watch:

CPU utilization — above 80% for sustained periods = trouble
Memory usage — if it keeps climbing without dropping, you have a memory leak
Disk space — databases and logs eat disk space silently
Response time — if your API goes from 200ms to 2000ms, something changed
Error rate — a sudden spike in 5xx errors means something broke
Active connections — connection pool exhaustion kills apps quietly

Tools of the trade:

AWS CloudWatch (if you're on AWS)
Azure Monitor / Application Insights (if you're on Azure)
Grafana + Prometheus (open-source, powerful)
New Relic / ELK Stack (enterprise-grade observability)

The Career Path Nobody Draws For You

L1 Support Engineer
    ↓
L2 Support Engineer (deeper troubleshooting, some scripting)
    ↓
    ├── DevOps Engineer (automation, CI/CD, infrastructure)
    ├── Cloud Engineer (AWS/Azure architecture)
    ├── SRE (Site Reliability Engineering)
    └── Solutions Architect (client-facing technical leadership)

Every great SRE I know started in support. Every great DevOps engineer I know started by reading logs at midnight. The path is real. The opportunity is real.

The Mindset Shift

Most people see L1 Support as a stepping stone. Something to survive.

The best engineers see it as a training ground.

You're learning:

How production systems actually behave (not how textbooks say they should)
How to communicate under pressure (a skill worth more than any certification)
How to think systematically when everything is on fire
How to own a problem from first ring to final resolution

Naval's principle applies perfectly here: "Specific knowledge is knowledge you cannot be trained for. It's found by pursuing your genuine curiosity."

An L1 Support role, done right, gives you the most specific knowledge in tech — how real systems fail, and how real teams fix them.

Your 30-Day Action Plan

Week	Focus	Actions
Week 1	Foundation	Set up AWS EC2 (Windows + Linux), install IIS, deploy a test app, learn basic CLI commands
Week 2	Monitoring & Logs	Set up CloudWatch dashboards, practice log analysis, learn to read error patterns
Week 3	APIs & Database	Use Postman to test APIs, write 20+ SQL queries, understand connection strings
Week 4	Incident Management	Write 3 mock RCA reports, practice client communication templates, simulate P1 response

The Bottom Line

The world doesn't need more people who can write "Hello World."

The world needs people who can figure out why "Hello World" stopped working at 3 AM, fix it, and explain what happened to a client in London who just lost $10,000 per minute of downtime.

That person is an L1 Support Engineer.

That person might be you.

If this helped you, share it with someone who's trying to break into tech. The support path is underrated, undershared, and wildly effective.

How to Think Like a System Administrator: The Practical Interview Playbook

Yashvi Kothari — Wed, 12 Aug 2026 11:33:27 +0000

At 11:00 PM, the phone rings.

A client says:

“The website is down.”

This is where a junior administrator starts guessing.

A strong system administrator starts asking questions.

Is the server reachable?

Is the web server running?

Is PHP-FPM healthy?

Is the database responding?

Is the disk full?

Did someone deploy something 10 minutes ago?

Are there errors in the logs?

The difference between a beginner and an experienced SysAdmin isn't how many commands they memorized.

It's how systematically they think when something breaks.

The SysAdmin Mental Model

Almost every production incident can be approached with the same pattern:

Verify → Isolate → Inspect → Fix → Verify → Prevent

Don't restart everything.

Don't randomly change configuration.

Don't immediately blame the application.

Find the failure.

Then fix the failure.

Scenario #1: The Website Is Down

Imagine a production website stops responding at 11 PM.

Your first step isn't:

sudo systemctl restart nginx

Your first step is verification.

Try:

curl -I https://example.com

Check connectivity:

ping SERVER_IP

Then connect to the server:

ssh user@SERVER_IP

Check the basic health:

uptime
free -h
df -h
top

Now inspect the web server:

systemctl status nginx

If you're using Apache:

systemctl status apache2

Then check logs.

For Nginx:

tail -50 /var/log/nginx/error.log

For PHP-FPM:

tail -50 /var/log/php8.2-fpm.log

If the site returns 502 Bad Gateway, investigate the upstream service.

For example:

systemctl status php8.2-fpm

Then check the database:

systemctl status mysql

And finally:

df -h

Because a surprisingly large number of “application problems” are actually disk-full problems.

The interview answer

Don't simply say:

“I would restart Nginx.”

Say:

“First I would verify the outage and determine whether it's isolated to one website or affects the entire server. Then I'd check server resources, web-server status, application services, database connectivity and logs. I would identify the root cause before making changes, verify the fix, and document the incident.”

That sounds like an administrator.

Scenario #2: The Server Is Slow

“It's slow” is not a diagnosis.

It's a symptom.

Start with:

uptime
free -h
htop

Check CPU:

ps aux --sort=-%cpu | head

Check memory:

ps aux --sort=-%mem | head

Check disk I/O:

iostat

Then investigate the web server.

How much traffic are you receiving?

Which IPs are generating the most requests?

For example:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Then investigate the database.

SHOW PROCESSLIST;

A slow website might actually be:

Nginx → PHP-FPM → MySQL → slow query

Restarting Nginx won't fix that.

This is why troubleshooting must follow the request path.

Scenario #3: SSL Certificate Expired

Users see:

“Your connection is not private.”

Check the certificate:

echo | openssl s_client \
-connect example.com:443 2>/dev/null \
| openssl x509 -noout -dates

For Let's Encrypt:

sudo certbot renew --dry-run

If renewal is required:

sudo certbot renew

Then validate Nginx before reloading:

sudo nginx -t
sudo systemctl reload nginx

The important interview point isn't knowing Certbot.

It's knowing the sequence:

Identify → Renew → Validate → Reload → Verify → Automate

And always test automatic renewal before assuming it works.

Scenario #4: Disk Is 95% Full

This is where many administrators make dangerous mistakes.

Don't immediately start deleting files.

First identify the problem.

df -h

Then:

sudo du -sh /* 2>/dev/null | sort -rh | head -20

Drill deeper:

sudo du -sh /var/* 2>/dev/null | sort -rh | head -20

Common culprits include:

Nginx/Apache logs
systemd journal logs
database binary logs
old backups
temporary files
application-generated files

Clean safely.

For example:

sudo apt clean
sudo journalctl --vacuum-time=7d

Then investigate log rotation.

The real solution isn't:

“I deleted some files.”

It's:

“I identified the source of disk growth and implemented log rotation, backup retention and monitoring so the problem doesn't return.”

That's the difference between incident response and systems administration.

Scenario #5: Database Connection Errors

Multiple websites suddenly report:

Cannot connect to database.

Start with:

sudo systemctl status mysql

Check the logs:

sudo tail -50 /var/log/mysql/error.log

Check disk:

df -h

Check memory:

free -h

Look for OOM events:

dmesg | grep -i "oom\|killed process"

If MySQL is running but applications can't connect, investigate:

credentials
database existence
user permissions
connection limits
host restrictions
application configuration

Test directly:

mysql -u appuser -p -h localhost database_name

Then:

SHOW STATUS LIKE 'Threads_connected';

And:

SHOW GRANTS FOR 'appuser'@'localhost';

Again, don't jump to:

systemctl restart mysql

Understand why connections are failing.

Scenario #6: Migrating 15 Websites

This is where planning matters more than commands.

A migration should look something like:

Before migration

Inventory:

domains
DNS records
databases
application versions
PHP versions
web-server configuration
SSL certificates
cron jobs
firewall rules
backups

Lower DNS TTL before migration.

For example:

300 seconds

Prepare the new server.

Then perform an initial data synchronization.

For example:

rsync -avz /var/www/ user@NEW_SERVER:/var/www/

Import databases.

Test websites against the new server before changing DNS.

A useful technique is testing through the local hosts file.

Then:

Final sync
Final database migration
DNS change
Verify applications
Monitor logs
Keep the old server available as rollback

The goal isn't simply:

“Move the websites.”

The goal is:

Move the websites while minimizing risk and maintaining a rollback path.

Scenario #7: The Server Is Under Attack

First determine what you're dealing with.

Look at traffic:

awk '{print $1}' /var/log/nginx/access.log \
| sort | uniq -c | sort -rn | head -20

Check connections:

ss -s

For HTTP connections:

ss -ant | grep ':80' | wc -l

But remember:

Not every traffic spike is a DDoS attack.

It could be:

legitimate traffic
a broken client
a crawler
a brute-force attack
an application bug
a real DDoS

For application-layer attacks, rate limiting can help.

For larger attacks, move protection upstream.

A service such as Cloudflare can provide:

WAF
rate limiting
bot protection
DDoS mitigation

The key interview answer:

“I would identify the attack pattern first, apply the least disruptive mitigation available, involve the provider or upstream DDoS protection when necessary, and then implement permanent controls.”

The 10 Commands I Want Every SysAdmin to Know

If you remember nothing else, remember these:

uptime
free -h
df -h
htop
ss -tlnp
systemctl status nginx
journalctl -u nginx
nginx -t
tail -f /var/log/nginx/error.log
lsof -i :80

They answer some of the most important questions:

Is the server healthy?

uptime
free -h
df -h

What's consuming resources?

htop

What's listening?

ss -tlnp

Is the service healthy?

systemctl status nginx

What went wrong?

journalctl -u nginx

Is my configuration valid?

nginx -t

What's happening right now?

tail -f /var/log/nginx/error.log

What's using the port?

lsof -i :80

The Two-Week Interview Plan

Don't spend two weeks just reading.

Build.

Week 1

Day 1: Linux commands

Day 2: Users, permissions and SSH

Day 3: Apache

Day 4: Nginx

Day 5: DNS

Day 6: SSL

Day 7: PHP and PHP-FPM

Week 2

Day 8: MySQL/MariaDB

Day 9: Monitoring

Day 10: Firewall and security

Day 11: Backups and cron

Day 12: Docker

Day 13: Cloud and Git

Day 14: Scenario practice

Every day:

1 hour theory

2 hours hands-on

1 hour interview practice

And don't just read answers.

Say them out loud.

Build Your Own Production-Like Lab

A cheap Ubuntu VM is enough to learn the fundamentals.

Install:

Nginx
PHP-FPM
MySQL
Docker
Git
UFW
Fail2ban

Then deliberately break things.

Stop Nginx.

Fill the disk.

Break a configuration file.

Stop PHP-FPM.

Change a database password.

Break DNS.

Expire a certificate.

Kill a process.

Then recover.

That is where real learning happens.

The Golden Rule of Troubleshooting

When something breaks:

Don't panic.

Don't guess.

Don't restart everything.

Use:

Verify → Isolate → Inspect → Fix → Verify → Prevent

And remember five things interviewers want to hear:

1. Systematic thinking

You investigate before changing things.

2. Security

You don't use root unnecessarily.

You don't expose databases publicly.

You don't give developers root access.

3. Backups

Before risky changes:

Have a rollback plan.

4. Communication

During incidents, stakeholders need updates.

5. Prevention

Fixing today's problem isn't enough.

Ask:

“How do we make sure this doesn't happen again?”

That's what separates a command runner from a system administrator.

Final Interview Advice

When asked:

“Tell me about your experience.”

Don't give a list of technologies.

Tell a story.

Instead of:

“I know Linux, Nginx, MySQL, AWS and Docker.”

Say:

“I manage Linux-based servers and web applications, including Nginx/Apache, PHP-FPM and databases. I handle deployments, SSL, DNS, backups, monitoring and security. When incidents occur, I troubleshoot systematically using logs, system metrics and service health checks, then focus on preventing the same issue from happening again.”

Technology tells them what you know.

Problem-solving tells them why they should hire you.

The best SysAdmins aren't the people who know the most commands.

They're the people who can stay calm at 11 PM, find the signal inside the noise, restore service safely, and explain exactly what happened afterward.

Learn the commands.

Practice the scenarios.

Build the habit of thinking in systems.

That's how you become interview-ready.

Part 7: Scenario Questions, Study Plan & Quick Reference

7.1 Scenario-Based Interview Questions (MOST IMPORTANT)

[!IMPORTANT]
Interviewers love scenario questions because they test real-world problem-solving. Practice explaining these OUT LOUD.

Scenario 1: Website is Down

Q: "It's 11 PM and a client reports their website is down. Walk me through your troubleshooting process."

Answer:

1. VERIFY the issue
   - Try accessing the site myself from browser + curl
   - Check if it's site-specific or all sites on the server
   - Ping the server IP

2. CHECK server connectivity
   - SSH into the server (if can't → check provider's console)
   - Run: uptime, free -h, df -h, top

3. CHECK web server
   - systemctl status nginx (or apache2)
   - If stopped → systemctl start nginx → check logs for why it stopped

4. CHECK error logs
   - tail -50 /var/log/nginx/error.log
   - tail -50 /var/log/php8.2-fpm.log

5. CHECK PHP-FPM (if PHP site)
   - systemctl status php8.2-fpm
   - If 502 → restart PHP-FPM

6. CHECK database
   - systemctl status mysql
   - If site shows DB error → restart MySQL, check credentials

7. CHECK disk space
   - df -h → if full → find and clean large files/logs

8. CHECK for recent changes
   - Did someone deploy code? Change config? Update server?

9. COMMUNICATE
   - Update client with status and ETA
   - Document the incident

Scenario 2: Server is Slow

Q: "Users report the website is very slow. How do you investigate?"

Answer:

1. CHECK server resources
   - htop → CPU usage, RAM usage, load average
   - free -h → is swap being used heavily?
   - iostat → disk I/O bottleneck?

2. CHECK what's consuming resources
   - ps aux --sort=-%cpu | head → top CPU processes
   - ps aux --sort=-%mem | head → top RAM processes

3. CHECK web server
   - Access log analysis: are there too many requests? Bot traffic?
   - awk '{print $1}' access.log | sort | uniq -c | sort -rn | head

4. CHECK database
   - SHOW PROCESSLIST → stuck/slow queries?
   - Enable slow query log
   - Check if indexes are missing

5. CHECK PHP
   - PHP-FPM status → are all workers busy?
   - Check PHP error log for warnings
   - Check if OPcache is enabled

6. CHECK network
   - Is bandwidth maxed? → nload, vnstat
   - Is there a DDoS attack? → check access logs for patterns

7. QUICK FIXES
   - Kill stuck processes
   - Restart PHP-FPM (clears memory leaks)
   - Enable caching (Redis, OPcache, Nginx cache)
   - Block abusive IPs with fail2ban or UFW

8. LONG-TERM
   - Scale server (more CPU/RAM)
   - Add CDN (Cloudflare)
   - Optimize database queries
   - Implement application-level caching

Scenario 3: SSL Certificate Expired

Q: "A client's SSL certificate has expired and users are seeing security warnings. What do you do?"

Answer:

1. IDENTIFY which certificate
   - echo | openssl s_client -connect domain.com:443 2>/dev/null | openssl x509 -noout -dates

2. RENEW the certificate
   - If Let's Encrypt: sudo certbot renew --force-renewal
   - If paid cert: generate new CSR, submit to provider, download new cert

3. INSTALL/VERIFY
   - sudo nginx -t && sudo systemctl reload nginx
   - Verify in browser: check padlock icon

4. PREVENT recurrence
   - Verify certbot timer: sudo systemctl status certbot.timer
   - Or set up monitoring: SSL expiry alert 30 days before
   - Test auto-renewal: sudo certbot renew --dry-run

Scenario 4: Disk Space Full

Q: "You receive an alert that the server's disk is 95% full. What steps do you take?"

Answer:

1. IDENTIFY what's consuming space
   - df -h (which partition is full?)
   - du -sh /* | sort -rh | head -20
   - Then drill down: du -sh /var/* | sort -rh | head -20

2. QUICK CLEANUP
   - sudo apt clean                    # Clear apt cache
   - sudo journalctl --vacuum-time=7d  # Clear old systemd logs
   - find /var/log -name "*.gz" -delete # Delete compressed old logs
   - find /tmp -type f -mtime +7 -delete # Clean temp files
   - Check /var/log for huge log files → truncate or rotate

3. CHECK for common culprits
   - Large log files: /var/log/apache2/access.log, error.log
   - Old backups still on server
   - MySQL binary logs: PURGE BINARY LOGS BEFORE '2024-01-01'
   - Mail queue: mailq → clear if large

4. PREVENT recurrence
   - Set up logrotate for all logs
   - Move backups to S3/remote storage
   - Set up disk space alert at 80%
   - Add cron to clean old files

Scenario 5: Database Connection Errors

Q: "Multiple websites are showing 'Cannot connect to database'. How do you fix this?"

Answer:

1. CHECK MySQL status
   - sudo systemctl status mysql
   - If stopped → sudo systemctl start mysql
   - Check: sudo tail -50 /var/log/mysql/error.log

2. IF MySQL won't start
   - Check disk space: df -h
   - Check RAM: free -h (OOM killer may have killed MySQL)
   - Check: sudo dmesg | grep -i "oom\|mysql"
   - Try: sudo mysqld_safe &

3. IF MySQL is running but connections fail
   - Check max connections: SHOW STATUS LIKE 'Threads_connected';
   - If maxed: kill idle connections, increase max_connections
   - Check credentials in website config files (.env, wp-config.php)
   - Test: mysql -u appuser -p -h localhost database_name

4. IF one site works but another doesn't
   - Check database-specific credentials
   - Check if specific database exists
   - Check user permissions: SHOW GRANTS FOR 'user'@'localhost';

Scenario 6: Server Migration

Q: "We need to migrate 15 websites from an old server to a new server with zero downtime. How?"

Answer:

1. PLAN (1-2 days before)
   - Inventory: list all domains, databases, configs, SSL certs
   - Set up new server with same software stack
   - Lower DNS TTL to 300 seconds (do this early!)

2. PREPARE NEW SERVER
   - Install: OS updates, Nginx/Apache, PHP (same version), MySQL
   - Configure: firewall, SSH, fail2ban
   - Set up same PHP extensions and configurations

3. SYNC DATA (night before)
   - rsync website files (first sync - bulk transfer)
   - Export all databases
   - Copy SSL certificates, configs, crontabs

4. MIGRATION DAY
   - Final rsync (only changed files, very fast)
   - Final database dump and import
   - Copy latest configs
   - Test each site on new server (use hosts file to test)

5. DNS SWITCH
   - Update A records to new server IP
   - Monitor propagation: dnschecker.org

6. VERIFY
   - Test all 15 sites on new server
   - Test SSL, forms, databases, email
   - Monitor error logs for 24-48 hours

7. POST-MIGRATION
   - Keep old server running 7 days as fallback
   - Raise DNS TTL back to normal
   - Update all documentation

Scenario 7: Server Under Attack

Q: "The server is being hit by a DDoS attack. What do you do?"

Answer:

1. IDENTIFY the attack
   - Check access logs for patterns:
     awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
   - Check: ss -s (total connections)
   - Check: netstat -an | grep :80 | wc -l

2. IMMEDIATE ACTIONS
   - Block top attacking IPs:
     sudo ufw deny from ATTACKER_IP
   - Enable rate limiting in Nginx:
     limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

3. CLOUDFLARE (if available)
   - Enable "Under Attack Mode"
   - Set up rate limiting rules
   - Block suspicious countries/ASNs
   - Enable Bot Fight Mode

4. SERVER-LEVEL
   - Configure fail2ban for HTTP flood
   - Increase worker_connections in Nginx
   - Enable connection limiting

5. LONG-TERM
   - Set up Cloudflare on all domains
   - Configure WAF rules
   - Set up monitoring alerts for traffic spikes

Scenario	Key Actions
PHP upgrade needed	Install new PHP alongside old, test sites, update Nginx/Apache fastcgi_pass, remove old version
Email not being delivered	Check SPF/DKIM/DMARC, check mail logs, check blacklist status (mxtoolbox), verify port 25/587 open
Cron job not running	Check `grep CRON /var/log/syslog`, verify path, check permissions, test command manually
MySQL table crashed	`REPAIR TABLE tablename`, or restore from backup if repair fails
Server rebooted unexpectedly	Check `last reboot`, check `dmesg`, check `/var/log/syslog`, check OOM killer, check provider status
New website deployment	Create vhost, set up DNS, create DB + user, deploy code, fix permissions, install SSL, test
Developer needs database access	Create MySQL user with limited permissions, never give root. `GRANT SELECT, INSERT, UPDATE on db.* TO 'dev'@'ip'`
Backup restoration needed	Verify backup integrity, create fresh DB, import SQL, update config, fix permissions, test

7.2 Two-Week Study Plan (Zero to Interview-Ready)

Week 1: Core Skills

Day	Topic	Practice
Day 1	Linux commands, file operations	Set up Ubuntu VM, practice all commands from Part 1
Day 2	Users, permissions, SSH	Create users, set permissions, configure SSH keys & hardening
Day 3	Apache configuration	Install Apache, create 3 virtual hosts, set up .htaccess
Day 4	Nginx configuration	Install Nginx, create 3 server blocks, set up reverse proxy
Day 5	DNS & Domains	Set up a domain with all record types (use free domains or Cloudflare)
Day 6	SSL Certificates	Install Let's Encrypt on both Apache & Nginx, practice troubleshooting
Day 7	PHP & PHP-FPM	Install PHP, configure php.ini, set up PHP-FPM with Nginx

Week 2: Advanced Skills

Day	Topic	Practice
Day 8	MySQL/MariaDB	Install, create databases/users, backup/restore, slow query log
Day 9	Server monitoring	Practice htop, disk analysis, log analysis, set up monitoring
Day 10	Firewall & Security	Configure UFW, install fail2ban, SSH hardening, security audit
Day 11	Backup & Cron	Write backup scripts, set up cron jobs, test restore
Day 12	Docker basics	Install Docker, run containers, create docker-compose.yml
Day 13	Cloud & Git	Deploy on DigitalOcean, set up Git deployment workflow
Day 14	Scenario practice	Review all scenarios, practice explaining solutions out loud

Daily Routine

Morning (1 hour):   Read theory for today's topic
Afternoon (2 hours): Hands-on practice on VM/VPS
Evening (1 hour):    Review interview Q&A, practice explaining answers

7.3 Hands-On Lab Setup

Option A: Local VM (Free)

# 1. Download VirtualBox: virtualbox.org
# 2. Download Ubuntu Server 22.04 LTS ISO
# 3. Create VM: 2 CPU, 2GB RAM, 20GB disk
# 4. Install Ubuntu Server
# 5. Practice everything locally

# Network setup for SSH from host:
# VirtualBox → Settings → Network → Adapter 1 → Bridged Adapter
# OR Port Forwarding: Host 2222 → Guest 22
ssh -p 2222 user@localhost

Option B: DigitalOcean (Paid but realistic)

# 1. Sign up at digitalocean.com (get $200 free credit with referral)
# 2. Create a $6/month Droplet: Ubuntu 22.04 LTS
# 3. SSH in: ssh root@YOUR_DROPLET_IP
# 4. Practice everything on real cloud server
# 5. Destroy when done to stop billing

7.4 Critical Commands Cheat Sheet

# === SERVER STATUS ===
uptime                          # Uptime + load average
free -h                         # Memory usage
df -h                           # Disk space
htop                            # Interactive process viewer
ss -tlnp                        # Listening ports

# === SERVICE MANAGEMENT ===
systemctl status nginx          # Check service
systemctl restart nginx         # Restart service
systemctl reload nginx          # Reload config (zero downtime)
systemctl enable nginx          # Start on boot
journalctl -u nginx -f          # Follow service logs

# === WEB SERVER ===
nginx -t                        # Test Nginx config
apache2ctl configtest           # Test Apache config
tail -f /var/log/nginx/error.log       # Follow error log

# === DNS ===
dig example.com                 # DNS lookup
dig @8.8.8.8 example.com       # Lookup via Google DNS
dig example.com MX              # Mail records
dig TXT _dmarc.example.com     # DMARC record

# === SSL ===
certbot --nginx -d example.com  # Get SSL cert
certbot renew --dry-run         # Test renewal
openssl s_client -connect example.com:443  # Check SSL

# === DATABASE ===
mysql -u root -p                # Login
mysqldump -u root -p dbname | gzip > backup.sql.gz   # Backup
gunzip < backup.sql.gz | mysql -u root -p dbname      # Restore
SHOW PROCESSLIST;               # Running queries

# === FIREWALL ===
ufw status                     # Check firewall
ufw allow 80/tcp               # Allow HTTP
ufw deny from 1.2.3.4          # Block IP
fail2ban-client status sshd    # Check banned IPs

# === FILES & PERMISSIONS ===
chown -R www-data:www-data /var/www/    # Fix ownership
chmod 755 /var/www/html                 # Dir permissions
chmod 644 /var/www/html/index.html      # File permissions
find /var/www -type f -perm 0777        # Find insecure files

# === TROUBLESHOOTING ===
tail -f /var/log/syslog         # System log
dmesg | tail                    # Kernel messages
grep "error" /var/log/nginx/error.log   # Search for errors
lsof -i :80                    # What's using port 80

7.5 Documentation Template

Server Inventory Template

# Server: production-web-01

## Server Details
- Provider: DigitalOcean
- IP: 192.168.1.100
- OS: Ubuntu 22.04 LTS
- CPU: 4 vCPUs
- RAM: 8 GB
- Disk: 160 GB SSD

## Software Stack
- Nginx 1.22
- PHP 8.2-FPM
- MySQL 8.0
- Redis 7.0
- Node.js 20 LTS

## Hosted Domains
| Domain | Type | Document Root | Database | SSL |
|--------|------|---------------|----------|-----|
| example.com | WordPress | /var/www/example.com | example_db | Let's Encrypt |
| app.company.com | Laravel | /var/www/app | app_db | Let's Encrypt |
| api.company.com | Node.js | Port 3000 | N/A | Let's Encrypt |

## Backups
- Database: Daily at 2 AM, retained 30 days
- Files: Weekly Sunday 3 AM, retained 12 weeks
- Location: S3 bucket: s3://company-backups/production/

## Access
- SSH: Port 2222, key-based only
- Users: john (sudo), deploy (limited)

## Monitoring
- UptimeRobot: All domains monitored
- Disk alert: > 80%
- CPU alert: > 90% for 5 minutes

## Last Incidents
| Date | Issue | Resolution | Duration |
|------|-------|------------|----------|
| 2024-01-15 | Disk full | Cleaned old logs | 15 min |
| 2024-02-03 | MySQL crashed | OOM, increased RAM | 30 min |

Incident Report Template

# Incident Report: [Brief Description]

## Summary
- Date/Time: 2024-01-15 23:30 IST
- Duration: 45 minutes
- Impact: example.com was unreachable
- Severity: High

## Timeline
- 23:30 - Alert received: example.com is down
- 23:32 - SSHed into server
- 23:33 - Found: Nginx running but PHP-FPM stopped
- 23:34 - Checked logs: OOM killer killed PHP-FPM
- 23:35 - Restarted PHP-FPM, site came back up
- 23:40 - Investigated: memory leak in custom plugin
- 00:15 - Increased server RAM, disabled problematic plugin

## Root Cause
A WordPress plugin had a memory leak, causing PHP-FPM workers to consume
all available RAM. The OOM killer terminated PHP-FPM processes.

## Resolution
1. Restarted PHP-FPM
2. Disabled the problematic plugin
3. Increased server RAM from 4GB to 8GB
4. Set pm.max_requests = 500 to restart workers periodically

## Prevention
- Set up memory usage alerting at 80%
- Added pm.max_requests to PHP-FPM config
- Scheduled weekly plugin updates and review

7.6 Final Tips for the Interview

[!TIP]
How to answer "Tell me about your experience":

"I have X years managing Linux servers running Ubuntu with Nginx/Apache, PHP-FPM, and MySQL"

"I manage Y domains across Z servers on [DigitalOcean/AWS]"

"I handle SSL certificates, DNS management, server security, and automated backups"

"I monitor server health including CPU, RAM, disk, and uptime using [tools]"

Mention specific scenarios you've resolved

[!IMPORTANT]
Key behaviors interviewers look for:

Systematic troubleshooting - Don't jump to random fixes. Check logs first

Security mindset - Always mention security considerations

Backup awareness - Always mention backup before making changes

Communication - Mention updating stakeholders during incidents

Documentation - Mention documenting changes and incidents

Proactive approach - Mention monitoring, alerts, and prevention

[!CAUTION]
Common interview mistakes to avoid:

Don't say "I would Google it" - show you know the commands

Don't say "rm -rf /" as a joke - shows carelessness

Don't say "just restart the server" for everything - shows lack of depth

Don't admit to using root for everything - shows bad security practice

Don't forget to mention testing config before restarting (nginx -t, apache2ctl configtest)

The Linux Server Administrator’s Modern Survival Guide: Cloud, Docker, Git, CI/CD and Production Infrastructure

Yashvi Kothari — Wed, 12 Aug 2026 11:29:38 +0000

The Linux Server Administrator’s Modern Survival Guide: Cloud, Docker, Git, CI/CD and Production Infrastructure

Most server administrators start with:

ssh

Then they discover that modern infrastructure is much bigger than SSH.

You need to understand cloud servers, containers, Git, CI/CD, reverse proxies, databases, caching, monitoring, backups, and disaster recovery.

The good news?

You don't need to memorize hundreds of commands.

You need to understand how the pieces fit together.

That is the difference between someone who can execute commands and someone who can operate production infrastructure.

The Modern Server Stack

A production application might look like this:

Users
   ↓
Cloudflare / CDN
   ↓
Load Balancer
   ↓
Nginx
   ↓
Application
   ↓
Redis
   ↓
Database
   ↓
Object Storage / Backups

GitHub
   ↓
CI/CD
   ↓
Deployment
   ↓
Monitoring
   ↓
Alerts

Every layer solves a different problem.

Cloud provides infrastructure.

Nginx handles web traffic.

Docker packages applications.

Git manages source code.

CI/CD automates delivery.

Redis accelerates frequently accessed data.

Prometheus/Grafana tells you what is happening.

Backups and disaster recovery make sure one failure doesn't become a catastrophe.

Learn the architecture first.

The commands become easier afterward.

1. Cloud: Stop Thinking in Terms of Servers

AWS, DigitalOcean, and Azure all provide similar fundamental building blocks.

You need to understand:

Compute
Storage
Networking
DNS
Identity
Firewalls
Load balancing
Monitoring
Backups

For example, on AWS:

EC2       → Compute
S3        → Object storage
RDS       → Managed database
Route 53  → DNS
ELB       → Load balancing
CloudFront → CDN
IAM       → Identity and access
VPC       → Networking

The important interview question isn't:

"What is EC2?"

It's:

"How would you deploy and protect an application running on EC2?"

A strong answer includes:

EC2
 ↓
Security Group
 ↓
Nginx
 ↓
Application
 ↓
Database
 ↓
S3 backups
 ↓
CloudWatch monitoring

That's infrastructure thinking.

2. Security Groups Are Not Just Another Firewall

A common interview mistake is saying:

"Security Groups are AWS firewalls."

That's technically correct, but incomplete.

A better answer:

A Security Group controls network traffic to and from AWS resources such as EC2 instances through defined inbound and outbound rules.

For example:

aws ec2 authorize-security-group-ingress \
    --group-id sg-12345 \
    --protocol tcp \
    --port 22 \
    --cidr 203.0.113.0/24

But don't blindly open SSH to:

0.0.0.0/0

Production security starts with one principle:

Allow only what is required, from only where it is required.

3. Docker: Package the Application, Not the Server

Before containers, deploying an application often meant:

Install OS
Install runtime
Install dependencies
Configure application
Configure services
Fix permissions
Hope nothing conflicts

Docker changes the model.

You package the application and its environment into an image.

Then run that image consistently.

docker pull nginx

docker run -d \
  --name my-nginx \
  -p 80:80 \
  nginx

Now understand the difference:

Image

The packaged blueprint.

Container

A running instance of that image.

Volume

Persistent storage.

Network

Communication between containers.

This distinction appears constantly in interviews.

4. Containers Are Not Virtual Machines

This question is almost guaranteed in DevOps interviews.

VM

Hardware
   ↓
Hypervisor
   ↓
Guest OS
   ↓
Application

Container

Hardware
   ↓
Host OS / Kernel
   ↓
Container Runtime
   ↓
Container
   ↓
Application

Containers generally start faster and use fewer resources because they share the host kernel.

But that doesn't mean:

"Containers are always better."

The correct engineering answer is:

Use the abstraction that fits the workload, isolation requirements, operational model, and scalability needs.

5. Docker Compose: One Application, Multiple Services

Real applications rarely contain only one process.

You might have:

Nginx
PHP
MySQL
Redis

Docker Compose lets you describe that architecture as code.

services:
  nginx:
    image: nginx:latest

  php:
    image: php:8.2-fpm

  mysql:
    image: mysql:8.0

  redis:
    image: redis:alpine

Then:

docker compose up -d

One command.

Four services.

Repeatable infrastructure.

That is the real value of containers:

consistency.

6. Git Is Infrastructure Knowledge

Git isn't just for developers.

If you're managing servers, you should understand:

git clone
git status
git pull
git fetch
git add
git commit
git push
git diff
git log
git stash
git revert

But don't just memorize commands.

Understand this:

Working Directory
       ↓
Staging Area
       ↓
Commit
       ↓
Remote Repository

And understand the difference between:

git fetch

and:

git pull

fetch downloads remote changes without modifying your current working tree.

pull generally performs a fetch followed by integration into your current branch.

That distinction matters during production troubleshooting.

7. CI/CD Turns Deployment Into a Pipeline

Without automation:

Developer
   ↓
SSH server
   ↓
git pull
   ↓
install dependencies
   ↓
restart service
   ↓
hope

With CI/CD:

Git Push
   ↓
Build
   ↓
Test
   ↓
Package
   ↓
Deploy
   ↓
Health Check
   ↓
Monitoring

A simple GitHub Actions workflow might deploy after a push to main.

But production CI/CD should ideally also include:

Automated tests
Security scanning
Build verification
Deployment approval where appropriate
Secrets management
Health checks
Rollback strategy

The goal isn't simply:

"Deploy automatically."

The goal is:

Deploy safely and repeatably.

8. Python and Node.js Need a Process Model

An application running manually from a terminal is not production architecture.

For Python:

Nginx
  ↓
Gunicorn
  ↓
Flask/Django

For Node.js:

Nginx
  ↓
Node.js

A process manager such as PM2 can help manage Node.js processes.

For Python applications, systemd plus Gunicorn is a common pattern.

The important principle is:

Your application should survive logout, crashes, and server reboots.

That means:

systemctl enable myapp

and:

Restart=always

are not cosmetic configuration.

They are operational resilience.

9. Redis: Fast Doesn't Mean Permanent

Redis is commonly used for:

Caching
Sessions
Queues
Counters
Temporary application state
Real-time workloads

A basic test:

redis-cli ping

Expected:

PONG

You should also understand dangerous commands.

For example:

redis-cli FLUSHALL

can delete all Redis data.

And:

redis-cli KEYS "*"

can become expensive on large production datasets.

A good administrator doesn't just know commands.

They know which commands not to run casually.

10. Elasticsearch: Search Is Different From a Database

Elasticsearch is designed around searching and analyzing large amounts of data.

Useful operational endpoints include:

curl localhost:9200

curl \
  "localhost:9200/_cluster/health?pretty"

curl \
  "localhost:9200/_cat/indices?v"

When troubleshooting, don't ask only:

"Is Elasticsearch running?"

Ask:

Is the service running?
Is port 9200 listening?
Is the cluster healthy?
Are nodes connected?
Are indices available?
Is disk space sufficient?
Are requests succeeding?

This is the difference between service checking and system troubleshooting.

11. Monitoring: If You Can't See It, You Can't Operate It

A server can be "up" while the application is effectively down.

For example:

CPU = 40%
RAM = 50%
Disk = 70%

Everything looks healthy.

But:

Database connections = exhausted

The application is down.

This is why production monitoring needs multiple layers.

Prometheus

Collects and stores metrics.

Grafana

Visualizes metrics.

Node Exporter

Exposes Linux system metrics.

Zabbix

Provides broader infrastructure monitoring and alerting.

The key lesson:

Monitoring should measure user-impacting health, not just server health.

12. Cloudflare Is More Than a CDN

Cloudflare can provide:

DNS
CDN
DDoS protection
WAF
TLS
Caching
Traffic filtering

A common architecture:

User
 ↓
Cloudflare
 ↓
Load Balancer
 ↓
Nginx
 ↓
Application

For production TLS, understand:

Flexible

Browser → HTTPS

Cloudflare → HTTP

Usually not desirable for secure applications.

Full

HTTPS between Cloudflare and origin, including self-signed certificates.

Full Strict

HTTPS end-to-end with a valid trusted origin certificate.

For production:

Full (Strict) is generally the preferred model.

13. Disaster Recovery Is Part of Being a Good Administrator

The worst backup is the one you've never tested.

A strong backup strategy follows the:

3-2-1 Rule

3 copies
2 different storage types
1 offsite copy

For example:

Production DB
      ↓
Local backup
      ↓
Cloud object storage
      ↓
Different region/provider

But backups alone aren't enough.

You need recovery procedures.

Ask:

"If this server disappears right now, how long until the application is running again?"

That question introduces two critical concepts:

RTO — Recovery Time Objective

How quickly must the service be restored?

RPO — Recovery Point Objective

How much data loss is acceptable?

Production infrastructure is not about preventing every failure.

It's about recovering intelligently when failure happens.

14. High Traffic Requires Architecture, Not Just Bigger Servers

When traffic increases, many administrators immediately think:

"Buy a bigger server."

That's vertical scaling.

Sometimes it works.

But eventually you need horizontal scaling.

                  Load Balancer
                 /      |      \
                /       |       \
            App 1     App 2     App 3
               \        |        /
                \       |       /
                   Database
                      |
                  Read Replica

Then add:

CDN
Caching
Redis
Connection pooling
Database replicas
Autoscaling

The goal is not to make one machine infinitely powerful.

The goal is to remove single points of failure and distribute work.

15. The Most Important Skill: Troubleshooting

Commands are easy to memorize.

Troubleshooting is harder.

Suppose a website returns:

502 Bad Gateway

Don't randomly restart everything.

Follow the path:

Client
 ↓
DNS
 ↓
Cloudflare
 ↓
Load Balancer
 ↓
Nginx
 ↓
Application
 ↓
Database

Check each layer.

For example:

dig example.com

curl -I https://example.com

systemctl status nginx

nginx -t

ss -tulpn

curl http://127.0.0.1:3000

journalctl -u myapp -n 100

docker ps

docker logs my-container

You're narrowing the failure domain.

That's what good troubleshooting looks like.

16. The Interview Mental Model

When an interviewer gives you a production problem, don't jump immediately to commands.

Use this framework:

1. Observe

What is the exact symptom?

2. Scope

Is one user affected?

One server?

One service?

The entire application?

3. Check

Look at:

Logs
Processes
Ports
CPU
Memory
Disk
Network
Dependencies
Configuration

4. Isolate

Find the first layer where reality differs from expectation.

5. Fix

Make the smallest safe change.

6. Verify

Confirm the service works.

7. Prevent

Add monitoring, automation, documentation, or configuration changes to prevent recurrence.

This framework works across:

Linux
AWS
Docker
Nginx
MySQL
Redis
Kubernetes
CI/CD

Final Lesson

You don't become a strong Linux or DevOps engineer by memorizing 1,000 commands.

You become one by understanding relationships.

Cloud
 ↓
Network
 ↓
Load Balancer
 ↓
Web Server
 ↓
Application
 ↓
Cache
 ↓
Database
 ↓
Storage
 ↓
Monitoring
 ↓
Backup
 ↓
Recovery

Then automate the boring parts.

Monitor the important parts.

Secure the dangerous parts.

Document the critical parts.

And test your recovery before production forces you to.

The best administrator isn't the person who knows the most commands.

It's the person who can look at a broken system, reduce the problem to a few possibilities, find the real cause, fix it safely, and make sure it doesn't happen again.

That is the skill worth building.

Part 6: Cloud Platforms, Docker, Git, CI/CD & Preferred Skills

6.1 Cloud Platforms (AWS, DigitalOcean, Azure)

AWS (Amazon Web Services)

# Key AWS services for server admins:
# EC2       - Virtual servers (VPS)
# S3        - Object storage (backups, static files)
# RDS       - Managed databases
# Route53   - DNS management
# ELB       - Load balancer
# CloudFront - CDN
# IAM       - User access management
# VPC       - Virtual private network

# AWS CLI setup
sudo apt install awscli
aws configure
# Enter: Access Key ID, Secret Access Key, Region, Output format

# EC2 operations
aws ec2 describe-instances                          # List all instances
aws ec2 start-instances --instance-ids i-1234567    # Start instance
aws ec2 stop-instances --instance-ids i-1234567     # Stop instance
aws ec2 reboot-instances --instance-ids i-1234567   # Reboot instance

# S3 operations (backups)
aws s3 ls                                           # List buckets
aws s3 ls s3://my-bucket/                          # List bucket contents
aws s3 cp backup.tar.gz s3://my-bucket/backups/    # Upload file
aws s3 sync /backups/ s3://my-bucket/backups/      # Sync directory
aws s3 cp s3://my-bucket/backups/backup.tar.gz ./  # Download file

# SSH to EC2
ssh -i ~/.ssh/my-key.pem ubuntu@ec2-ip-address
# Default users: ubuntu (Ubuntu), ec2-user (Amazon Linux), admin (Debian)

# Security Groups (AWS firewall)
# Configure in AWS Console or CLI:
aws ec2 authorize-security-group-ingress \
    --group-id sg-12345 \
    --protocol tcp \
    --port 22 \
    --cidr 203.0.113.0/24

DigitalOcean

# Key concepts:
# Droplets   - Virtual servers
# Spaces     - Object storage (like S3)
# Managed DB - Managed databases
# Load Balancers, Firewalls, Domains

# doctl CLI setup
sudo snap install doctl
doctl auth init                         # Enter API token

# Droplet operations
doctl compute droplet list             # List all droplets
doctl compute droplet create my-server \
    --size s-2vcpu-4gb \
    --image ubuntu-22-04-x64 \
    --region blr1                       # Create droplet

# Firewall
doctl compute firewall create \
    --name my-firewall \
    --inbound-rules "protocol:tcp,ports:22,address:0.0.0.0/0 protocol:tcp,ports:80,address:0.0.0.0/0 protocol:tcp,ports:443,address:0.0.0.0/0"

# Snapshots (backup)
doctl compute droplet-action snapshot DROPLET_ID --snapshot-name "pre-migration-backup"

# DigitalOcean console access
# Through web console when SSH is locked out

Azure

# Key services:
# Virtual Machines  - Compute
# Blob Storage      - Object storage
# Azure SQL         - Managed databases
# Azure DNS         - DNS management
# Azure CDN         - Content delivery

# Azure CLI
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
az login

# VM operations
az vm list --output table
az vm start --name myVM --resource-group myRG
az vm stop --name myVM --resource-group myRG
az vm restart --name myVM --resource-group myRG

VPS vs Cloud vs Dedicated Servers

Feature	VPS	Cloud (AWS/DO/Azure)	Dedicated
Cost	Low ($5-50/mo)	Pay-as-you-go	High ($100+/mo)
Scalability	Limited	Instant scaling	Hardware limited
Performance	Shared resources	Variable	Full resources
Management	Self-managed	Managed options	Self-managed
Use case	Small-medium sites	Scalable apps	High-performance

Interview Q&A: Cloud

Question	Answer
Difference between VPS and cloud?	VPS is a fixed virtual server. Cloud is scalable infrastructure (can add/remove resources instantly)
What is an EC2 instance?	AWS virtual server. You choose CPU, RAM, storage, OS
What is S3?	AWS object storage. Unlimited storage for files, backups, static assets
What are Security Groups in AWS?	Virtual firewall rules for EC2 instances. Control inbound/outbound traffic
How do you access a cloud server?	SSH with key pair. AWS uses .pem files, DigitalOcean uses SSH keys
What is auto-scaling?	Automatically adds/removes servers based on traffic/load

6.2 Cloudflare & CDN

Cloudflare Setup

# Setup steps:
# 1. Create Cloudflare account
# 2. Add your domain
# 3. Change nameservers at domain registrar to Cloudflare NS
# 4. Configure DNS records in Cloudflare dashboard

# Cloudflare provides:
# - CDN (cache static files at edge locations)
# - DDoS protection
# - WAF (Web Application Firewall)
# - Free SSL (Flexible, Full, Full Strict)
# - DNS management
# - Page Rules
# - Caching Rules

Cloudflare SSL Modes

Mode	Description	When to use
Off	No SSL	Never
Flexible	HTTPS browser→CF, HTTP CF→server	No SSL on origin (not recommended)
Full	HTTPS everywhere, self-signed OK	Self-signed cert on origin
Full (Strict)	HTTPS everywhere, valid cert required	Recommended with Let's Encrypt

Cloudflare Configuration Tips

# Page Rules examples:
# Force HTTPS: URL pattern *.example.com/* → Always Use HTTPS
# Cache everything: URL pattern *.example.com/static/* → Cache Level: Cache Everything

# Common Cloudflare DNS settings:
# Type | Name | Value           | Proxy Status
# A    | @    | YOUR_SERVER_IP  | Proxied (orange cloud)
# A    | www  | YOUR_SERVER_IP  | Proxied (orange cloud)
# A    | api  | YOUR_SERVER_IP  | DNS only (grey cloud - for websockets/SSH)

# Getting real visitor IP behind Cloudflare (Nginx)
# Install ngx_http_realip_module, then:
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ... (add all Cloudflare IP ranges)
real_ip_header CF-Connecting-IP;

# Apache: Install mod_remoteip
RemoteIPHeader CF-Connecting-IP

Interview Q&A: CDN

Question	Answer
What is a CDN?	Content Delivery Network. Caches content at edge servers globally for faster delivery
What does Cloudflare do?	CDN, DDoS protection, WAF, DNS, SSL, performance optimization
What is "Full (Strict)" SSL?	Encrypts traffic end-to-end and requires a valid SSL certificate on the origin server
How do you see the real client IP behind Cloudflare?	Use `CF-Connecting-IP` header. Configure `real_ip_header` in Nginx or `mod_remoteip` in Apache
How to bypass Cloudflare for debugging?	Use DNS-only mode (grey cloud) or add server IP to local hosts file
What are Cloudflare Page Rules?	URL-based rules for caching, redirects, SSL mode, and other behavior per URL pattern

6.3 Docker & Containerization

Docker Basics

# Install Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER         # Add user to docker group
# Log out and log back in

# Docker commands
docker ps                              # List running containers
docker ps -a                           # List all containers (including stopped)
docker images                          # List images
docker pull nginx                      # Download image
docker pull php:8.2-fpm                # Specific version

# Run containers
docker run -d --name my-nginx -p 80:80 nginx          # Run Nginx
docker run -d --name my-mysql -p 3306:3306 \
    -e MYSQL_ROOT_PASSWORD=secret \
    -v mysql_data:/var/lib/mysql mysql:8.0              # Run MySQL with volume

# Container management
docker start container_name
docker stop container_name
docker restart container_name
docker rm container_name               # Remove stopped container
docker rm -f container_name            # Force remove running container
docker logs container_name             # View logs
docker logs -f container_name          # Follow logs
docker exec -it container_name bash    # Shell into container
docker inspect container_name          # Detailed info

# Clean up
docker system prune -a                 # Remove unused images, containers, networks
docker volume prune                    # Remove unused volumes

Docker Compose (Multi-Container Apps)

# docker-compose.yml
version: '3.8'

services:
  nginx:
    image: nginx:latest
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./html:/var/www/html
    depends_on:
      - php
    restart: always

  php:
    image: php:8.2-fpm
    volumes:
      - ./html:/var/www/html
    restart: always

  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: secret
      MYSQL_DATABASE: myapp
      MYSQL_USER: appuser
      MYSQL_PASSWORD: apppassword
    volumes:
      - mysql_data:/var/lib/mysql
    ports:
      - "3306:3306"
    restart: always

  redis:
    image: redis:alpine
    ports:
      - "6379:6379"
    restart: always

volumes:
  mysql_data:

# Docker Compose commands
docker compose up -d                   # Start all services
docker compose down                    # Stop all services
docker compose restart                 # Restart all services
docker compose logs                    # View all logs
docker compose logs -f php             # Follow specific service logs
docker compose exec php bash           # Shell into specific service
docker compose ps                      # List services
docker compose pull                    # Pull latest images
docker compose build                   # Build images (if using Dockerfile)

Dockerfile (Custom Image)

# Dockerfile
FROM php:8.2-fpm

# Install extensions
RUN docker-php-ext-install pdo pdo_mysql mysqli mbstring

# Install additional tools
RUN apt-get update && apt-get install -y \
    curl \
    zip \
    unzip \
    && rm -rf /var/lib/apt/lists/*

# Install Composer
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

# Copy application
COPY . /var/www/html
WORKDIR /var/www/html

# Set permissions
RUN chown -R www-data:www-data /var/www/html

EXPOSE 9000
CMD ["php-fpm"]

Interview Q&A: Docker

Question	Answer
What is Docker?	Platform for building, shipping, and running apps in containers. Lightweight isolated environments
Container vs VM?	Container shares host kernel (lightweight, fast). VM has its own kernel (heavier, more isolation)
What is Docker Compose?	Tool for defining multi-container apps in YAML. Start all services with one command
What is a volume?	Persistent storage for containers. Data survives container restarts/deletion
How to debug a container?	`docker logs`, `docker exec -it container bash`, `docker inspect`
What is a Dockerfile?	Blueprint for building a custom Docker image. Defines base image, dependencies, files, commands

6.4 Git & GitHub

Git Basics for Server Admin

# Install Git
sudo apt install git

# Configure Git
git config --global user.name "Your Name"
git config --global user.email "your@email.com"

# Clone repository
git clone https://github.com/company/website.git
git clone git@github.com:company/website.git         # SSH (preferred for deployments)

# Basic workflow
git status                             # Check changes
git pull origin main                   # Pull latest changes
git add .                              # Stage all changes
git commit -m "Fix: update config"     # Commit
git push origin main                   # Push changes

# Branches
git branch                             # List branches
git branch -a                          # List all (including remote)
git checkout main                      # Switch to main
git checkout -b feature/new-feature    # Create and switch to new branch
git merge feature/new-feature          # Merge branch into current
git branch -d feature/new-feature      # Delete branch

# View history
git log --oneline -10                  # Last 10 commits
git log --oneline --graph              # Visual branch history
git diff                               # View unstaged changes
git diff --cached                      # View staged changes

# Stash changes
git stash                              # Save changes temporarily
git stash pop                          # Restore stashed changes

# Undo changes
git checkout -- file.txt               # Discard file changes
git reset --hard HEAD                  # Discard ALL uncommitted changes
git revert abc1234                     # Create new commit that undoes a commit

Deployment Workflows

# Simple Git Pull Deployment (basic)
# On server:
cd /var/www/html
git pull origin main
# Fix permissions, restart services if needed

# Deploy Script (/usr/local/bin/deploy.sh)
#!/bin/bash
set -e

APP_DIR="/var/www/html"
BRANCH="main"

echo "Starting deployment..."

cd $APP_DIR

# Pull latest code
git fetch origin
git reset --hard origin/$BRANCH

# Install dependencies
composer install --no-dev --optimize-autoloader  # PHP
# OR
npm install --production                          # Node.js

# Build assets (if applicable)
npm run build

# Clear caches
php artisan cache:clear                           # Laravel
php artisan config:cache
php artisan route:cache
php artisan view:cache

# Run migrations
php artisan migrate --force

# Fix permissions
chown -R www-data:www-data $APP_DIR
chmod -R 755 $APP_DIR

# Restart services
sudo systemctl reload php8.2-fpm
sudo systemctl reload nginx

echo "Deployment complete!"

SSH Keys for GitHub (Server Deployment)

# Generate deploy key on server
ssh-keygen -t ed25519 -C "server-deploy-key" -f ~/.ssh/github_deploy

# Add public key to GitHub repo → Settings → Deploy Keys
cat ~/.ssh/github_deploy.pub

# Configure SSH to use this key for GitHub
cat >> ~/.ssh/config << EOF
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/github_deploy
EOF

# Test connection
ssh -T git@github.com

6.5 Deploying Python & Node.js Applications

Python (Flask/Django) Deployment

# Install Python
sudo apt install python3 python3-pip python3-venv

# Create virtual environment
cd /var/www/myapp
python3 -m venv venv
source venv/bin/activate

# Install dependencies
pip install -r requirements.txt

# Install Gunicorn (WSGI server)
pip install gunicorn

# Test run
gunicorn --bind 0.0.0.0:8000 app:app                # Flask
gunicorn --bind 0.0.0.0:8000 myproject.wsgi:application  # Django

# Create systemd service
sudo nano /etc/systemd/system/myapp.service

[Unit]
Description=My Python Application
After=network.target

[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/myapp
Environment="PATH=/var/www/myapp/venv/bin"
ExecStart=/var/www/myapp/venv/bin/gunicorn --workers 3 --bind unix:myapp.sock app:app
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl start myapp
sudo systemctl enable myapp

# Nginx config for Python app
server {
    listen 80;
    server_name myapp.com;

    location / {
        proxy_pass http://unix:/var/www/myapp/myapp.sock;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /static {
        alias /var/www/myapp/static;
    }
}

Node.js Deployment

# Install Node.js (using nvm - recommended)
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
source ~/.bashrc
nvm install 20                         # Install Node.js 20 LTS
nvm use 20

# OR via apt
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install nodejs

# Deploy app
cd /var/www/nodeapp
npm install --production
npm run build                          # If build step needed

# Process Manager - PM2 (recommended for production)
sudo npm install -g pm2

pm2 start app.js --name "my-app"       # Start app
pm2 start npm --name "my-app" -- start # Start with npm start
pm2 list                               # List all apps
pm2 logs                               # View logs
pm2 restart my-app                     # Restart
pm2 stop my-app                        # Stop
pm2 delete my-app                      # Remove
pm2 monit                              # Real-time monitoring

# PM2 auto-start on reboot
pm2 startup                            # Generate startup script
pm2 save                               # Save current process list

# Nginx config for Node.js
server {
    listen 80;
    server_name nodeapp.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_cache_bypass $http_upgrade;
    }
}

6.6 Redis & Elasticsearch

Redis

# Install Redis
sudo apt install redis-server

# Configure
sudo nano /etc/redis/redis.conf
# Key settings:
# bind 127.0.0.1               # Listen on localhost only
# requirepass YourStrongPassword # Set password
# maxmemory 256mb               # Max memory usage
# maxmemory-policy allkeys-lru  # Eviction policy

sudo systemctl restart redis
sudo systemctl enable redis

# Redis CLI
redis-cli
redis-cli -a YourPassword          # With password

# Basic commands
redis-cli ping                      # Test connection → PONG
redis-cli INFO                      # Server info
redis-cli INFO memory               # Memory usage
redis-cli DBSIZE                    # Number of keys
redis-cli FLUSHALL                  # Clear all data (CAREFUL!)
redis-cli MONITOR                   # Real-time command monitoring

# Key operations
redis-cli SET mykey "Hello"
redis-cli GET mykey
redis-cli DEL mykey
redis-cli KEYS "*"                  # List all keys (don't use in production)

Elasticsearch

# Install Elasticsearch
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list
sudo apt update
sudo apt install elasticsearch

# Configure
sudo nano /etc/elasticsearch/elasticsearch.yml
# Key settings:
# cluster.name: my-cluster
# node.name: node-1
# network.host: 127.0.0.1
# http.port: 9200

sudo systemctl start elasticsearch
sudo systemctl enable elasticsearch

# Test
curl -X GET "localhost:9200"          # Check cluster health
curl -X GET "localhost:9200/_cluster/health?pretty"
curl -X GET "localhost:9200/_cat/indices?v"    # List indices

6.7 CI/CD & Automated Deployment

GitHub Actions (Simple CI/CD)

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/html
            git pull origin main
            composer install --no-dev
            php artisan migrate --force
            php artisan cache:clear
            sudo systemctl reload php8.2-fpm

Webhook-Based Deployment

# Simple webhook server for auto-deploy on git push
# Install webhook tool
sudo apt install webhook

# /etc/webhook.conf
[
  {
    "id": "deploy",
    "execute-command": "/usr/local/bin/deploy.sh",
    "command-working-directory": "/var/www/html",
    "pass-arguments-to-command": [],
    "trigger-rule": {
      "match": {
        "type": "value",
        "value": "your-webhook-secret",
        "parameter": {
          "source": "header",
          "name": "X-Hub-Signature"
        }
      }
    }
  }
]

6.8 Monitoring Tools (Grafana, Prometheus, Zabbix)

Quick Overview

Tool	Purpose	Key Feature
Prometheus	Metrics collection & storage	Pull-based, time-series DB
Grafana	Visualization & dashboards	Beautiful graphs, alerts
Zabbix	Full monitoring platform	All-in-one, agent-based
Nagios	Infrastructure monitoring	Alerting, legacy but stable
Netdata	Real-time monitoring	Zero config, instant dashboards

Prometheus + Grafana Stack (Most Popular)

# Install Node Exporter (on each server to monitor)
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
tar xvfz node_exporter-*.tar.gz
sudo mv node_exporter-*/node_exporter /usr/local/bin/

# Create systemd service
sudo nano /etc/systemd/system/node_exporter.service

[Unit]
Description=Node Exporter
After=network.target

[Service]
User=nobody
ExecStart=/usr/local/bin/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl start node_exporter
sudo systemctl enable node_exporter
# Metrics available at http://server:9100/metrics

# Install Grafana
sudo apt install -y apt-transport-https software-properties-common
wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
echo "deb https://packages.grafana.com/oss/deb stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt update
sudo apt install grafana
sudo systemctl start grafana-server
sudo systemctl enable grafana-server
# Access Grafana at http://server:3000 (default: admin/admin)

Quick Monitoring with Netdata (Easiest)

# One-line install
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
# Dashboard available at http://server:19999
# Real-time CPU, RAM, disk, network, processes - zero config

6.9 Disaster Recovery

Disaster Recovery Plan

1. DOCUMENT EVERYTHING
   - Server IPs, hostnames, OS versions
   - All software versions and configurations
   - DNS records for all domains
   - Database credentials
   - SSL certificate details
   - Contact info for providers

2. BACKUP STRATEGY (3-2-1 Rule)
   - 3 copies of all critical data
   - 2 different storage types (local + cloud)
   - 1 offsite copy (different region/provider)

3. AUTOMATED BACKUPS
   - Daily database backups (retained 30 days)
   - Weekly full server backups (retained 3 months)
   - Real-time replication for critical databases

4. RECOVERY PROCEDURES
   - Document step-by-step recovery for each service
   - Test recovery quarterly
   - Maintain runbooks for common failure scenarios

5. MONITORING & ALERTS
   - Uptime monitoring (UptimeRobot, Pingdom)
   - Resource alerts (CPU > 80%, disk > 90%, RAM > 85%)
   - SSL expiry alerts (30 days before)

Recovery Commands Quick Reference

# Server won't boot → Use provider's console/recovery mode

# Restore from backup
# 1. Provision new server
# 2. Install same software stack
# 3. Restore files from backup
tar -xzf www_backup.tar.gz -C /var/www/
# 4. Restore databases
gunzip < all_databases.sql.gz | mysql -u root -p
# 5. Restore configurations
tar -xzf configs.tar.gz -C /etc/
# 6. Fix permissions
chown -R www-data:www-data /var/www/
# 7. Restart all services
systemctl restart nginx php8.2-fpm mysql
# 8. Update DNS if IP changed
# 9. Verify SSL certificates
# 10. Test all websites and services

6.10 Handling High-Traffic Infrastructure

# Performance optimization checklist for high traffic:

# 1. Enable caching
# - OPcache for PHP (bytecode caching)
# - Redis/Memcached for application caching
# - Nginx fastcgi_cache or proxy_cache
# - Cloudflare CDN for static assets

# 2. Optimize Nginx for high traffic
worker_processes auto;
worker_connections 4096;
multi_accept on;
use epoll;

# 3. PHP-FPM tuning
pm = static                            # Or dynamic for variable traffic
pm.max_children = 100                   # Based on available RAM
# Formula: max_children = (Total RAM - Other Services RAM) / PHP avg memory

# 4. MySQL optimization
innodb_buffer_pool_size = 4G           # 60-70% of RAM for dedicated DB
innodb_log_file_size = 512M
max_connections = 500
query_cache_type = 0                   # Disabled in MySQL 8.0

# 5. OS-level tuning
# /etc/sysctl.conf
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_max_syn_backlog = 65535
fs.file-max = 65535

# Apply: sysctl -p

# 6. Connection pooling
# Use ProxySQL or PgBouncer for database connection pooling

# 7. Horizontal scaling
# Load balancer (Nginx, HAProxy, AWS ELB) distributing traffic
# Multiple app servers behind load balancer
# Read replicas for database

Interview Q&A: Preferred Skills

Question	Answer
Docker vs VM?	Docker: lightweight, shares kernel, fast startup. VM: full OS, more isolation, heavier
What is PM2?	Node.js process manager. Auto-restarts, clustering, log management
What is Gunicorn?	Python WSGI HTTP server. Runs Python apps, manages worker processes
Git pull vs Git fetch?	`pull` = fetch + merge (updates working code). `fetch` = download changes only (doesn't change files)
What is Redis used for?	In-memory cache, session storage, queues, real-time data. Very fast
What is CI/CD?	Continuous Integration (auto test) / Continuous Deployment (auto deploy). Automates the release pipeline
How to handle sudden traffic spike?	Scale vertically (bigger server), scale horizontally (more servers + load balancer), enable caching, use CDN
What is Prometheus?	Open-source monitoring system. Collects metrics via HTTP pull model, stores in time-series DB
What is Grafana?	Visualization platform. Creates dashboards from Prometheus/other data sources

Linux Server Monitoring, Backup, Security & Troubleshooting: The Practical SysAdmin Playbook

Yashvi Kothari — Wed, 12 Aug 2026 11:24:59 +0000

Linux Server Monitoring, Backup, Security & Troubleshooting Guide

Learn practical Linux server monitoring, backup, security, firewall configuration, and troubleshooting techniques with real commands and interview-ready explanations.

A server rarely fails without leaving clues.

CPU usage rises.

Memory disappears.

Disk space reaches 100%.

A service stops listening.

Nginx returns a 502.

The database refuses connections.

And suddenly someone asks:

“Can you fix production?”

Good system administrators don't panic.

They investigate.

They follow evidence.

They fix the root cause.

This guide covers the practical Linux skills every SysAdmin and DevOps engineer should know: monitoring, backup, security, and troubleshooting.

1. Monitoring: Know What Your Server Is Doing

Monitoring isn't about staring at dashboards all day.

It's about answering four questions:

Is the CPU overloaded?
Is memory exhausted?
Is disk space running out?
Is the network or application behaving abnormally?

CPU Monitoring

Start with:

uptime

You'll see something like:

load average: 0.50, 0.75, 0.80

The three values represent the 1-minute, 5-minute, and 15-minute load averages.

But there's an important interview detail:

Load average is not the same thing as CPU percentage.

A rough rule is to compare load with the number of CPU cores.

For a 4-core server:

Load < 4     → generally comfortable
Load ≈ 4     → CPUs are fully utilized
Load > 4     → work is waiting for CPU/resources

Check CPU information:

lscpu
nproc

Find CPU-heavy processes:

ps aux --sort=-%cpu | head -20

For interactive troubleshooting:

top

or:

htop

2. Memory Monitoring

Use:

free -h

The most important number isn't always free.

Look at:

available

Linux intentionally uses unused RAM for filesystem cache and buffers.

That memory can often be reclaimed when applications need it.

Check memory-heavy processes

ps aux --sort=-%mem | head -20

Check swap

swapon --show

and:

free -h

You can also monitor swap activity:

vmstat 1 5

Pay attention to si and so.

Heavy, continuous swap activity can indicate memory pressure and often results in poor performance.

3. Disk Monitoring

One of the most common production problems is surprisingly simple:

The disk is full.

Start with:

df -h

Then identify where the space went:

du -sh /* 2>/dev/null | sort -rh

Investigate /var:

du -sh /var/* 2>/dev/null | sort -rh | head -20

Logs are frequent offenders:

du -sh /var/log/* 2>/dev/null | sort -rh

Find huge files:

find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null

But disk space isn't the only resource that can run out.

Check inodes

df -i

A filesystem can have free GBs available while still being unable to create files because its inodes are exhausted.

That's a classic interview question.

4. Disk I/O

A server can have:

low CPU
plenty of RAM
plenty of disk space

…and still be painfully slow.

Why?

Disk I/O.

Use:

iostat -x 1 5

For process-level I/O:

iotop

High disk utilization or latency can point toward:

slow disks
excessive logging
database activity
backups
large file operations
overloaded storage

5. Network Monitoring

Check listening services:

ss -tlnp

Get socket statistics:

ss -s

Check network interfaces:

ip addr show
ip link show

Test connectivity:

ping google.com

Trace the route:

traceroute google.com

Or combine latency and route analysis:

mtr google.com

For HTTP:

curl -I https://example.com

This is extremely useful because it tells you whether the server is actually returning an HTTP response.

6. Logs Are Your First Investigation Tool

When something breaks, don't randomly restart everything.

Read the logs.

System logs:

sudo tail -f /var/log/syslog

Authentication logs:

sudo tail -f /var/log/auth.log

Systemd:

sudo journalctl -f

Recent logs:

sudo journalctl --since "1 hour ago"

For Nginx:

sudo tail -f /var/log/nginx/error.log

For Apache:

sudo tail -f /var/log/apache2/error.log

For MySQL:

sudo tail -f /var/log/mysql/error.log

The fastest troubleshooting path is often:

Symptom → service status → logs → dependency → configuration → resource usage

7. Backup: Assume the Server Will Fail

A backup isn't:

“I copied the website somewhere.”

A proper backup strategy considers the entire system.

You should consider backing up:

/var/www/
databases
Nginx/Apache configuration
PHP configuration
MySQL configuration
SSL certificates
cron jobs
user data
custom scripts
package information

For MySQL:

mysqldump -u root -p --all-databases --routines --triggers > all_databases.sql

Compress it:

gzip all_databases.sql

For files:

tar -czf www_backup.tar.gz /var/www/

8. Why rsync Is a SysAdmin Superpower

For large migrations, rsync is usually much more useful than repeatedly copying everything.

Example:

rsync -avz --progress /var/www/ user@newserver:/var/www/

Why?

Because rsync can synchronize only what changed.

That makes it extremely useful for:

server migrations
backups
deployments
synchronization
large file transfers

A strong interview answer:

“I prefer rsync for large transfers because it efficiently synchronizes changed files and can resume transfers.”

9. Remember the 3-2-1 Backup Rule

A practical backup strategy follows:

3 copies of your data

2 different types of storage

1 copy offsite

For example:

Production server
       ↓
Local backup
       ↓
Remote backup
       ↓
Cloud/offsite backup

And one more important principle:

A backup isn't proven until you've restored it.

Test your backups.

A backup that has never been restored is only a theory.

10. Firewall Security

On Ubuntu, UFW provides a simpler interface for firewall management.

Install:

sudo apt install ufw

Before enabling it, make sure SSH is allowed:

sudo ufw allow ssh

Then:

sudo ufw enable

Check:

sudo ufw status verbose

A typical web server may need:

sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https

Then use restrictive defaults:

sudo ufw default deny incoming
sudo ufw default allow outgoing

The principle is simple:

Don't expose services that don't need to be exposed.

11. iptables

For lower-level firewall control:

sudo iptables -L -n -v

Allow established connections:

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Allow loopback:

sudo iptables -A INPUT -i lo -j ACCEPT

Allow SSH:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Allow HTTP/HTTPS:

sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Then carefully define your default policy.

Important: Never experiment with firewall rules remotely without ensuring you won't lock yourself out.

12. Fail2ban

A firewall controls network access.

Fail2ban adds another layer by watching logs for suspicious authentication behavior and temporarily banning offending IP addresses.

Install:

sudo apt install fail2ban

Check status:

sudo fail2ban-client status

Check SSH protection:

sudo fail2ban-client status sshd

Unban an IP:

sudo fail2ban-client set sshd unbanip 1.2.3.4

Think of it as:

Logs → Detect repeated abuse → Ban IP

13. Server Hardening

A secure server starts with basic discipline.

Keep packages updated

sudo apt update
sudo apt upgrade -y

Remove unnecessary packages

sudo apt autoremove -y

Enable automatic security updates

sudo apt install unattended-upgrades

Audit permissions

find /var/www -type f -perm 0777

World-writable files deserve investigation.

Audit open ports

sudo ss -tlnp

The goal isn't:

“Close every port.”

The goal is:

“Know why every exposed port exists.”

14. Troubleshooting HTTP 500

A 500 Internal Server Error means the server encountered an application-side error.

Don't immediately blame Nginx.

Start with logs:

sudo tail -50 /var/log/nginx/error.log

or:

sudo tail -50 /var/log/apache2/error.log

If PHP is involved:

sudo tail -50 /var/log/php8.2-fpm.log

Then investigate:

application errors
permissions
PHP extensions
PHP configuration
.htaccess
application code
memory limits

The most important habit:

Check the error log first.

15. Troubleshooting 502 Bad Gateway

This error is especially common with reverse proxies.

Conceptually:

Client
  ↓
Nginx
  ↓
Backend

A 502 generally means Nginx cannot successfully communicate with the upstream.

Check:

sudo systemctl status php8.2-fpm

Check the PHP-FPM socket:

ls -la /var/run/php/php8.2-fpm.sock

For a Node.js application:

sudo lsof -i :3000

The critical question is:

“Is the backend running, and is Nginx connecting to the correct socket or port?”

16. 503 Service Unavailable

A 503 generally means the service cannot currently handle the request.

Check:

uptime

Then:

sudo systemctl status nginx
sudo systemctl status apache2
sudo systemctl status php8.2-fpm

Check connections:

ss -s

Possible causes include:

overloaded server
stopped backend
maintenance mode
rate limiting
exhausted application workers
overloaded database

17. 504 Gateway Timeout

A 504 tells a different story.

The backend may be reachable.

But it didn't respond within the required time.

Possible causes:

slow database queries
slow application code
overloaded backend
network latency
insufficient PHP workers
overly aggressive timeout settings

Check:

mysql -u root -p -e "SHOW FULL PROCESSLIST;"

Check resources:

htop
iostat

Only increase timeouts after understanding why the backend is slow.

Increasing a timeout can hide the symptom while making resource consumption worse.

18. DNS Troubleshooting

When a website doesn't open, don't immediately restart Nginx.

Check DNS.

dig example.com

Get the IP:

dig +short example.com

Query a public resolver:

dig @8.8.8.8 example.com

For mail:

dig MX example.com

For SPF:

dig TXT example.com

For DMARC:

dig TXT _dmarc.example.com

The troubleshooting chain becomes:

Domain
  ↓
DNS
  ↓
IP
  ↓
Firewall
  ↓
Port
  ↓
Web server
  ↓
Reverse proxy
  ↓
Application
  ↓
Database

That's how you avoid guessing.

19. SSL Troubleshooting

Check certificate dates:

echo | openssl s_client \
-connect example.com:443 2>/dev/null \
| openssl x509 -noout -dates

Test Let's Encrypt renewal:

sudo certbot renew --dry-run

Common causes of renewal failures:

DNS points somewhere else
port 80 blocked
HTTP challenge inaccessible
incorrect web-server configuration
certificate configuration errors

20. Database Troubleshooting

If MySQL isn't responding:

sudo systemctl status mysql

Check logs:

sudo tail -50 /var/log/mysql/error.log

Test credentials:

mysql -u root -p

Check connections:

mysql -u root -p -e "SHOW STATUS LIKE 'Threads_connected';"

Check maximum connections:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"

Don't blindly increase max_connections.

More connections require more resources.

First understand why the connections are being consumed.

21. The SysAdmin Troubleshooting Framework

When production breaks, use this sequence:

Step 1 — Confirm the symptom

curl -I https://example.com

Step 2 — Check the service

systemctl status nginx

Step 3 — Check logs

journalctl -u nginx --since "10 minutes ago"

Step 4 — Check ports

ss -tlnp

Step 5 — Check resources

uptime
free -h
df -h

Step 6 — Check dependencies

Database?

PHP-FPM?

Node.js?

Redis?

External API?

Step 7 — Check configuration

nginx -t

Step 8 — Make the smallest safe change

Avoid changing five things at once.

Step 9 — Verify

curl -I https://example.com

Step 10 — Document the root cause

A production fix is not complete until someone understands why it happened.

22. Interview Questions You Should Be Ready For

How do you check server load?

Use:

uptime

Then compare load average with available CPU cores and investigate CPU, I/O, and other bottlenecks.

How do you find what's filling the disk?

Start with:

df -h

Then:

du -sh /* 2>/dev/null | sort -rh

What's the difference between 502 and 504?

502: The proxy couldn't successfully communicate with the upstream.

504: The proxy waited for the upstream but timed out.

What is rsync?

A file synchronization tool that efficiently transfers changed data and is particularly useful for backups and migrations.

What is the 3-2-1 backup rule?

Three copies, two different storage types, one offsite.

How do you secure a Linux server?

Update the OS, minimize exposed services, configure a firewall, harden SSH, use automatic security updates, monitor authentication, use appropriate intrusion-prevention controls, and maintain tested backups.

What is your first step when a website is down?

Confirm the symptom and check the relevant service and logs before making changes.

Final Lesson

The best SysAdmins don't memorize hundreds of commands.

They understand what the commands are trying to prove.

CPU problem?
    → top / htop / uptime

Memory problem?
    → free / vmstat

Disk problem?
    → df / du / iostat

Network problem?
    → ss / ping / mtr / curl

Service problem?
    → systemctl / journalctl

Application problem?
    → application logs

Security problem?
    → auth logs / firewall / open ports

Backup problem?
    → restore test

HTTP problem?
    → status code → logs → backend → dependencies

That's the difference between knowing Linux commands and actually knowing how to operate Linux servers.

Commands are tools.

Troubleshooting is the skill.

And in production, the engineer who can calmly turn a symptom into evidence into a root cause is the engineer everyone wants on the incident call.

Part 5: Server Monitoring, Backup, Security & Troubleshooting

5.1 Server Monitoring

CPU Monitoring

# Real-time CPU usage
top                                    # Press 'P' to sort by CPU
htop                                   # Better interactive viewer (install: apt install htop)

# CPU info
lscpu                                 # CPU architecture info
nproc                                 # Number of CPU cores
cat /proc/cpuinfo                     # Detailed CPU info

# Load average
uptime                                # Shows load average (1, 5, 15 min)
# Output: load average: 0.50, 0.75, 0.80
# Rule: load average should be < number of CPU cores
# 4 cores → load < 4.0 is OK, > 4.0 means overloaded

# CPU usage snapshot
mpstat                                # CPU usage per core (install: apt install sysstat)
vmstat 1 5                            # System stats every 1 sec, 5 times
sar -u 1 5                            # CPU usage (requires sysstat)

# Top CPU-consuming processes
ps aux --sort=-%cpu | head -20

RAM Monitoring

# Memory usage
free -h                               # Human-readable memory info
# Key: Available (not Free) is what matters

# Detailed memory
cat /proc/meminfo

# Top memory-consuming processes
ps aux --sort=-%mem | head -20

# Check for memory issues
vmstat 1 5                            # Watch si/so columns (swap in/out)
# If si/so are high → server needs more RAM

# Check swap
swapon --show
free -h | grep Swap

Disk Space Monitoring

# Disk usage overview
df -h                                 # All mounted filesystems
df -h /                               # Root partition specifically

# Find what's using space
du -sh /*                             # Size of top-level directories
du -sh /var/* | sort -rh | head -20   # Largest dirs in /var
du -sh /var/log/* | sort -rh          # Log sizes
ncdu /                                # Interactive disk usage tool

# Find large files
find / -type f -size +100M -exec ls -lh {} \;  # Files > 100MB
find /var/log -name "*.log" -size +50M          # Large log files

# Check inodes
df -i                                 # Inode usage (can run out before disk space)

# Monitor disk I/O
iostat -x 1 5                         # Disk I/O stats (install: apt install sysstat)
iotop                                 # Real-time I/O by process (install: apt install iotop)

Bandwidth & Network Monitoring

# Current connections
ss -s                                 # Socket statistics summary
ss -tlnp                              # Listening ports
netstat -tlnp                         # Alternative (legacy)

# Bandwidth usage
iftop                                 # Real-time bandwidth by connection (install: apt install iftop)
nload                                 # Real-time bandwidth graph (install: apt install nload)
vnstat                                # Historical bandwidth (install: apt install vnstat)
vnstat -d                             # Daily traffic
vnstat -m                             # Monthly traffic

# Network interface info
ip addr show                          # IP addresses
ip link show                          # Network interfaces

# Test connectivity
ping google.com                       # Basic connectivity
traceroute google.com                  # Route to destination
mtr google.com                        # Combined ping + traceroute (install: apt install mtr)
curl -I https://example.com           # HTTP response headers
wget --spider https://example.com     # Check if URL is accessible

Server Uptime & Load

# System uptime
uptime
# Output: 14:30:05 up 45 days, 3:22, 2 users, load average: 0.50, 0.75, 0.80

# System info
uname -a                              # Kernel version, architecture
hostnamectl                            # Hostname, OS, kernel, architecture
cat /etc/os-release                    # OS version

# Last reboot
last reboot | head -10
who -b                                # Last boot time

# System resource summary (one command)
echo "=== UPTIME ===" && uptime && echo "=== MEMORY ===" && free -h && echo "=== DISK ===" && df -h / && echo "=== CPU LOAD ===" && cat /proc/loadavg

Log Monitoring

# System logs
sudo tail -f /var/log/syslog                    # System log (live)
sudo tail -f /var/log/auth.log                  # Authentication log
sudo journalctl -f                              # systemd journal (live)
sudo journalctl --since "1 hour ago"            # Recent logs

# Web server logs
sudo tail -f /var/log/apache2/error.log         # Apache errors
sudo tail -f /var/log/nginx/error.log           # Nginx errors
sudo tail -f /var/log/apache2/access.log        # Apache access

# PHP logs
sudo tail -f /var/log/php8.2-fpm.log            # PHP-FPM log

# MySQL logs
sudo tail -f /var/log/mysql/error.log           # MySQL errors

# Analyze access logs
# Top 10 IPs hitting the server
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# Top 10 requested URLs
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# Count 404 errors
grep " 404 " /var/log/nginx/access.log | wc -l

# Count 500 errors
grep " 500 " /var/log/nginx/access.log | wc -l

# Requests per minute/hour
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | sort | uniq -c | tail -20

Interview Q&A: Monitoring

Question	Answer
How do you check server load?	`uptime` shows load average. Compare to CPU cores: load > cores = overloaded
What's the difference between free and available memory?	Free = completely unused. Available = free + cache/buffer that can be freed. Available is what matters
How to find what's filling up disk?	`du -sh /* \
How do you monitor in real-time?	{% raw %}`htop` (CPU/RAM), `iftop` (bandwidth), `tail -f` (logs), `iostat` (disk I/O)
What is swap? When is it bad?	Overflow area on disk when RAM is full. High swap usage = server needs more RAM, causes slowness
How to identify a DDoS attack?	Check access logs for unusual traffic from single IPs, high connection count, `ss -s`

5.2 Server Backup, Restore & Migration

Full Server Backup Strategy

# What to backup:
# 1. Website files (/var/www/)
# 2. Databases (mysqldump)
# 3. Server configurations (/etc/nginx, /etc/apache2, /etc/php, /etc/mysql)
# 4. SSL certificates (/etc/letsencrypt)
# 5. Cron jobs (crontab -l)
# 6. User home directories
# 7. Custom scripts

# Full website backup script
#!/bin/bash
DATE=$(date +%Y-%m-%d)
BACKUP_DIR="/backups/$DATE"
mkdir -p $BACKUP_DIR

# 1. Backup website files
tar -czf $BACKUP_DIR/www_backup.tar.gz /var/www/

# 2. Backup all databases
mysqldump -u root -p'password' --all-databases --routines --triggers | gzip > $BACKUP_DIR/all_databases.sql.gz

# 3. Backup configs
tar -czf $BACKUP_DIR/configs.tar.gz /etc/nginx/ /etc/apache2/ /etc/php/ /etc/mysql/ /etc/letsencrypt/

# 4. Backup crontabs
crontab -l > $BACKUP_DIR/root_crontab.txt
crontab -u www-data -l > $BACKUP_DIR/www-data_crontab.txt 2>/dev/null

# 5. Server info
dpkg --get-selections > $BACKUP_DIR/installed_packages.txt
ip addr > $BACKUP_DIR/network_config.txt
cat /etc/hosts > $BACKUP_DIR/hosts.txt

# 6. Sync to remote/cloud
rsync -avz $BACKUP_DIR/ backup@remote-server:/offsite-backups/$DATE/
# OR to S3:
# aws s3 sync $BACKUP_DIR/ s3://my-backups/$DATE/

# 7. Cleanup old backups (keep 30 days)
find /backups/ -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;

echo "Backup completed: $BACKUP_DIR"

Server Migration Steps

# Step-by-step server migration checklist:

# 1. PREPARE NEW SERVER
sudo apt update && sudo apt upgrade -y
# Install all required software: nginx, php, mysql, etc.
# Configure same PHP version and extensions

# 2. BACKUP OLD SERVER (everything listed above)

# 3. TRANSFER FILES
# Option A: rsync (best for large transfers, supports resume)
rsync -avz --progress -e "ssh -p 22" /var/www/ newserver:/var/www/

# Option B: scp
scp -r /var/www/ user@newserver:/var/www/

# Option C: tar + transfer
tar -czf /tmp/www_backup.tar.gz /var/www/
scp /tmp/www_backup.tar.gz user@newserver:/tmp/
# On new server: tar -xzf /tmp/www_backup.tar.gz -C /

# 4. TRANSFER DATABASES
# On old server:
mysqldump -u root -p --all-databases | gzip > /tmp/all_db.sql.gz
scp /tmp/all_db.sql.gz user@newserver:/tmp/
# On new server:
gunzip < /tmp/all_db.sql.gz | mysql -u root -p

# 5. TRANSFER CONFIGURATIONS
scp -r /etc/nginx/sites-available/ user@newserver:/etc/nginx/sites-available/
scp -r /etc/letsencrypt/ user@newserver:/etc/letsencrypt/
# Copy php.ini, mysql configs, etc.

# 6. FIX PERMISSIONS
sudo chown -R www-data:www-data /var/www/
sudo chmod -R 755 /var/www/

# 7. UPDATE DNS (point to new server IP)
# Lower TTL first (300 seconds), wait for propagation
# Change A records to new server IP
# Wait for propagation (check with dig @8.8.8.8 domain.com)

# 8. VERIFY
# Test all websites
# Test database connections
# Test SSL certificates
# Test email delivery
# Monitor logs for errors

# 9. KEEP OLD SERVER running for a few days as fallback

Interview Q&A: Backup & Migration

Question	Answer
What should be included in a server backup?	Website files, databases, configs (nginx/apache/php/mysql), SSL certs, crontabs, custom scripts
What is rsync? Why use it?	File synchronization tool. Only transfers changed files, supports resume, efficient for large transfers
How often should you backup?	Daily for databases, weekly for full backups. Keep 30 days of daily + 3 months of weekly
What is the 3-2-1 backup rule?	3 copies of data, on 2 different media types, 1 offsite (cloud/remote)
How do you minimize downtime during migration?	Sync data before DNS change, lower TTL, test on new server first, keep old server as fallback
How do you verify a backup is good?	Periodically do test restores to a staging server

5.3 Firewall & Server Security

UFW (Uncomplicated Firewall) - Ubuntu Default

# Install and enable
sudo apt install ufw
sudo ufw enable                        # CAREFUL: make sure SSH is allowed first!

# Check status
sudo ufw status
sudo ufw status verbose
sudo ufw status numbered               # Show rule numbers

# Allow common services
sudo ufw allow ssh                     # Port 22
sudo ufw allow 2222/tcp                # Custom SSH port
sudo ufw allow http                    # Port 80
sudo ufw allow https                   # Port 443
sudo ufw allow 3306/tcp               # MySQL (only if needed remotely)

# Allow from specific IP
sudo ufw allow from 192.168.1.100
sudo ufw allow from 192.168.1.100 to any port 22  # SSH from specific IP only
sudo ufw allow from 192.168.1.0/24 to any port 3306  # MySQL from subnet

# Deny rules
sudo ufw deny 23                       # Deny telnet
sudo ufw deny from 1.2.3.4             # Block specific IP

# Delete rules
sudo ufw delete allow 3306/tcp
sudo ufw delete 5                      # Delete rule by number

# Rate limiting (brute force protection)
sudo ufw limit ssh                     # Limit SSH connections (6 in 30 seconds)

# Default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Reset all rules
sudo ufw reset

# Logging
sudo ufw logging on
sudo ufw logging medium

iptables (Advanced Firewall)

# List rules
sudo iptables -L -n -v
sudo iptables -L -n --line-numbers

# Allow SSH
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow HTTP/HTTPS
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow established connections
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow loopback
sudo iptables -A INPUT -i lo -j ACCEPT

# Drop everything else
sudo iptables -A INPUT -j DROP

# Block specific IP
sudo iptables -A INPUT -s 1.2.3.4 -j DROP

# Rate limit SSH
sudo iptables -A INPUT -p tcp --dport 22 -m connlimit --connlimit-above 3 -j DROP

# Save rules (persist after reboot)
sudo apt install iptables-persistent
sudo netfilter-persistent save

Fail2ban (Brute Force Protection)

# Install
sudo apt install fail2ban

# Configure
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

# Key settings in jail.local:
[DEFAULT]
bantime = 3600                         # Ban for 1 hour
findtime = 600                         # Within 10 minutes
maxretry = 5                           # After 5 failed attempts
destemail = admin@example.com
action = %(action_mwl)s                # Ban + email with whois + logs

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

[apache-auth]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache2/error.log

[nginx-http-auth]
enabled = true
port = http,https
filter = nginx-http-auth
logpath = /var/log/nginx/error.log

# Service management
sudo systemctl start fail2ban
sudo systemctl enable fail2ban
sudo systemctl status fail2ban

# Check banned IPs
sudo fail2ban-client status
sudo fail2ban-client status sshd

# Unban an IP
sudo fail2ban-client set sshd unbanip 1.2.3.4

Server Hardening Checklist

# 1. Keep system updated
sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y

# 2. Automatic security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# 3. SSH hardening (see Part 1 SSH section)

# 4. Disable root login
sudo passwd -l root                   # Lock root password

# 5. Remove unnecessary packages
sudo apt remove telnet ftp             # Remove insecure services

# 6. Secure /tmp
# Mount /tmp with noexec option

# 7. Security headers (in Nginx/Apache)
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
add_header Content-Security-Policy "default-src 'self'";
add_header Referrer-Policy "strict-origin-when-cross-origin";

# 8. File permissions audit
find /var/www -type f -perm 0777       # Find world-writable files
find /var/www -type d -perm 0777       # Find world-writable directories

# 9. Monitor auth logs
sudo tail -f /var/log/auth.log
sudo grep "Failed password" /var/log/auth.log | tail -20

# 10. Check for rootkits
sudo apt install rkhunter
sudo rkhunter --check

# 11. Audit open ports
sudo ss -tlnp                         # Should only show expected ports
sudo nmap -sT localhost                # Scan own ports

Interview Q&A: Security

Question	Answer
How do you secure a new server?	Update OS, configure firewall (UFW), SSH hardening, fail2ban, disable root, security headers, automatic updates
What is fail2ban?	Monitors logs for failed auth attempts, bans IPs after threshold. Prevents brute force
What is UFW?	Uncomplicated Firewall - simplified interface for iptables on Ubuntu
What ports should be open on a web server?	22 (or custom SSH), 80 (HTTP), 443 (HTTPS). Everything else blocked
How to check for unauthorized access?	Check `/var/log/auth.log`, check `last` command, check running processes, audit open ports
What are security headers?	HTTP headers that protect against XSS, clickjacking, content sniffing. Set in web server config

5.4 Troubleshooting HTTP Errors

500 Internal Server Error

# Most common causes & fixes:

# 1. Check error logs FIRST
sudo tail -50 /var/log/apache2/error.log
sudo tail -50 /var/log/nginx/error.log
sudo tail -50 /var/log/php8.2-fpm.log

# 2. PHP errors
# Check php.ini:
display_errors = On   # Temporarily (NEVER in production)
# Or check PHP error log
tail -f /var/log/php/error.log

# 3. .htaccess issues (Apache)
# Temporarily rename .htaccess to test:
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak
# If site works → .htaccess has syntax error

# 4. File permissions
ls -la /var/www/html/
# Files should be 644, dirs 755, owned by www-data

# 5. PHP memory limit
# Error: "Allowed memory size exhausted"
# Fix in php.ini: memory_limit = 256M

# 6. Missing PHP extensions
php -m  # Check if required extensions are installed

502 Bad Gateway

# Means: Nginx/Apache can't reach the backend (PHP-FPM, Node.js, etc.)

# 1. Check if PHP-FPM is running
sudo systemctl status php8.2-fpm

# 2. Check PHP-FPM socket
ls -la /var/run/php/php8.2-fpm.sock
# If missing → restart PHP-FPM

# 3. Check Nginx config matches PHP-FPM socket
# Nginx should have: fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
# PHP-FPM should have: listen = /var/run/php/php8.2-fpm.sock

# 4. Check backend app (Node.js, Python)
# Is the app running? Is it on the right port?
sudo lsof -i :3000                    # Check if app is listening

# 5. Check PHP-FPM pool config
# Too few workers? Increase pm.max_children

# 6. Check memory - OOM killer may have killed PHP-FPM
sudo dmesg | grep -i "out of memory"
sudo dmesg | grep -i "oom"

503 Service Unavailable

# Means: Server is overloaded or in maintenance

# 1. Check server load
uptime
htop

# 2. Check if service is running
sudo systemctl status nginx
sudo systemctl status apache2
sudo systemctl status php8.2-fpm

# 3. Check connections
ss -s                                 # Socket summary
ss -tlnp | grep :80                   # Connections on port 80

# 4. Check rate limiting
# Nginx: check if limit_req is too aggressive
# Cloudflare: check if WAF is blocking

# 5. Database overloaded
mysql -u root -p -e "SHOW PROCESSLIST;"
# Too many connections? Kill stuck queries

504 Gateway Timeout

# Means: Backend took too long to respond

# 1. Increase timeout in Nginx
proxy_read_timeout 300;
proxy_connect_timeout 300;
fastcgi_read_timeout 300;

# 2. Increase timeout in Apache
ProxyTimeout 300
Timeout 300

# 3. Increase PHP execution time
# php.ini: max_execution_time = 300

# 4. Check for slow database queries
mysql -u root -p -e "SHOW FULL PROCESSLIST;"
# Check slow query log

# 5. Check if server is overloaded
htop                                   # High CPU/RAM usage?
iostat                                 # High disk I/O?

DNS Issues Troubleshooting

# 1. Domain not resolving
dig example.com                        # Check A record
dig @8.8.8.8 example.com              # Check with Google DNS
ping example.com                       # Test connectivity

# 2. Wrong IP
dig +short example.com                 # What IP is it resolving to?
# Update A record in DNS provider

# 3. Propagation delay
# Check propagation: dnschecker.org
# Solution: Wait, or flush local DNS cache
sudo systemd-resolve --flush-caches

# 4. Subdomain not working
dig subdomain.example.com              # Check if A/CNAME record exists
# Add appropriate record in DNS

# 5. Email not working
dig MX example.com                     # Check MX records
dig TXT example.com                    # Check SPF/DKIM

SSL Issues Troubleshooting

# 1. Certificate expired
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
sudo certbot renew

# 2. Mixed content (HTTP on HTTPS page)
# Fix URLs in code/database to use HTTPS
# WordPress: update site URL in wp_options table

# 3. Certificate doesn't match domain
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer
# Reissue certificate for correct domain

# 4. Let's Encrypt renewal failing
sudo certbot renew --dry-run          # Test renewal
# Common issues:
# - Port 80 blocked (needs to be open for HTTP challenge)
# - DNS not pointing to this server
# - .well-known/acme-challenge not accessible

Database Connectivity Issues

# 1. Can't connect to MySQL
sudo systemctl status mysql            # Is it running?
sudo tail -20 /var/log/mysql/error.log # Check error log

# 2. Access denied
mysql -u root -p                       # Test credentials
# Check user@host: SELECT user, host FROM mysql.user;

# 3. Too many connections
mysql -u root -p -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"
# Increase max_connections if needed

# 4. MySQL crashed
sudo systemctl restart mysql
sudo tail -50 /var/log/mysql/error.log
# Check for OOM: sudo dmesg | grep -i mysql

Email/SMTP Troubleshooting

# 1. Check mail queue
mailq                                  # View pending emails
sudo postqueue -f                      # Flush/retry mail queue
sudo postsuper -d ALL                  # Delete all queued mail

# 2. Check mail logs
sudo tail -f /var/log/mail.log
sudo grep "status=bounced" /var/log/mail.log | tail -20

# 3. Test SMTP
telnet mail.example.com 25             # Test SMTP connection
openssl s_client -connect mail.example.com:587 -starttls smtp  # Test STARTTLS

# 4. Check SPF/DKIM/DMARC
dig TXT example.com                    # SPF
dig TXT default._domainkey.example.com # DKIM
dig TXT _dmarc.example.com            # DMARC

# 5. Test email delivery
echo "Test" | mail -s "Test Email" user@example.com

# 6. Check if port 25/587 is blocked
sudo ss -tlnp | grep -E "25|587"
sudo ufw status | grep -E "25|587"

# 7. Check blacklist status
# Use: mxtoolbox.com/blacklists.aspx
# Check reverse DNS: dig -x YOUR_SERVER_IP

Interview Q&A: Troubleshooting

Question	Answer
First thing you do when a site is down?	Check if server is reachable (ping), check web server status, check error logs
How to diagnose a 500 error?	Check error logs (apache/nginx/php), check permissions, check .htaccess, check PHP config
Difference between 502 and 504?	502: backend unreachable/crashed. 504: backend is running but too slow to respond
Website is slow. How to diagnose?	Check server load (htop), check slow query log, check PHP-FPM status, check disk I/O, check network
Server ran out of disk space. Quick fix?	Find large files (`du -sh`), clean old logs, clear apt cache (`apt clean`), remove old backups
How to handle DDoS?	Enable Cloudflare, configure rate limiting, use fail2ban, block suspicious IPs, enable UFW rate limiting
How to check if emails are being delivered?	Check mail logs, verify SPF/DKIM/DMARC records, check blacklists, test with mxtoolbox

DEV Community: Yashvi Kothari

Lovable Data Leak 2026: 24,664 AI Apps Exposed 80,000+ User Records via Supabase

How a Marketing Manager Deployed a Production Data Leak in 4 Minutes (And Why Your Scanner Missed It)

The Anatomy of a 15-Minute Breach

The 4 Silent Misconfigurations of Rapid PaaS Deployments

1. Public Production URLs Without Authentication

2. Secrets Stored as Readable Config Instead of Secret

3. The SAML Illusion (Connected vs. Enforced)

4. Zombie Access Tokens

The CloudOps Blind Spot: Why Single-Team Dashboards Fail

The Engineering Takeaway: Audit Metadata, Not Just Code

Your Monday Morning CloudOps Checklist:

What Is the Storm-3168 Azure Service Principal Attack and How Do You Detect It?

Binance Hack: DevSecOps Lessons from the $6.34B Breach

Act I: The Anatomy of a $6.34 Billion Breach

Act II: When the Kill Switch Fails

Act III: The CloudOps & DevSecOps Playbook

1. Contain the Blast Radius of Internal AI Tools

2. Long-Lived Tokens on Laptops Are Ticking Time Bombs

3. Move Local Dev Environments out of User-Owned Host Paths

4. Package Managers Need an Allowlist, Not Search Engines

5. Game-Day Your "Un-Revocable" Architecture

The Takeaway

29 Notable Cloud & DevOps Professionals from India to Follow in 2026

Phase 1 HTML

Example:

Beautiful Apartment

[ Reserve ]

Just HTML.

HTML Comments

HTML Comment Syntax

Multiline Comments

Are HTML Comments Completely Hidden?

Important

Practice Exercise

Task

Lab Note

Tags in HTML

Say Hello to HTML Elements

Your First HTML Element

Opening Tag

Closing Tag

Complete the Challenge

Create a Headline with the h2 Element

Understanding the h2 Element

Complete the Challenge

Anchor Tag

The href Attribute

Block-Level and Inline Tags in HTML

Creating a Paragraph

Complete the Challenge

HTML Naming Convention

Why HTML tags exist?

we can attach event handlers. when we click on button turn h1 tag to red or h2 tag should disappear or h3 tag should change to bigger font size.

Image Tag

Video (video) tag

for youtube link copy embedded snippet whole iframe thing.

Table (table) tag

Create a Text Field

Creating a Text Input

Complete the Challenge

Add Placeholder Text to a Text Field

Complete the Challenge

Declare the Doctype of an HTML Document

Declare the HTML Version

Complete the Challenge

Hello World

Complete the Challenge

Hello World

1. The Basic Structure — html, head, body

2. Headings — h1 through h6

3. Paragraph — p

4. Division & Span — div and span

<div> — Block-level container

<span> — Inline container

5. Links — a (Anchor)

6. Images — img

7. Lists — ul, ol, li

Unordered List (bullet points)

Ordered List (numbered)

2. Secrets Stored as Readable `Config` Instead of `Secret`

Create a Headline with the `h2` Element

Understanding the `h2` Element

The `href` Attribute

1. The Basic Structure — `html`, `head`, `body`

2. Headings — `h1` through `h6`

3. Paragraph — `p`

4. Division & Span — `div` and `span`

`<div>` — Block-level container

`<span>` — Inline container

5. Links — `a` (Anchor)

6. Images — `img`

7. Lists — `ul`, `ol`, `li`

8. Tables — `table`

9. Forms — `form`, `input`, `textarea`, `select`, `button`, `label`

The `<form>` container

`<label>` — Describes a form field

`<input>` — The Swiss Army Knife

`<textarea>` — Multi-line text

`<select>` — Dropdown

`<button>` — A clickable button

`id` vs `class`