Cloud Computing
Complete Notes

Model Answer:

IaaS (Infrastructure as a Service) provides virtualised computing infrastructure over the internet. You manage the OS, runtime, applications and data. The provider manages virtualisation, servers, storage and networking. Examples: AWS EC2, Azure VMs, GCP Compute Engine — you get virtual servers and control everything above the hypervisor. PaaS (Platform as a Service) provides a platform for developers to build, run and manage applications without dealing with infrastructure. You manage only your application code and data. Examples: AWS Elastic Beanstalk, Heroku, Azure App Service — deploy your code and the platform handles the rest. SaaS (Software as a Service) delivers complete, ready-to-use applications over the internet. You manage nothing technical. Examples: Gmail, Salesforce, Microsoft 365, Zoom — you just use the software. The key question: "How much do you want to manage?" IaaS=most control, SaaS=least control, PaaS=in between.

Model Answer:

The Shared Responsibility Model divides security duties between AWS and the customer. AWS is responsible "OF" the cloud — the physical data centres, hardware, network infrastructure, and the managed services themselves (the hypervisor for EC2, the storage hardware for S3, etc.). The customer is responsible "IN" the cloud — everything they build and configure on top: their data and its encryption, their IAM users and policies, their EC2 operating system patching, their Security Group rules, their application security, and their network configurations. The split changes by service type: for EC2 (IaaS), you manage the OS and above. For RDS (managed service), AWS manages the database engine — you manage user accounts and data. For S3, AWS manages infrastructure, you manage bucket policies and encryption settings. A common interview follow-up: "Who is responsible for patching an EC2 instance?" Answer: The customer — it is IaaS, so OS patching is your responsibility.

Model Answer:

A VPC (Virtual Private Cloud) is your logically isolated private network within AWS (or Azure VNet, GCP VPC). Key components: Subnets — divisions of the VPC IP range. Public subnets have a route to the Internet Gateway (internet-facing resources like load balancers). Private subnets have no direct internet route (databases, application servers). Internet Gateway — connects your VPC to the internet; attach one per VPC for public subnet internet access. NAT Gateway — allows private subnet resources to make outbound internet requests (for patches, API calls) without being directly accessible from the internet. Route Tables — control where network traffic is directed; every subnet has one. Security Groups — stateful virtual firewall at the instance level; you specify allow rules only, deny is implicit. Network ACLs — stateless firewall at the subnet level; supports both allow and deny rules; processed in order. VPC Peering — connects two VPCs privately without internet transit.

Model Answer:

Security Groups are stateful — if you allow inbound traffic, the return traffic is automatically allowed. They operate at the instance/resource level. You can only create ALLOW rules. They evaluate all rules before deciding. Use Security Groups for instance-level firewall control. Network ACLs (NACLs) are stateless — inbound and outbound rules are evaluated separately; you must explicitly allow both directions. They operate at the subnet level and apply to all resources in the subnet. They support both ALLOW and DENY rules. Rules are evaluated in number order — lowest first, and processing stops at the first match. Use NACLs as an additional subnet-level layer, typically to block known malicious IPs. In practice: Security Groups cover 95% of security needs. NACLs are an extra layer of defence for network perimeter security.

Model Answer:

Kubernetes (K8s) is an open-source container orchestration platform originally created by Google. It automates deployment, scaling, load balancing, self-healing and management of containerised applications. Why it is needed: Docker can run containers on one machine, but production systems need containers running across many machines. When a container crashes, something must restart it. When traffic increases, something must scale up more containers. When you deploy a new version, something must do a rolling update without downtime. Kubernetes handles all of this. Key capabilities: Self-healing (restarts failed containers, replaces and reschedules them), Horizontal scaling (scale based on CPU/memory metrics), Rolling updates and rollbacks, Service discovery and load balancing, Secret and configuration management. AWS EKS, Azure AKS and GCP GKE provide managed Kubernetes where the control plane is managed for you.

Model Answer:

Serverless computing allows you to run code without provisioning or managing servers. You write functions, deploy them, and the cloud provider handles execution, scaling, and availability. You pay only per invocation and compute time — zero cost when idle. AWS Lambda, Azure Functions and GCP Cloud Functions are the main offerings. Key benefits: No server management, automatic scaling to zero (and back), pay per use (very cost effective for low/intermittent traffic), event-driven architecture support. Limitations: (1) Cold start latency — first invocation after idle period can take 100ms to 3 seconds depending on runtime and code size. (2) Maximum execution time — AWS Lambda has a 15-minute maximum. Not suitable for long-running processes. (3) Limited local state — functions are stateless; use DynamoDB, S3 or ElastiCache for state. (4) Debugging complexity — distributed tracing (AWS X-Ray) needed for debugging. (5) Vendor lock-in — Lambda code is often tightly coupled to AWS services.

Model Answer:

Infrastructure as Code means managing and provisioning infrastructure (servers, networks, databases) through machine-readable configuration files rather than manual clicks in a console. Tools: Terraform (vendor-agnostic, most popular), AWS CloudFormation (AWS-specific JSON/YAML), Azure ARM/Bicep templates, Pulumi (code in Python/TypeScript). Why it matters: (1) Version control — your infrastructure is in Git; you can see every change, who made it, and when. (2) Repeatability — spin up identical environments for dev, staging and production consistently. (3) Speed — provision complex infrastructure in minutes, not days. (4) Documentation — the code IS the documentation. (5) Disaster recovery — rebuild your entire infrastructure from scratch if needed. (6) Cost control — destroy non-production environments at night and recreate them in the morning. IaC is not optional in modern cloud engineering — it is the foundation of DevOps and GitOps practices.

Model Answer:

A highly available architecture on AWS uses multiple layers of redundancy. (1) Multi-AZ deployment: deploy EC2 instances in at least 2 Availability Zones. An AZ failure will not bring down the application. (2) Auto Scaling Group: automatically add instances when CPU exceeds threshold, remove when traffic drops. Ensures capacity without manual intervention. (3) Application Load Balancer: distributes traffic across healthy instances in multiple AZs. Health checks remove unhealthy instances automatically. (4) Multi-AZ RDS: primary database in one AZ with a synchronous standby in another. Automatic failover in 1–2 minutes if primary fails. (5) ElastiCache (Redis/Memcached): cache database query results to reduce DB load and improve response times. (6) CloudFront: CDN to serve static assets globally — reduces latency and origin server load. (7) S3 for static assets: 99.999999999% durable, automatically multi-AZ, no management needed. (8) Route 53 health checks: route traffic to a backup region if the primary region fails. Target: 99.99% availability (52 minutes downtime per year maximum).