Cloud Computing Roadmap

Introduction to Cloud Computing Core

Cloud computing is the practice of using computing resources owned and run by someone else, reached over a network, and paid for by use. Instead of ordering servers, waiting weeks and installing them in a room, you request a machine, a database or a queue through an API and have it in minutes.

The idea rests on a few properties: self-service provisioning, access over the network, pooled resources shared among customers, rapid elasticity and metered billing. Together they turn infrastructure from a capital purchase into an operating cost that follows demand. This roadmap covers the models, networking, storage, security, delivery practices and cost control that every cloud engineer is expected to know, whichever provider is used.

Practice. Write a half-page explanation of the cloud for a non-technical friend, using the five properties above.

Cloud vs On-Premises Core

On-premises means you buy, house, power and operate the hardware. You get full control and predictable costs for steady loads, and you can meet strict data rules easily. You also carry long lead times, over-provisioning for peaks, hardware refresh cycles and the staff to run it all.

Cloud swaps up-front spending for pay-as-you-go pricing, offers fast scaling and many managed services, and moves much undifferentiated work to the provider. The costs show up elsewhere: bills that grow with use, a need for new skills, dependence on a provider and shared responsibility for security. Steady, predictable workloads at large scale can be cheaper on-premises, and many organisations keep some systems there. The honest answer in an interview is a comparison by workload, not a slogan.

Practice. Choose one workload and compare cost, speed, control and risk for cloud and on-premises in a table.

Data Centers: Racks, Pods and Aisles Recommended

A data centre is a building built to run computers reliably. Servers are mounted in racks, standard cabinets of about forty-two rack units. Racks stand in rows called aisles, often arranged so cold air enters at the front and hot air leaves into a separate hot aisle. A pod is a group of racks, with its own network switches and power, that can be built and added as a unit. Racks usually connect to a top-of-rack switch, which links to aggregation and core layers.

Knowing this explains cloud terms. A failure domain, such as a rack or a pod, is why providers spread your instances across hosts and zones. A "zone" is built from one or more such facilities.

Practice. Draw a simple data centre layout with two pods and show where a rack, switch and power feed would fail separately.

Power and Cooling Optional

Computers turn almost all the electricity they use into heat, so power and cooling are the main limits on data centre size. Power arrives from the grid through transformers, uninterruptible power supplies for short outages and generators for long ones, usually with redundant paths. Cooling uses air handling, chilled water or increasingly liquid cooling for dense hardware.

The efficiency metric is power usage effectiveness: total facility power divided by IT power, where closer to one is better. This matters to you because energy sets provider costs and sustainability claims, and because GPU racks need far more power and cooling than ordinary servers. Region choice can change the carbon footprint of a workload.

Practice. Look up the power usage effectiveness reported by two providers and compare what each says about its method.

Hypervisors and Virtual Machines Core

A hypervisor is software, sometimes built into firmware or the operating system, that divides one physical server into several isolated virtual machines (VMs). Type 1 hypervisors, such as KVM, Xen and Hyper-V, run directly on hardware. Type 2 hypervisors run as an application on a normal operating system, as desktop tools do. Each VM has its own operating system and virtual hardware, and the hypervisor schedules CPU, memory and I/O between them.

Virtual Machines are the base of infrastructure as a service. Isolation lets many customers share a host safely, and an image can be copied to make identical machines. Overhead is small today thanks to hardware support. Some providers use light hypervisors, such as AWS Nitro, to move work onto dedicated cards.

Practice. Create a VM on your laptop with any hypervisor and note the CPU, memory and disk you gave it.

VM Migration, Live Migration Recommended

Migrating a VM means moving it to another host, data centre or provider. Cold migration stops the VM, copies it and starts it again. Live migration copies memory pages while the VM keeps running, then switches over in a pause of milliseconds. Providers use it to maintain hosts without telling you.

For moving workloads into the cloud, the common strategies are rehost (lift and shift), replatform (small changes, such as a managed database), refactor (redesign for cloud services), repurchase and retire. Rehosting is quickest, and refactoring gets the most from the platform. Plan for data transfer time, licensing, network addressing and a rollback.

Practice. Choose one on-premises application and decide which migration strategy you would use, with reasons.

Cloud Service Models: IaaS, PaaS and SaaS Core

Cloud Service Models differ in how much the provider runs. IaaS (infrastructure as a service) gives virtual machines, disks and networks: you manage operating systems and everything above. PaaS (platform as a service) gives a runtime where you deploy code and the provider handles servers, patching and scaling, as with App Service or Cloud Run. SaaS (software as a service) is a finished application used through a browser.

Think of it as a stack of layers: hardware, virtualisation, operating system, runtime, application, data. Each model hands more layers to the provider. More hand-over means less operations work and less control. Choose the highest level that still meets your needs.

Practice. Take five products you use and place each on the IaaS, PaaS or SaaS scale.

FaaS and DaaS Recommended

Function as a service (FaaS) runs small pieces of code in response to events and bills for execution time, in products from every major provider, Lambda being the best known. It is covered further under serverless computing.

DaaS has two meanings, and interviewers may mean either. Desktop as a service delivers virtual desktops from the cloud, as with Windows 365 or Amazon WorkSpaces, which helps with remote staff and tight data control. Database or data as a service offers a managed database or data feed. Check which one is meant before answering.

Practice. List one business case for each meaning of DaaS.

Cloud Deployment Models: Public Cloud and Private Cloud Core

Cloud Deployment Models describe who owns the infrastructure and who shares it. A public cloud is run by a provider for many customers over the internet. A private cloud serves one organisation, run in its own data centre or by a host, often with tools such as OpenStack or VMware. Private gives more control and customised compliance, and costs more to operate.

Choose by data sensitivity, regulation, cost at scale and skills. Most organisations use public cloud for the majority of workloads and private for special cases, which leads to hybrid designs.

Practice. Write criteria that would push a workload to a private cloud rather than public.

Hybrid Cloud, Regional Cloud and Bare Metal Cloud Recommended

Hybrid cloud connects private or on-premises systems with public cloud, through VPN or dedicated links, and often with tools that manage both such as Azure Arc or AWS Outposts. Use it for migration, data residency, latency to local equipment and bursting extra load into the cloud.

A regional cloud is a smaller provider focused on a country or area, chosen for data sovereignty, language support and local relationships. Bare metal cloud rents whole physical servers by the hour with API provisioning, without a hypervisor layer. It suits databases, high-performance work, licensing that counts sockets and anything needing direct hardware access, such as GPUs.

Practice. Name one workload that needs bare metal and one that needs a regional provider and say why.

Region, Availability Zone and Failure Domains Core

Providers divide their footprint into regions, which are separate geographic areas, and Region, Availability Zone pairs inside them. A zone is a group of data centres with independent power, cooling and network. Deploying across zones protects against a data centre failure, and across regions against a regional outage or for lower latency to distant users.

Choose a region for legal rules, latency, available services and price. Data moves between zones and regions at a cost and with added delay, so replicate deliberately. Some services are zonal, some regional and some global, and you must know which ones you depend on.

Practice. Draw a two-zone design for a web app and mark which components are zonal, regional or global.

Hyperscalers: AWS, Azure and GCP Core

Hyperscalers are the very large providers that operate data centres around the world and sell a broad range of services. AWS was first and has the broadest catalogue. Azure integrates strongly with Microsoft software, identity and enterprise contracts. GCP is known for data analytics, machine learning, Kubernetes and networking. Others include Oracle Cloud and Alibaba Cloud.

They offer equivalent core services under different names: virtual machines, object storage, managed databases, serverless functions and managed Kubernetes. Learn the concepts first and keep a mapping table of names. See AWS Roadmap for a detailed look at one provider.

Practice. Build a table mapping compute, object storage, DNS and managed Kubernetes across AWS, Azure and GCP.

Multi-Cloud and Provider Lock-In Recommended

Multi-cloud means using more than one provider. Reasons include avoiding dependence, picking best-of-breed services, meeting regional rules and surviving a provider outage. Costs include duplicated skills, lowest-common-denominator designs, more complex security and data transfer fees.

Provider lock-in is the difficulty of leaving once you rely on proprietary services, data formats and APIs. It is a spectrum, not a binary. Reduce it where cheap, using open standards, containers, Kubernetes, Terraform and portable databases, and accept it where the managed service saves more than it risks. Many experienced teams use one primary provider and design clean exits for the most critical data.

Practice. List three services you would accept lock-in for and three you would keep portable.

Shared Responsibility Model, SLA and Multi-Tenancy Core

In the Shared Responsibility Model the provider secures the platform and you secure what you put on it. The split moves with the service model: you own the operating system on IaaS but not on SaaS, yet you always own your data and identities.

An SLA (service level agreement) is the provider's written promise of availability, such as 99.9 percent per month, with credits if missed. Read what the number covers, because credits are small compared with real downtime, and your own availability is at most that of your weakest dependency. Combine components in series by multiplying availabilities.

Multi-tenancy means many customers share the same infrastructure with logical isolation. It lowers cost and raises the need for strong isolation, noisy-neighbour control and careful data separation, in providers' platforms and in SaaS applications you build.

Practice. Calculate the combined availability of three components at 99.9 percent each when all must work.

Instance, Virtual Machine Instances and Instance Types Core

An instance is one running virtual machine in a provider's service. Virtual Machine Instances are created from an image and a size, and billed while they run. Instance types combine CPU, memory, network and storage in families, such as general purpose, compute optimised, memory optimised, storage optimised and GPU. Burstable types give a baseline with credits for bursts.

Pick a type by measuring: observe CPU, memory and I/O, then choose the smallest type that fits with headroom. Newer generations and Arm-based processors often give better price for performance. Treat instances as disposable: configure by image or automation, not by logging in and editing, so any instance can be replaced.

Practice. Compare three instance types for a memory-heavy workload using the provider pricing page.

VMs vs Containers and Containers Core

A VM virtualises hardware and carries a full operating system. A container isolates a process using kernel features, namely namespaces and control groups, and shares the host kernel. So containers start in seconds, use less memory and pack more densely, while VMs give stronger isolation and can run different operating systems.

Containers package an application with its dependencies in an image, which runs the same on a laptop and in production. They are the common unit of deployment for microservices. In practice you often run containers inside VMs, combining density with isolation. Learn the tooling in Docker Roadmap.

Practice. Run the same small web app in a VM and in a container and compare start-up time and memory use.

Docker and Container Orchestration Core

Docker made containers easy: a Dockerfile describes how to build an image, and docker run starts a container from it. Images are stored in registries and layered, so builds and pulls reuse unchanged layers.

One container on one host is simple. Many containers over many hosts need container orchestration, a system that places containers, restarts failures, scales them, connects them and rolls out updates. Kubernetes is the dominant choice, with simpler options such as Amazon ECS, Nomad and Docker Swarm. The orchestrator is what turns a fleet of machines into one pool of capacity.

Practice. Write a Dockerfile for a small app, build it, run it and list the layers with docker history.

Kubernetes, Cluster and Control Loops and Controllers Core

Kubernetes is an orchestrator built around desired state. A Cluster has a control plane, which stores state and schedules work, and worker nodes that run pods, the smallest deployable units. You declare what you want, for example three replicas of an image, and the system works to make reality match.

The mechanism is the control loop. A controller keeps observing what exists, measures the distance from what you asked for and takes action to shrink it, again and again. A Deployment controller creates and replaces pods, and a node controller notices dead nodes. This pattern also explains self-healing and why Kubernetes extensions are written as controllers. Study Kubernetes Roadmap for the full detail.

Practice. Apply a Deployment with three replicas, delete one pod and watch the controller replace it.

Managed Kubernetes Recommended

Managed Kubernetes services such as Amazon EKS, Azure AKS and Google GKE run the control plane for you, handling availability, upgrades and backups of cluster state. You manage worker nodes, or use serverless node options such as GKE Autopilot or Fargate profiles, plus your workloads, networking policy and security.

Benefits are far less operations work and tight integration with the provider's identity, load balancers and storage. Costs include a control plane fee, version upgrades on the provider's schedule and some provider-specific behaviour. Run your own Kubernetes only when you have a strong reason, such as on-premises or air-gapped sites.

Practice. List the tasks a managed service removes from you and three it leaves in place.

Serverless Computing, Serverless Platforms and Stateless Functions Core

Serverless computing lets you run code without managing servers, with automatic scaling, including to zero, and billing by use. Serverless Platforms include hosted function products (Lambda is the best known), container-based ones such as Cloud Run and Azure Container Apps, and serverless databases and queues.

Functions are expected to be stateless: any state lives in a database, cache or object store, since the platform may start, stop or duplicate an instance at any time. This is what lets the platform scale freely. Keep functions short, idempotent and quick to start, and treat local memory only as a cache.

Practice. Write a function that increments a counter, then explain where the counter must be stored to survive restarts.

Trade-offs of Serverless and FaaS Limits Recommended

Trade-offs of serverless: you gain no server administration, fine-grained cost and quick scaling. You accept cold start delays, execution time limits, less control over the runtime, harder local testing and debugging, and strong coupling to the platform's event model and services. Steady high-volume workloads can cost more than well-used containers.

Good fits are event processing, glue code, spiky APIs and scheduled jobs. Poor fits are long-running jobs, ultra-low-latency paths, and heavy or stateful processing. Design with timeouts, retries, concurrency limits and downstream protection, since a function scaling up can overwhelm a database.

Practice. Decide whether three given workloads suit serverless, and note the risk for each.

Scalability, Elasticity and Scaling Core

Scalability is the ability to handle more load by adding resources. Vertical scaling makes one machine bigger, and is simple but has a ceiling and often needs a restart. Horizontal scaling adds more machines and needs stateless design, load balancing and shared data, but has no fixed ceiling.

Elasticity is the ability to scale out and back in automatically as demand changes, so you pay for what you need. Scaling decisions can be reactive, from metrics such as CPU or queue length, scheduled for known peaks, or predictive. Watch for limits further down: a database or third-party API often fails before the web tier does.

Practice. Draw how you would scale a web tier and identify which backend component becomes the bottleneck first.

Auto Scaling and Workload Patterns Core

Auto Scaling groups or autoscalers adjust capacity to a rule: target tracking keeps a metric near a value, step policies react in bands and schedules add capacity before known events. Kubernetes has the Horizontal Pod Autoscaler for pods and cluster autoscalers or Karpenter for nodes.

A workload is the application and its resources that you run, and its pattern guides the design. Steady workloads suit reserved capacity. Spiky workloads suit autoscaling or serverless. Batch workloads suit spot capacity and queues. Set minimum and maximum sizes, cool-down periods, and health checks so replaced instances are real replacements. Test scaling under load before you need it.

Practice. Run a load test against an autoscaled service and record when instances were added.

Edge Computing and Edge vs Cloud Recommended

Edge computing runs processing close to where data is produced or used, such as on a factory gateway, in a mobile network site or at a CDN location. It reduces latency, saves bandwidth and keeps working when the connection to the central cloud is poor.

Edge vs cloud is not a contest. The cloud offers huge capacity, central management and the easiest analytics, while the edge offers speed and locality at the cost of smaller hardware, harder management of many sites and tighter security needs. A common design runs real-time decisions at the edge, sends summaries to the cloud, and trains models centrally. Services such as AWS Greengrass, Azure IoT Edge and Cloudflare Workers fit here.

Practice. Design a camera system that detects events on site and sends only the results to the cloud.

Networking Basics and Core Networking Core

Networking Basics start with IP addresses, which identify hosts, and CIDR notation, which describes ranges. Ports identify services on a host, TCP gives reliable ordered delivery and UDP gives fast, unreliable delivery. DNS maps names to addresses. HTTP and HTTPS carry most application traffic, and TLS encrypts it.

Core Networking in the cloud rebuilds this in software: a private network, subnets, route tables, gateways, firewalls and load balancers that you create by API. The concepts match physical networks, so strength in the basics pays off directly. When something is unreachable, work through the path: name resolution, route, firewall, then service.

Practice. Trace a request from a browser to a server naming every step: DNS, TCP, TLS and HTTP.

Network Topology Recommended

Network topology is the shape in which devices and networks connect. Classical shapes are star, ring, bus and mesh. Inside data centres, a leaf and spine design connects every leaf switch to every spine switch, so any two servers are the same number of hops apart and capacity grows by adding switches.

In the cloud, topology appears at the level of your virtual networks. A hub and spoke design connects many spoke networks through one central hub that hosts shared services, firewalls and the link to on-premises. A full mesh of peerings becomes unmanageable as networks multiply, which is why transit gateways exist. Pick the topology that matches how many networks you will have.

Practice. Draw a hub and spoke design for four environments sharing one egress firewall.

Virtual Private Cloud (VPC) Core

A Virtual Private Cloud gives you a private, software-defined network inside a provider's data centres, with address ranges, subnets and routing under your control. Azure calls it a virtual network (VNet). Resources inside get private addresses and talk to each other directly. You decide what connects to the internet, other networks and on-premises sites.

Plan address ranges so they do not overlap with other networks you may connect, and leave room to grow. Use separate networks or subnets for environments, and place only what must be public, such as load balancers, in public subnets. Connect to provider services privately through endpoints. See AWS Roadmap for a worked VPC.

Practice. Design address ranges for dev, staging and production networks that can all be peered later.

Subnets and Routing Core

Subnets & Routing divide a network into smaller ranges, usually per zone, and route tables decide where packets go. Each route pairs a destination range with a target, and the most specific match wins. A subnet whose default route points to an internet gateway is public. One whose default route points to a NAT device or nothing is private.

Keep tiers in separate subnets so firewall rules and routes can differ: public for load balancers, private for applications, isolated for databases with no outbound route. Routing across peered or connected networks needs routes on both sides, and routes do not pass through a peering automatically.

Practice. Write the route table for a public, private and isolated subnet and say where each default route points.

NAT and IP Management Recommended

Network address translation lets many private hosts share a few public addresses. NAT & IP Management covers a few ideas. A NAT gateway lets private instances start outbound connections while blocking inbound ones. Public addresses are scarce and now charged for, so use as few as possible, with load balancers and gateways as the entry points. Elastic or static addresses stay with you, while ordinary public addresses change when a machine is stopped.

IP address management also means planning ranges, tracking allocations, using IPv6 where supported and avoiding overlaps when merging networks. NAT gateways cost per hour and per gigabyte, so keep large downloads on private endpoints when possible.

Practice. Calculate the monthly NAT cost for 2 TB of outbound traffic, and find a cheaper path for part of it.

Firewalls and Security Groups Core

Firewalls & Security Groups filter traffic. A security group is a stateful, instance-level firewall with allow rules, where replies are permitted automatically. Network ACLs filter at the subnet level and are usually stateless. Web application firewalls inspect HTTP for attacks such as injection. Network firewall services inspect and filter traffic between networks and to the internet.

Write rules by role: the application tier accepts traffic only from the load balancer, and the database accepts only from the application tier. Refer to groups rather than addresses where supported. Deny by default, open the smallest port range and review rules regularly, since forgotten broad rules are a common finding in audits.

Practice. Review a security group with 0.0.0.0/0 on port 22 and replace it with a safer access path.

VLANs and VXLAN Optional

A VLAN splits one physical network into separate logical networks using a tag in the Ethernet frame. There are only 4,094 usable VLAN ids, which is too few for a large cloud with many tenants. VXLAN solves this by wrapping layer 2 frames inside UDP packets across a layer 3 network, with a 24-bit identifier that allows about sixteen million segments.

Providers use overlay networks like this to give each customer its own virtual network over shared hardware. You rarely configure them in a public cloud, but you meet them in private clouds, Kubernetes networking plugins and data centre work. Know the problem each solves.

Practice. Explain in two sentences why VLAN limits matter for multi-tenant clouds and how VXLAN helps.

SDN: Software-Defined Networking Recommended

SDN splits networking into two parts: a control plane that chooses paths, and a data plane that moves the packets. A central controller programs switches through an API, so networks are configured like software: versioned, reviewed and automated.

Cloud virtual networks are SDN in practice. When you create a subnet or a route, a controller programs the hosts' virtual switches. Benefits are speed, consistency and automation. Risks include the controller being a critical component and the need for good observability. SDN also underlies SD-WAN, which connects branch offices over several links with central policy.

Practice. Describe what happens behind the scenes when you add a route to a virtual network.

Load Balancers and Traffic Management Core

Load balancers distribute requests across healthy targets. Layer 4 balancers work on TCP and UDP connections and are fast. Layer 7 balancers understand HTTP, so they can route by host or path, terminate TLS, and add headers. Algorithms include round robin, least connections and hashing, and health checks remove failed targets.

Traffic Management goes further: weighted routing for canary releases, DNS-based routing by latency or location, failover to another region and rate limiting. Combine global traffic managers with regional load balancers. Remember connection draining, so deployments do not drop active requests, and sticky sessions only when a service cannot be made stateless.

Practice. Configure weighted routing that sends 10 percent of traffic to a new version.

DNS in the Cloud, CDN and Edge Caching Core

DNS in the Cloud is a managed service for public and private zones, with records pointing at load balancers and services, health-checked failover, and routing by latency or location. Short TTLs speed changes and raise query volume. Private zones give internal names to resources only inside your networks.

A CDN caches content at edge locations close to users. CDN & Edge Caching cut latency and offload your origin: static files cache for long periods, and versioned filenames avoid stale content. Dynamic content can be cached briefly or accelerated by a persistent connection to the origin. CDNs also absorb attacks, terminate TLS and run small pieces of code at the edge.

Practice. Put a CDN in front of a static site and compare response times from two distant locations.

VPN, Direct Connect and Upstream Connectivity Recommended

VPN & Direct Connect describe the two ways to link a company network to the cloud. A site-to-site VPN uses encrypted tunnels over the internet. Setup is fast and cheap, though throughput and latency can vary. A dedicated connection, such as AWS Direct Connect, Azure ExpressRoute or Google Cloud Interconnect, uses private lines with steady latency and high capacity, at higher cost and longer lead time. Many designs use a VPN as a backup for the dedicated link.

Upstream connectivity is how a provider or network reaches the wider internet, through transit providers and peering with other networks. It affects latency and reliability, and is a reason to choose providers with good peering to your users.

Practice. Design connectivity for an office that needs high reliability, and say what backs up the main link.

Latency, Throughput and Endpoints Core

Latency & Throughput are different. Latency is the time for one request to go and return, limited by distance and the speed of light, about one millisecond per hundred kilometres of fibre each way. Throughput is the data moved per second. High throughput does not fix high latency, and chatty protocols suffer over long distances.

Reduce latency by moving compute and data closer to users, caching, using persistent connections and reducing round trips. An endpoint is the address where a service accepts requests, and private endpoints expose provider services inside your network with no internet path, improving security and often cost. Measure with real tools such as ping, traceroute and application metrics.

Practice. Measure round-trip time to two regions from your location and explain the difference.

Cloud Storage: Block, File and Object Core

Cloud Storage comes in three kinds, and choosing between them is a standard interview topic. Block storage presents a raw disk to a single server, with low latency, and is used for operating systems and databases. File storage offers a shared file system over a network protocol, for several servers that need common paths. Object storage keeps whole objects with metadata under keys, accessed over HTTP, scales almost without limit and is cheap, but it has no in-place edit.

Match access pattern to type: transactional data on block, shared content on file, and media, backups, logs and data lakes on object.

Practice. Assign block, file or object storage to a database, a shared home directory and a photo archive.

Block Storage and Object Storage in Detail Core

Block storage volumes live in one zone and attach to an instance. Snapshots copy them to cheaper storage, and performance depends on the volume type, with provisioned IOPS options for databases. Examples are EBS, Azure Managed Disks and Persistent Disk.

Object Storage groups objects in buckets or containers. Examples are S3, Azure Blob Storage and Google Cloud Storage. Features include versioning, replication, lifecycle rules, encryption and pre-signed links for temporary access. Durability is extremely high because data is spread across devices and zones. Keep buckets private by default, since public exposure is among the most common cloud mistakes.

Practice. Create a bucket and a volume, and note what each can and cannot do for a running application.

File Storage, NAS and SAN Recommended

File Storage in the cloud is managed network file systems such as Amazon EFS, Azure Files and Filestore, using NFS or SMB. They suit shared content, home directories and lift-and-shift of applications that expect a file system.

NAS and SAN are the traditional models. A NAS (network attached storage) shares files over the network, and clients see folders. A SAN (storage area network) shares block devices over a dedicated network, such as Fibre Channel or iSCSI, and clients see disks. Cloud services reproduce both ideas in managed form. Remember that network file systems are slower than local disks and cost more per gigabyte than object storage.

Practice. Explain what the application sees differently when it is given a NAS share and a SAN volume.

Storage Classes and Tiering, Data Lifecycle and Archiving Core

Storage Classes & Tiering trade price for access speed. Hot tiers serve frequent reads, cool or infrequent access tiers cost less to store and more to read, and archive tiers are cheapest and slowest, taking minutes to hours to retrieve. Automatic tiering moves objects between them by observed access.

The data lifecycle is the path from creation through active use, infrequent use, archiving and deletion. Lifecycle rules apply the policy. Data Archiving keeps old data cheaply for audit, analysis or legal reasons. Watch for minimum storage durations, retrieval fees and early deletion charges, which can make a cold tier more costly than a hot one for small or short-lived data.

Practice. Write a lifecycle policy that moves logs through three tiers and deletes them after seven years.

Retention, Compliance and Data Protection Core

Retention & Compliance means keeping data as long as rules or business require, and no longer. Some regulations require records for years, and privacy law requires deletion on request. Features such as object lock and legal holds make data write-once for a period.

Data Protection covers backups, replication and recovery. Define recovery point objective, how much data you can lose, and recovery time objective, how long you can be down, then choose the approach: backups for protection against deletion and corruption, replication for availability. Keep copies in another account or region, encrypt them and test restores regularly. Replication alone copies mistakes and ransomware as quickly as good data.

Practice. Set RPO and RTO for a customer database and pick a backup and replication design that meets them.

Databases in the Cloud: Managed Relational and NoSQL Core

Databases can run on VMs you manage, or as managed services. Managed Relational DBs such as Amazon RDS and Aurora, Azure SQL and Cloud SQL handle patching, backups, failover and read replicas, while you design schemas and queries. Use them for structured data, joins and transactions. Learn the query side in SQL Roadmap.

NoSQL databases trade relational features for scale or flexibility: key-value stores such as DynamoDB, document stores such as MongoDB and Firestore, wide-column stores, graph databases and caches. Choose by access pattern, consistency needs and scale. Many systems combine a relational store, a cache and a search index, and keep each in sync through events.

Practice. Choose a database type for a shopping cart, a bank ledger and a product search, with a reason each.

Identity and Access Management: IAM, Access Control and RBAC Core

IAM decides who or what may do which action on which resource. Identities can be people, groups and workloads. Access Control combines authentication, which proves identity, and authorisation, which grants permission. RBAC (role-based access control) attaches permissions to roles, such as reader or deployer, and assigns people to roles, which scales better than per-person grants.

Principles: least privilege, separation of duties, short-lived credentials, MFA for people and federated single sign-on. Workloads should use platform identities such as roles and managed identities, not stored keys. Review permissions regularly and log every access decision for audit.

Practice. Define three roles for a project team and list which actions each is allowed on which resources.

Encryption Core

Encryption protects data when stolen or intercepted. At rest, storage services encrypt with keys, usually by default, and customer-managed keys in a key management service give you control of rotation and revocation. In transit, TLS protects connections between users and services and between services. Envelope encryption, where a data key encrypts the data and a master key encrypts the data key, is the standard pattern.

Encryption does not replace access control: anyone allowed to read through the service sees plaintext. Keep keys separate from data, restrict key use, enable rotation and audit key access. Client-side encryption suits data you do not want the provider to see at all.

Practice. Enable a customer-managed key for a bucket and observe what access the key policy adds or removes.

Secrets Management Core

Secrets are credentials, tokens and keys that applications need. Secrets Management stores them in a dedicated service, from each cloud provider or from HashiCorp Vault, with access control, audit logs and rotation. Applications fetch them at run time with their platform identity.

Avoid secrets in source control, container images, environment dumps and logs. Rotate on a schedule and immediately after exposure. Prefer short-lived credentials that are issued on demand over long-lived ones. In Kubernetes, remember that a Secret object is only base64 encoded by default, so enable encryption at rest and tight RBAC, or use an external secret store.

Practice. Move a database password from a config file to a secrets service and read it at start-up.

Zero Trust and Cybersecurity Basics Core

Zero trust drops the idea of a trusted internal network. Every request is authenticated, authorised and evaluated by identity, device state and context, wherever it comes from. Practical parts include strong identity, per-service access rules, micro-segmentation, encrypted internal traffic and continuous verification.

Cybersecurity Basics for cloud engineers: patch quickly, minimise open ports, apply least privilege, keep inventory, enable logging and alerting, back up and test restores, scan images and dependencies, and prepare an incident process. Common causes of cloud breaches are misconfiguration, exposed credentials and over-broad permissions, not exotic exploits. The security-focused role roadmaps go deeper.

Practice. List five zero trust controls you could add to a typical three-tier application.

Privacy and Compliance Recommended

Privacy & Compliance covers the rules for handling personal and regulated data. Laws such as the GDPR in Europe govern consent, access, deletion and transfer across borders. Standards and frameworks such as ISO 27001, SOC 2, PCI DSS and HIPAA set controls for security and handling of specific data types.

Providers publish audit reports for their platform, but compliance remains shared: your configuration and processes must also comply. Practical work includes data classification, choosing regions to meet residency rules, minimising collected data, logging access and documenting controls. Automated policy checks catch drift between audits.

Practice. Classify the data in a sample application and decide which region and controls each class needs.

Monolithic vs Microservices Core

A monolith is deployed as one unit. It is simple to build, test and run at first, and the cost grows as the team and code grow: slower releases, wider blast radius and scaling everything together. Microservices split the system into small services owned by teams, each deployable and scalable independently, communicating over the network.

The price of microservices is distributed-system complexity: network failures, data consistency across services, versioned APIs, harder debugging and much more operational tooling. Many teams do best by starting with a well-structured monolith and extracting services where independence pays off. Choose by team size and change patterns, not fashion.

Practice. List the signals that tell you a monolith should be split and the signals that tell you to wait.

Microservices and Microservices Communication Core

Microservices communication is synchronous or asynchronous. Synchronous calls, over REST or gRPC, are simple and give an immediate answer, but couple services in time: if the callee is slow, so is the caller. Use timeouts, retries with backoff, circuit breakers and idempotency. Asynchronous messaging through queues and topics decouples services, smooths bursts and allows retries, at the cost of eventual consistency.

Each service should own its data store, and other services should read it only through its API or events. Document APIs, version them carefully and use correlation ids to trace one request across services. See API Design Roadmap for design rules.

Practice. Draw an order flow between three services and mark each hop as synchronous or asynchronous.

Event-Driven Architecture Recommended

In an event-driven architecture, components publish events, facts that something happened, and other components react. Producers do not know who consumes. This enables loose coupling, easy addition of new reactions and natural scaling with queues and streams.

Challenges: events can arrive twice or out of order, so consumers must be idempotent. Debugging a flow means following it across components, so use tracing. Schema changes need care, and a schema registry helps. Typical tools are queues such as SQS, topics such as SNS, event buses such as EventBridge and streams such as Kafka and Kinesis. Combine with serverless functions for reactions.

Practice. Design an event flow for "order placed" with three independent consumers.

Service Mesh Optional

A service mesh adds a layer for service-to-service communication, usually with a sidecar proxy beside each service or a node-level proxy. It provides mutual TLS, retries, timeouts, traffic splitting, and metrics and traces without changing application code. Examples are Istio, Linkerd and Cilium.

A mesh helps when you have many services and need consistent security and traffic policy. It adds resource use, configuration to learn and one more failure source, so small systems rarely need one. Libraries and the platform's load balancers often cover simpler needs.

Practice. Write down which mesh features you would want first and whether a library or load balancer could give them.

Version Control and Developer-Focused Workflow Core

Everything in a modern cloud workflow starts in version control. Application code, infrastructure definitions, pipeline files and configuration all live in Git, and changes come through reviewed pull requests. This gives history, accountability and the ability to roll back. Learn the tool in Git and GitHub Roadmap.

Developer-Focused cloud work means making the path from code to running service easy: templates for new services, preview environments for pull requests, fast local development with the same containers used in production and clear documentation. Platform teams build this as an internal developer platform, so product teams spend time on features, not plumbing.

Practice. Put a sample app and its infrastructure files in one repository and open a pull request that changes both.

CI/CD, CI/CD Pipelines and Artifact Registries Core

Continuous integration builds and tests every change. Continuous delivery keeps software always releasable, and continuous deployment releases automatically after checks pass. CI/CD pipelines are the automated sequences that do this: build, unit test, scan, package, deploy to staging, run integration tests and promote to production.

Artifact Registries store the outputs, such as container images, packages and binaries, with versions and access control. Build once, store an immutable artifact and promote that same artifact through environments. Use short-lived cloud credentials through federation, sign artifacts, scan dependencies and keep pipelines as code. Common tools include GitHub Actions, GitLab CI, Jenkins and Cloud Build.

Practice. Create a pipeline that builds an image, scans it, pushes it to a registry and deploys it to a test environment.

Deployment Strategies Core

Deployment Strategies control risk when releasing. Recreate stops the old version and starts the new one, which is simple with downtime. Rolling replaces instances gradually. Blue-green keeps two full environments and switches traffic at once, with instant rollback. Canary sends a small share of users to the new version and grows it while watching metrics. Feature flags separate deploying code from releasing a feature.

Pick by risk, cost and statefulness. Database changes need extra care: use backward-compatible steps (expand, migrate, contract) so old and new code both work during the release. Automate rollback on failing health checks or error budgets.

Practice. Plan a canary release with the metrics and thresholds that would stop it.

Infrastructure as Code, Terraform and Provisioning Core

Infrastructure as Code describes resources in files that a tool applies, so environments are repeatable and reviewable. Provisioning is the act of creating resources, and IaC makes it a declared, versioned process. Terraform is the most common multi-cloud tool, with provider plugins and state that tracks what exists. Cloud-native alternatives are CloudFormation, Bicep and Deployment Manager, and Pulumi uses general-purpose languages. See the Terraform Roadmap roadmap.

Practices: modularise, keep state remote and locked, run plans in pull requests, apply from pipelines, scan for misconfigurations and detect drift. Never change production by hand except in emergencies, and then fold the change back into code.

Practice. Describe a small network and virtual machine in Terraform and apply it in a sandbox account.

Configuration Management and GitOps Recommended

Configuration management tools such as Ansible, Chef and Puppet configure what runs inside machines: packages, files, services and users, converging them to a declared state. With immutable images and containers, less of this is needed, but it remains common for fleets of VMs and network devices.

GitOps applies the same idea to whole environments: the desired state lives in a Git repository, and an agent in the cluster, such as Argo CD or Flux, pulls it and reconciles reality continually. Benefits are an audit trail, easy rollback by reverting a commit and no cluster credentials in the CI system. Drift is corrected automatically.

Practice. Install Argo CD or Flux in a test cluster and deploy an app from a Git repository.

Levels of Automation and Lights-Out Operations Optional

Levels of Automation describe a progression: manual work, scripts, tools run by hand, pipelines, self-service platforms and finally self-healing systems. Each level removes toil and human error, and needs better testing, observability and guardrails.

Lights-Out Operations means running infrastructure with almost no manual intervention or on-site staff, as in data centres that run unattended and in fully automated deployments. The aim is not to remove people, but to move their effort from repetitive tasks to design, improvement and incident learning. Be sure that alerts, runbooks and escalation exist before removing manual checks.

Practice. Place your current deployment process on the automation scale and pick the next step.

Linux, Shell, Bash and Python for the Cloud Core

Most cloud servers and containers run Linux, so you need to navigate the file system, manage processes and services, read logs, handle permissions and network tools. Learn it in Linux Roadmap. Shell / Bash scripting automates tasks and glues commands together, as covered in Shell and Bash Roadmap.

Python is the common language for cloud automation, with the boto3, Azure and Google SDKs, and for data and machine learning work. Use it when a script outgrows Bash, needs structured data or calls provider APIs. See Python Roadmap. Scripts should be idempotent, handle errors and log what they do.

Practice. Write a Python script that lists untagged resources in an account and prints them as a table.

AI and ML Services Recommended

AI/ML Services from providers come at several levels. Pre-built APIs handle tasks such as vision, speech, translation and text analysis. Managed platforms such as SageMaker, Azure Machine Learning and Vertex AI cover training, tracking, deployment and monitoring. Foundation model services, such as Amazon Bedrock, Azure OpenAI and Vertex AI, offer hosted large models through an API.

Choose the highest level that meets the need, since training and GPU capacity cost far more than API calls. Plan for data privacy, evaluation, latency, rate limits and cost per request. Keep data in the region and account your rules require, and monitor quality over time.

Practice. Call a hosted language model API from a script and record latency and cost for ten requests.

Pricing Models Core

Pricing Models vary by service. On-demand charges per second or hour with no commitment. Committed use, such as Savings Plans, reserved instances and committed use discounts, trades a one or three year commitment for large discounts. Spot or preemptible capacity is cheapest and can be reclaimed. Serverless charges per request and duration, storage per gigabyte-month and retrieval, and networks per gigabyte of outbound traffic.

Hidden costs include cross-zone and cross-region transfer, internet egress, NAT processing, load balancers, idle resources, snapshots and logs. Always estimate with the provider calculator before building, and include data transfer.

Practice. Estimate the monthly cost of a three-tier app and mark the three largest line items.

Spot and Reserved Instances Recommended

Reserved capacity and Spot & Reserved Instances reduce price in different ways. Reserved instances and savings plans give a discount for committing to steady usage, and fit the baseline you always run. Spot instances give discounts of up to ninety percent in exchange for interruption on short notice, so use them for stateless, restartable work: batch, CI runners, rendering and queue workers.

A common mix is reserved for the base, on-demand for variable load and spot for flexible work. Spread spot across instance types and zones to lower the chance of interruption, checkpoint progress and handle interruption notices.

Practice. Design a mixed fleet for a web tier and a batch tier and give the share of each purchase type.

Cost Monitoring, Budgets and FinOps Core

Cost Monitoring and Budgets start with visibility: tag every resource with team, project and environment, enable cost reports and set budgets with alerts at thresholds and anomaly detection for sudden jumps. Show spend to the teams who cause it.

FinOps is the practice of managing cloud cost together across engineering, finance and product. Its loop is inform, optimise and operate: make costs visible, find savings and build the habit of reviewing them. Unit costs, such as cost per customer or per thousand requests, show whether spending is healthy better than total spend. Good FinOps is about value and accountability, not only cutting.

Practice. Create a budget with alerts and a tag policy, then build a report of spend by team.

Resource Optimization Core

Resource Optimization means paying only for what you need. Right-size instances by measuring utilisation, stop or schedule development environments overnight, delete unattached disks, old snapshots and idle load balancers, and move cold data to cheaper tiers. Prefer newer instance generations and Arm processors where compatible, and use serverless or autoscaling for variable load.

Optimise safely: change one thing at a time, keep headroom for peaks, and watch performance and error rates afterwards. Automate clean-up with policies, and review the biggest cost items first, since a few services usually account for most of the bill.

Practice. Find the five least-used resources in a sandbox account and decide which to delete, resize or keep.