Welcome to Day 02! After setting the foundation, today we dive into the “Big Three” of infrastructure: Security (AuthN/AuthZ), the Linux Foundation, and AWS Global Infrastructure.

---

1. Authentication vs. Authorization: The Security Handshake

In a DevOps world, we don’t just secure people; we secure pipelines, containers, and APIs.

Core Definitions

• Authentication (AuthN) → Who are you? (Verifying identity)
• Authorization (AuthZ) → What can you do? (Verifying permissions)

Real-World Example:

Logging into the AWS Console is Authentication. Being restricted to “Read-Only” access so you can’t delete an S3 bucket is Authorization.

Key Mechanisms in DevOps

1. Human Auth: SSO (Single Sign-On) via corporate identity providers (like Okta or Azure AD) allows developers to access AWS/Azure without multiple passwords.
2. Machine-to-Machine (M2M): This is critical. CI/CD pipelines use IAM Roles and Short-lived tokens instead of hardcoded passwords to deploy code.
3. Token-Based Auth: Modern APIs use OAuth 2.0 or JWT (JSON Web Tokens). Tokens expire, reducing the “blast radius” if a credential is leaked.
4. Secrets Management: The Golden Rule of DevOps: Never store secrets in Git. Use tools like HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets.

---

2. Why Linux is the Heart of DevOps

If you want to master DevOps, you must master Linux. Here is why it is the industry standard:

• Cloud Native: The majority of AWS, GCP, and Azure run on Linux.
• Automation: Linux is built for the CLI. Bash scripting allows us to automate repetitive tasks that a GUI simply cannot handle.
• Containerization: Technologies like Docker and Kubernetes are built on Linux kernel features (Cgroups and Namespaces). You cannot truly understand containers without understanding Linux.
• Consistency: Using Linux-based containers eliminates the “Works on my machine” problem. The environment in your local Docker container is identical to the one in Production.

---

3. Client-Server Architecture in the Cloud

In the modern cloud, the simple Client-Server model has evolved into a highly distributed system.

The Evolution:

1. Simple: Client (Browser) $\leftrightarrow$ Server (App).
2. 3-Tier: Client $\leftrightarrow$ App Server $\leftrightarrow$ Database.
3. Cloud-Scale:
   • Load Balancers: Distribute traffic across multiple servers.
   • Kubernetes/Docker: Orchestrate services in pods.
   • Database Clusters: Ensure data is always available.

Architecture  
=========

    Client (Browser)
          |
          v
    [ Load Balancer ]
          |
    +-----+-----------+
    | Kubernetes Pods | (Dockerized Apps)
    +-----+-----------+
          |
    [ Managed Database ] (e.g., AWS RDS)

---

4. AWS Global Infrastructure: Regions vs. AZs

Designing for the cloud means designing for failure. AWS provides two layers of isolation:

A. AWS Regions (Geographic Isolation)

A Region is a physical location in the world (e.g., Mumbai – ap-south-1).

• Selection Criteria: Latency (closeness to users), Compliance (legal data residency), and Cost.
• Independence: Regions are separate. If one goes down, the others remain unaffected.

B. Availability Zones (Fault Isolation)

An AZ is one or more discrete data centers within a Region (e.g., ap-south-1a).

• High Availability: We deploy apps across multiple AZs. If a fire or power outage hits one data center (AZ), your app stays online in the second AZ.

Feature	Scope	Use Case
Availability Zone	Data Center Level	High Availability (HA)
Region	Geographic Level	Disaster Recovery (DR)