Cloud Concepts and Architecture
What to know
Cloud architecture rests on a few load-bearing ideas. On-demand self-service and broad network access describe how consumers provision resources without human intervention from the provider. Resource pooling and rapid elasticity explain multi-tenancy and the ability to scale out and back in. Measured service ties consumption to billing. Know the service models (IaaS, PaaS, SaaS) by who manages what: in IaaS you still own the guest OS and runtime; in PaaS the provider owns the OS and runtime but not your application or data; in SaaS you own only your data and configuration. Deployment models (public, private, hybrid, community) describe tenancy and control, not technology.
Traps
Questions love to blur the line between high availability (surviving a component failure, often within a region), fault tolerance (no interruption, redundant everything), disaster recovery (recovering after a site loss, measured by RTO/RPO), and scalability (capacity to grow) versus elasticity (automatic matching of capacity to demand). Another trap: assuming multi-region equals multi-AZ, or that a managed service removes all customer responsibility. Shared-responsibility questions usually hinge on the boundary: provider secures the cloud; you secure what you put in it.
Worked example
A team needs an app that survives the loss of a single data center but tolerates a few minutes of degradation. That is high availability across availability zones, not fault tolerance (which would demand active-active everywhere) and not DR (which implies a region loss). Rule of thumb: pick the smallest architecture that meets the stated failure scope and RTO.
Rule of thumb
Map every requirement to one axis - failure scope (AZ, region), management boundary (service model), or demand pattern (scale vs. elasticity) - before choosing a design.