Study Guide · Bucket 1 of 7

Foundation & Security

Yeh bucket wo ground hai jispe baaki sab 6 buckets khade honge. Account setup, governance, aur IAM — bina isko strong kiye aage kuch bhi galat direction mein ja sakta hai.

Context
Real talk: koi bhi service touch karne se pehle, tumhe samajhna padega ki cloud kaam kaise karta hai aur tumhara account kis tarah organize aur secure hota hai. Yeh bucket 'boring' lagta hai lekin har interview aur har production incident isi foundation pe wapas aata hai.

Pre-Foundation Conceptsconcepts — not a service

What
Cloud ko samajhne ke liye 4 building-block concepts: SDLC (Software Delivery Life Cycle), Cloud Deployment Models (Public / Private / Hybrid / Multi-cloud), Cloud Service Models (IaaS / PaaS / SaaS), aur Regions & Availability Zones (AZs) — yeh physical data centers hote hain jahan tumhara sab kuch actually run hota hai.
Why
Interview mein jab poochha jaata hai 'AWS kya hai' ya 'IaaS vs PaaS vs SaaS mein farak kya hai', yeh wahi base hai. Region/AZ samajhna isliye zaroori hai kyunki latency, compliance (data kahan store ho raha hai), aur high-availability design — sab isi pe depend karta hai.
How
Ek Region ek geographic area hai (e.g. ap-south-1 = Mumbai). Har Region ke andar multiple Availability Zones hote hain (physically alag data centers, but low-latency network se connected) — taaki agar ek AZ fail ho jaaye, doosra chalta rahe.
Skill
Koi coding nahi — sirf conceptual clarity chahiye.
  • Public / Private / Hybrid / Multi-cloud
  • IaaS vs PaaS vs SaaS
  • Region vs Availability Zone
  • Why multi-AZ = high availability

Day-1 Account SetupAWS Console

What
AWS account banana, root user secure karna (MFA), billing alerts set karna, aur ek IAM admin user banana taaki root account daily use ke liye na ho.
Why
Root account = master key to everything. Agar yeh compromise hua, poora infrastructure gaya. MFA aur billing alerts din-1 se on karna non-negotiable habit hai — warna ek chhota mistake $$$$ ka bill bana sakta hai.
How
aws.amazon.com pe sign up -> email/card verify -> Free Tier + credits mil jaate hain -> Root user pe MFA enable (Google Authenticator se) -> Billing -> Billing Preferences -> alerts enable -> IAM -> naya admin user banao aur uske through hi kaam karo, root se nahi.
Skill
Console clicks only — koi coding requirement nahi.
  • Root user vs IAM user
  • MFA
  • Billing alerts / budgets
  • Free Tier limits

AWS Organizations & Control Towergovernance

What
AWS Organizations se ek 'management account' multiple AWS accounts (dev/staging/prod, ya alag teams) ko centrally control kar sakta hai. Control Tower isi ko automate karta hai — guardrails aur security best-practices preconfigured deta hai.
Why
Real companies ek account mein sab kuch nahi rakhte — dev/staging/prod alag accounts mein isolate karte hain taaki ek galti dusre environment ko na todhe, aur billing bhi alag-alag track ho sake.
How
Learning ke liye tumhe sirf ek account chahiye — bas samajh lo ki yeh exist karta hai aur enterprise mein kaise use hota hai.
Skill
Sirf awareness chahiye — hands-on abhi zaroori nahi.
  • Management account
  • Multi-account strategy
  • Guardrails
Real org mein
Real org mein: naya joining hote hi tumhe ek IAM role milega jo ek specific AWS account (e.g. 'dev' account) tak limited hoga — tum 'prod' account tak directly nahi pahunch paoge. Yeh Organizations ki wajah se hota hai.

IAM (Identity and Access Management)core service

What
Controls karta hai ki tumhare AWS account mein kaun kya kar sakta hai. 4 core pieces: Users (log-in karne wale log), Groups (same-permission users ka collection), Roles (services/apps ke liye identity — no hardcoded credentials), Policies (JSON documents jo Allow/Deny define karte hain).
Why
Har single AWS action — instance launch karna ho, S3 pe upload karna ho, database banana ho — permission maangta hai. IAM na samjha toh na kuch launch hoga, na kisi security incident ko debug kar paoge.
How
Classic pattern: EC2 ko S3 access chahiye -> (1) IAM Role banao -> (2) us role pe ek Policy attach karo jo S3 permissions deti hai -> (3) role ko EC2 instance pe attach karo. Ab EC2 instance khud ek 'user' ki tarah S3 access kar sakta hai — koi access key hardcode nahi hui.
Skill
JSON policies padhna/likhna aana chahiye — basic level.
  • Users vs Roles (sabse common interview confusion)
  • Groups
  • JSON policy structure
  • Principle of least privilege
Real org mein
Real org mein tumhe kabhi root/admin access seedha nahi milta. Tumhe ek Role assign hota hai with specific policies — jitna kaam ke liye zaroori utna hi access (least privilege). Agar zyada access chahiye, ticket raise karna padta hai.

Secrets Manager & Parameter Storesecurity

What
Secrets Manager: encrypted storage for DB credentials, API keys — with automatic secret rotation (paid service). Parameter Store (Systems Manager): free alternative — general config + simple secrets ke liye.
Why
Credentials ko code/script mein hardcode karna sabse common security mistake hai (GitHub pe accidentally push ho jaana). Secrets ko ek encrypted vault mein rakhna aur code se sirf reference karna — yeh industry standard hai.
How
Secrets Manager mein secret create karo (e.g. DB password) -> application code us secret ko naam se fetch karta hai (via SDK) -> rotation automatically ho sakta hai bina app restart kiye.
Skill
SDK se secret fetch karna (Boto3 / AWS SDK) samajhna chahiye.
  • Never hardcode secrets
  • Rotation
  • Parameter Store = free, Secrets Manager = paid + rotation
Key Tasks — is bucket ko 'done' maanne se pehle
  • AWS account banao aur root par MFA enable karo
  • Billing alarm set karo (chahe notifications pasand na ho, phir bhi karo)
  • IAM admin user banao — root se kaam karna band karo
  • Ek IAM role banao jo S3 access deta ho, aur EC2 ko attach karo (concept practice)
  • Users vs Roles ka farak clearly explain kar sako
Next →Compute & Containers