Cloud concepts, architecture and service models
The Cloud Computing Foundations domain covers the vocabulary the rest of the exam builds on: what cloud computing actually is, the five essential characteristics that must all be present, and the economic logic behind adoption. Apply the stated definition carefully rather than assuming a marketing label establishes the operating characteristics.
Definition
NIST SP 800-145 describes cloud computing as a model for enabling ubiquitous, on-demand network access to a shared pool of configurable computing resources that can be provisioned and released with minimal management effort. Three things follow: it is an operating model, not a product; resources are pooled and shared across consumers; and provisioning is self-service and rapid.
The five essential characteristics
- On-demand self-service: the consumer provisions capacity without human interaction with the provider.
- Broad network access: services are reachable over the network from heterogeneous client devices.
- Resource pooling: provider resources serve multiple consumers using a multi-tenant model.
- Rapid elasticity: capacity scales out and in, often automatically, appearing near-unlimited to the consumer.
- Measured service: usage is monitored, controlled and reported through metering, giving transparency to relevant parties. Metering does not require a particular billing scheme.
Within the stated NIST definition, the five characteristics describe the cloud model; the word cloud in marketing alone does not establish them. A virtualised data centre where users raise a ticket and wait three days fails self-service and rapid elasticity, however modern its hardware.
Why organisations adopt it
Public-cloud consumption can reduce upfront hardware purchases and shift costs toward ongoing services. Private-cloud investment, contracts and applicable accounting policies can produce different capital or operating classifications. The exam links this to agility, faster time to market and avoiding over-provisioning for peak - not to a guarantee that cloud is always cheaper.
Worked example
A retailer runs a batch job needing 40 servers for three hours each night, and none for the other twenty-one. On-premises it must buy 40 servers sized for that peak. In cloud it launches 40 instances nightly and terminates them. Which characteristic justifies this? Reasoning: capacity is released as well as provisioned, automatically, on consumer demand - that is rapid elasticity. The nightly bill matching actual consumption is measured service. Scalability concerns accommodating changed demand; elasticity emphasizes adapting capacity to demand and releasing it again. Automation is common but not a universal requirement, and billing follows the actual contract, including storage and reserved charges.
Traps that cost marks
- Treating cloud as a synonym for the internet, or for virtualisation.
- Confusing elasticity (responsive expansion and contraction) with scalability (capacity to accommodate changed demand).
- Assuming multi-tenancy is inherently insecure rather than a control to be assessed.
- Assuming cloud is always cheaper, ignoring integration, migration and egress costs.
The Cloud Architecture and Service Models domain tests how cloud environments are structured and who is responsible for what. You need the NIST reference architecture roles, the three service models with their management boundaries, the four deployment models, and the enabling technologies of virtualisation and multi-tenancy.
Reference architecture roles
NIST SP 500-292 names five actors: the cloud consumer who uses services; the cloud provider who delivers them; the cloud auditor who independently assesses controls; the cloud broker who aggregates, integrates or arbitrages services from multiple providers; and the cloud carrier who provides network connectivity.
Service models and the responsibility boundary
- IaaS: the provider manages hardware, network and hypervisor; the consumer manages operating systems, middleware, runtime, applications and data.
- PaaS: the provider also manages the OS, runtime and middleware; the consumer manages its application code and its data.
- SaaS: the provider manages the whole stack; the consumer still manages identities, access, configuration and the data it puts in.
Deployment models
Private (single organisation), public (open to the market), community (shared by organisations with common concerns) and hybrid (two or more distinct models bound by technology enabling data and application portability). Private describes exclusive use by one organization, not a requirement for a particular location - a private cloud can be hosted by a third party.
Worked example
A team deploys containerised code and configures environment variables and scaling rules, but never patches an operating system or installs a runtime. Which model? Reasoning: the provider owns the OS, runtime and middleware; the team owns only its application and configuration. Control of scaling rules and environment settings does not make it IaaS, because IaaS would leave OS patching with the team. It is PaaS. If the team also chose and patched the OS, the answer would move to IaaS; if the team only used a finished business application, it would be SaaS.
Traps that cost marks
- Assuming SaaS removes all consumer responsibility: data classification, user access reviews and configuration remain yours.
- Confusing community cloud with hybrid cloud, or assuming private cloud must be on-premises.
- Mixing up the broker (service intermediation) with the carrier (connectivity).
- Choosing a service model by technology rather than by which management tasks the consumer keeps.