AWS interview questions

AWS Shared Responsibility Model divides security duties between AWS and the customer. AWS is responsible for (Security OF the cloud): - Physical security of data centers - Hardware, networking, and virtualization layer - Managed service underlying infrastructure (e.g., RDS OS patching) - Global infrastructure (Regions, AZs, Edge Locations) Customer is responsible for (Security IN the cloud): - Data encryption (at rest and in transit) - IAM users, roles, policies — access management - OS patching on EC2 instances - Application-level security - Network configuration (VPC, Security Groups, NACLs) - Client-side data encryption The line shifts based on service type: - IaaS (EC2): customer manages OS upward - PaaS (RDS): AWS manages OS/engine, customer manages data and access - SaaS (S3): AWS manages almost everything; customer manages data and bucket policies

Region: a geographic area containing multiple Availability Zones. Examples: ap-south-1 (Mumbai), us-east-1 (N. Virginia). AWS has 30+ regions globally. Availability Zone (AZ): one or more physically separate data centers within a region, connected by low-latency fiber. Independent power, cooling, and networking. Failures in one AZ don't affect others. Why they matter: - High Availability: deploy resources across multiple AZs. If AZ-a fails, AZ-b and AZ-c keep serving traffic. Multi-AZ is the standard for production. - Disaster Recovery: deploy across multiple Regions for regional outage resilience (e.g., entire Mumbai region goes down → failover to Singapore) - Data Residency: some data (financial, healthcare) must stay in specific countries — choose Region accordingly. Mumbai region keeps data in India. - Latency: choose the Region closest to your users India-relevant: ap-south-1 (Mumbai) is the primary region. ap-south-2 (Hyderabad) was added in 2022 for more options. Best practice for production: always use Multi-AZ deployments (RDS Multi-AZ, ALB spanning multiple AZs, ECS tasks across AZs).

IAM (Identity and Access Management): controls authentication and authorization for AWS resources. Global service — not region-specific. Users: individual identities (human or programmatic). Created for developers, CI/CD pipelines. Avoid using root account for daily tasks. Groups: collection of IAM users. Attach policies to a group → all members inherit those permissions. E.g., "Developers" group with S3 and EC2 read access. Roles: identities with policies that can be assumed by AWS services, applications, or users. No permanent credentials — roles issue temporary security tokens. Example: EC2 instance assumes a role to access S3 without hardcoding access keys. Lambda function assumes a role to write to DynamoDB. Policies: JSON documents defining allowed/denied actions on resources. { "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::my-bucket/*" } Types of policies: - AWS Managed: pre-built by AWS (AmazonS3ReadOnlyAccess) - Customer Managed: you create and manage them - Inline: directly attached to one user/group/role Best practices: principle of least privilege, use roles not access keys for EC2/Lambda, enable MFA on root account, rotate access keys regularly.

EC2 (Elastic Compute Cloud): virtual servers (instances) in the cloud. You choose OS, CPU, RAM, storage, and networking. Instance types (families): - t3/t4g: burstable, general purpose — dev/test, low-traffic apps - m6i/m7i: balanced CPU/RAM — web servers, app servers - c6i/c7i: compute-optimized — CPU-intensive workloads, batch processing - r6i/r7i: memory-optimized — in-memory databases, Redis at scale - p3/p4: GPU — ML training, deep learning - i3/i4i: storage-optimized — high I/O, NoSQL databases AMI (Amazon Machine Image): a template capturing the OS, pre-installed software, and configuration. Used to launch new instances. You can use AWS-provided AMIs (Amazon Linux, Ubuntu), marketplace AMIs, or create custom AMIs from running instances. Pricing models: - On-Demand: pay per second/hour, no commitment. Highest cost. Use for unpredictable workloads. - Reserved Instances (RI): 1 or 3 year commitment, up to 72% discount. Best for steady-state workloads. - Savings Plans: commitment to $ spend/hour, flexible across instance types. More flexible than RI. - Spot Instances: bid on spare capacity, up to 90% discount. Can be interrupted with 2-min notice. Use for fault-tolerant batch jobs, ML training. - Dedicated Hosts: physical server for your use — compliance/licensing requirements. Key: Spot for batch/ML, Reserved for production baseline, On-Demand for variable traffic.

S3 (Simple Storage Service): object storage service. Stores unlimited objects (files) up to 5TB each. 99.999999999% (11 nines) durability. Globally unique bucket names. Key concepts: - Bucket: container for objects. Region-specific. - Object: file + metadata + key (path-like name) - Versioning: keep multiple versions of an object - Static website hosting: serve HTML/CSS/JS directly from S3 Storage Classes (choose based on access frequency and cost): - S3 Standard: frequently accessed data, millisecond access, highest cost - S3 Intelligent-Tiering: auto-moves objects between tiers based on access patterns. Best when access is unpredictable. - S3 Standard-IA (Infrequent Access): cheaper storage, retrieval fee. Access monthly or less. - S3 One Zone-IA: single AZ, 20% cheaper than Standard-IA. For non-critical data you can recreate. - S3 Glacier Instant Retrieval: archive, millisecond retrieval. Quarterly access. - S3 Glacier Flexible Retrieval: archive, retrieval in minutes to hours. Semi-annual access. - S3 Glacier Deep Archive: cheapest, 12-hour retrieval. Annual access. Long-term compliance. S3 Lifecycle Policies: automatically transition objects to cheaper storage classes or delete them after N days. Security: Block Public Access (default on), bucket policies, S3 ACLs (deprecated for new buckets), SSE-S3/SSE-KMS encryption, VPC endpoints for private access.

Lambda: serverless compute — upload code, Lambda runs it in response to events. No servers to provision or manage. Scales automatically from 0 to thousands of concurrent invocations. How it works: - Trigger: API Gateway, S3 event, SQS message, DynamoDB stream, CloudWatch Events, etc. - Execution: Lambda spins up a runtime (Node.js, Python, Java, Go...), runs your function, scales automatically - Billing: charged per request + per 100ms of execution time. Zero cost when idle. Lambda limits: - Max execution time: 15 minutes - Memory: 128MB to 10GB (CPU scales with memory) - Deployment package: 50MB zipped, 250MB unzipped (use Lambda layers for large deps) - Cold start: first invocation takes longer (runtime initialization) — keep functions warm or use Provisioned Concurrency for latency-critical paths Use Lambda when: - Event-driven: process S3 uploads, SQS messages, API requests - Sporadic/variable traffic: pay only for actual invocations - Short-running tasks (under 15 min) - Microservices with unpredictable scale Use EC2/ECS when: - Long-running processes (video encoding, ETL pipelines) - Consistent high traffic (EC2 Reserved is cheaper) - Specific OS/runtime requirements - GPU workloads - Cold start latency is unacceptable Lambda + API Gateway = serverless REST API. Very common pattern for India-based SaaS products.

RDS (Relational Database Service): managed relational databases — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Amazon Aurora. AWS handles backups, patching, failover. Multi-AZ Deployment: - Synchronous replication to a standby instance in a different AZ - Standby is NOT readable — it's purely for failover - Automatic failover in 1-2 minutes if primary fails (DNS flips to standby) - Use for: high availability and disaster recovery - Extra cost: you pay for a second instance that gets no traffic Read Replicas: - Asynchronous replication from primary to one or more replicas - Replicas ARE readable — offload SELECT queries from primary - Can be in same Region, different Region, or different AZ - Up to 5 replicas for MySQL/PostgreSQL (Aurora: 15) - Can be promoted to standalone DB if primary fails (manual, not automatic) - Use for: read scaling (reporting, analytics, read-heavy workloads) Aurora Specifics: - AWS's cloud-native MySQL/PostgreSQL-compatible DB - Storage auto-scales up to 128TB, 6 copies across 3 AZs by default - Aurora Serverless v2: scales capacity in fine-grained increments - Up to 15 Aurora Replicas with auto-failover priority Exam tip: Multi-AZ = HA/failover. Read Replica = performance/read scaling. They can be combined.

DynamoDB: fully managed NoSQL database. Key-value and document model. Single-digit millisecond latency at any scale. Serverless — no capacity planning needed (On-Demand mode). Data model: - Table: collection of items - Item: a record (like a row), up to 400KB - Attributes: key-value pairs within an item (schema-less — each item can have different attributes) Primary Key types: - Partition Key only (simple): e.g., userId. DynamoDB hashes the partition key to determine which partition stores the item. - Partition Key + Sort Key (composite): e.g., userId + createdAt. All items with the same partition key are stored together, sorted by sort key. Enables range queries on sort key. Secondary Indexes: - GSI (Global Secondary Index): different partition key + optional sort key. Query on non-primary attributes. - LSI (Local Secondary Index): same partition key, different sort key. Must be created at table creation. Read/Write modes: - Provisioned: set Read Capacity Units (RCU) and Write Capacity Units (WCU). Auto-scaling available. - On-Demand: pay per request, auto-scales instantly. More expensive per request but no idle cost. Use DynamoDB when: - Massive scale with consistent low latency (millions of requests/sec) - Simple access patterns (key-value lookups, prefix queries) - Serverless architecture - Session storage, shopping carts, IoT telemetry Use RDS when: - Complex JOINs needed - ACID transactions across multiple tables - Reporting/analytics with complex SQL

VPC (Virtual Private Cloud): a logically isolated network within AWS where you launch resources. You control IP ranges, subnets, routing, and security. Key components: CIDR Block: IP range for your VPC (e.g., 10.0.0.0/16 = 65,536 IPs). Subnets: subdivisions of the VPC's CIDR, tied to a single AZ. - Public subnet: has a route to Internet Gateway. Resources can communicate directly with the internet (if they have a public IP/EIP). - Private subnet: no route to internet. Resources are not directly reachable from internet. Internet Gateway (IGW): attached to VPC, enables internet access for public subnet resources. Required for EC2 instances in public subnets to reach the internet. NAT Gateway: allows private subnet resources to initiate outbound internet connections (e.g., to download software updates) without being accessible from the internet. Deployed in a public subnet, private route table points to NAT GW. Route Tables: control where traffic is directed. - Public subnet route table: 0.0.0.0/0 → Internet Gateway - Private subnet route table: 0.0.0.0/0 → NAT Gateway Security Groups: stateful firewall at instance level. Allow inbound/outbound rules. Return traffic is automatically allowed. NACLs (Network Access Control Lists): stateless firewall at subnet level. Must explicitly allow both inbound and outbound. Last line of defense. Best practice architecture: public subnets for ALB, private subnets for EC2/RDS. Traffic flows: Internet → ALB (public) → EC2 (private) → RDS (private).

ECS (Elastic Container Service): AWS-native container orchestration. Define tasks (one or more containers), deploy as services. Simpler than Kubernetes. Launch types: - EC2 launch type: you manage a fleet of EC2 instances as container hosts. More control, more responsibility. - Fargate launch type: serverless — AWS manages the underlying infrastructure. You just define CPU/memory for each task. No cluster management. EKS (Elastic Kubernetes Service): managed Kubernetes control plane. AWS handles control plane HA, upgrades, etcd. You manage worker nodes (or use Fargate for EKS too). ECS advantages: - Simpler to learn and operate — especially for teams new to containers - Tighter AWS integration (IAM roles per task, native CloudWatch, ALB integration) - Fargate makes it truly serverless — no node management - Cost: no Kubernetes overhead EKS advantages: - Full Kubernetes API — portable across clouds (GKE, AKS) - Richer ecosystem: Helm charts, Istio, Argo CD, Kustomize - Better for polyglot, multi-team microservices environments - Required if teams already know Kubernetes or use K8s manifests India context: most product companies running at scale use EKS (Flipkart, Swiggy, Razorpay use Kubernetes). Service companies (TCS, Infosys) often use ECS for simpler deployments. Choose ECS+Fargate for simplicity, EKS for portability and ecosystem richness.

CloudFront: AWS's CDN (Content Delivery Network). Caches content at 400+ Edge Locations globally, serving it from the location closest to the user. How it works: 1. User requests content (image, JS file, API response) 2. Request routes to nearest CloudFront Edge Location 3. If cached (cache hit): returned immediately from edge — very low latency 4. If not cached (cache miss): CloudFront fetches from origin (S3, ALB, API Gateway, EC2), caches it, returns to user 5. Subsequent requests for same content are served from cache Origins: S3 bucket, ALB, API Gateway, any HTTP server, Lambda Function URL. Use CloudFront when: - Static assets (images, CSS, JS): cache at edge, dramatically reduce S3 costs and latency - Global audience: serve users in India and US from nearest edge, not just one region - API acceleration: route API requests through CloudFront's optimized network backbone - DDoS protection: CloudFront + AWS Shield Standard protect against volumetric attacks - HTTPS everywhere: free SSL certificate via ACM, enforced HTTPS to origin Cache behaviors: different TTLs for different URL patterns (/api/* no cache, /static/* 1 year cache). OAC (Origin Access Control): CloudFront can access private S3 buckets — users can't bypass CDN to hit S3 directly. Invalidations: force-clear cache (POST /2020-05-31/distribution/ID/invalidation) — use versioned filenames (app.v2.js) instead for better performance.

Auto Scaling Group (ASG): automatically adds or removes EC2 instances based on demand. Ensures you have the right number of instances to handle the load. Key ASG settings: - Minimum capacity: floor (e.g., always keep 2 instances even at low load) - Maximum capacity: ceiling (e.g., never exceed 20 instances) - Desired capacity: current target - Launch Template: defines what instances to launch (AMI, instance type, security groups, IAM role) Scaling policies: - Target Tracking: maintain a metric at a target value (e.g., keep average CPU at 50%). AWS automatically adds/removes instances. Simplest. - Step Scaling: scale by a defined number of instances based on metric thresholds (CPU > 70% → add 2, CPU > 90% → add 4) - Scheduled Scaling: scale at specific times (add instances before 9am every weekday — predictable load) - Predictive Scaling: uses ML to forecast demand and scale proactively Horizontal scaling (Scale Out/In): add or remove EC2 instances. ASG handles this. Stateless apps work perfectly — each instance is identical. Vertical scaling (Scale Up/Down): change instance type (t3.medium → t3.xlarge). Requires instance restart — brief downtime. Used when the app can't be horizontally scaled. Combination: ALB + ASG. ALB distributes traffic across all instances; ASG maintains the right number of instances. Register ASG with ALB's target group for automatic instance registration/deregistration. Cooldown period: time after a scaling action before another can occur — prevents thrashing.