EXIN Cloud Computing Foundation cheat sheet
EXIN Cloud Computing Foundation · Keep the key ideas within reach.
Cloud Computing Foundations
Essential characteristics (ISO/IEC 17788 and NIST): on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service.
Service models: SaaS delivers applications; PaaS delivers runtime and development platforms; IaaS delivers compute, storage, and network.
Deployment models: public, private, community, and hybrid; hybrid combines two or more distinct models bound by data or application portability technology.
Economies of scale: large providers spread fixed costs over many tenants, lowering unit price; this is a primary driver of cloud adoption.
CapEx to OpEx shift: cloud converts upfront capital investment into recurring operating expenditure, changing budgeting and accounting treatment.
Elasticity vs scalability: elasticity matches resources to demand automatically and temporarily; scalability is the ability to handle growth in a sustained way.
Multitenancy means one physical instance serves several customers with logical isolation; it underpins pooling but concentrates risk.
Cloud bursting moves peak load to a public cloud while the baseline runs in a private environment; it requires compatible images and networking.
Measured service enables chargeback and showback, typically metered per vCPU-hour, GB-month, or per request.
Cloud Architecture and Service Models
IaaS gives the consumer control over OS, middleware, and applications; the provider manages virtualization, hosts, storage, and networking.
PaaS removes OS and runtime management from the consumer, who controls only deployed applications and limited configuration.
SaaS leaves the consumer with user access management and data; everything below the application is provider-managed.
Shared responsibility line moves down the stack from IaaS to SaaS: the higher the service model, the more the provider secures.
Loose coupling and statelessness let components scale independently and survive node failure; state is externalized to a data store.
Horizontal scaling adds instances behind a load balancer; vertical scaling enlarges a single instance and is bounded by hardware limits.
A CDN caches content at edge locations, reducing latency and origin load; cache invalidation strategy determines freshness.
Availability zones are isolated datacenter groups within a region; multi-AZ deployment removes single-datacenter failure as a cause of outage.
Serverless (FaaS) bills per invocation and execution time, scales to zero, and imposes runtime time limits and cold-start latency.
Cloud Adoption and Implementation
Migration strategies (the 6 Rs): rehost, replatform, repurchase, refactor, retain, retire; each carries different cost and effort.
Rehost (lift and shift) is fastest but forgoes cloud-native benefits; refactor yields the most benefit at the highest cost and risk.
A cloud strategy starts with business drivers and a portfolio assessment; workload placement follows, not precedes, that analysis.
TCO comparison must include egress fees, integration, retraining, licensing, and decommissioning, not only the compute price.
Pilot-first adoption: migrate a low-risk, well-understood workload to validate operating model before scaling.
Vendor lock-in risk rises with proprietary APIs and data services; portability is preserved by open standards, containers, and exportable data.
A cloud center of excellence sets standards, guardrails, and reusable templates; it enables rather than centralizes all delivery.
Exit strategy: contractual rights to export data in a standard format and defined transition assistance reduce lock-in exposure.
Readiness assessment covers skills, governance, network capacity, security posture, and application dependencies before migration.
Cloud Security, Risk and Compliance
Confidentiality, integrity, and availability remain the security triad; cloud changes where controls are implemented, not the goals.
Identity is the new perimeter: federated identity, MFA, and least-privilege roles are primary controls in cloud environments.
Encryption at rest and in transit; key management options are provider-managed, customer-managed (BYOK), or held in an HSM.
Data residency and sovereignty: legal jurisdiction follows where data is stored and processed, so region choice is a compliance decision.
Shared responsibility model: provider secures the cloud infrastructure; customer secures what they put in the cloud, per service model.
Compliance attestations (ISO/IEC 27001, SOC 2) are inherited from the provider only for in-scope services; the customer still needs own controls.
Breach notification duties and audit rights should be written into the contract, including subcontractor and data-deletion terms.
Risk treatment options: mitigate, transfer, avoid, accept; residual risk must be documented and owned.
Insider threat and misconfiguration are leading cloud incident causes; configuration baselines and continuous scanning are control responses.
Cloud Operations and Management
SLI is a measured indicator; SLO is the target range for that indicator; SLA is the contractual commitment with remedies.
Availability is often expressed as nines: 99.9% allows about 43 minutes downtime per month; 99.99% about 4.3 minutes.
Error budget equals 1 minus SLO; it quantifies acceptable unreliability and governs release velocity decisions.
Monitoring covers metrics, logs, and traces; observability adds the ability to answer unanticipated questions from that telemetry.
Capacity management in cloud relies on autoscaling policies with defined minimum, maximum, and scaling triggers.
Patch and configuration management remain customer duties in IaaS; in PaaS and SaaS the provider handles the underlying layers.
Backup and disaster management: define RTO (acceptable downtime) and RPO (acceptable data loss), then choose strategy to meet them.
FinOps practices: tagging for cost allocation, rightsizing idle resources, reserved or committed use discounts, and budget alerts.
Change and release management uses blue-green or canary deployment to limit blast radius and enable fast rollback.
Cloud Operations and Management (Service Management)
Incident management restores service quickly; problem management finds and removes root cause; the two have different goals and timelines.
Service catalogue lists available services with owners, tiers, and costs; request fulfilment draws from it.
Configuration management database records configuration items and dependencies, enabling impact analysis during incidents.
Change advisory: standard changes are pre-approved; normal changes need review; emergency changes are retrospective.
Capacity and performance reporting should align to SLOs, not raw infrastructure metrics alone.
Vendor management: track provider SLAs, credits, escalation paths, and periodic service review meetings.
Continual improvement uses incident trends, post-incident reviews, and SLO attainment to prioritize remediation work.
Asset and licence management prevents unbounded cloud spend and audit exposure from unmanaged resources.
Automation of routine operations reduces toil and human error; runbooks should be versioned and tested.
Cloud Operations and Management (Cost and Performance)
Rightsizing compares allocated resources against actual utilization; sustained low utilization signals over-provisioning.
Reserved instances and savings plans trade commitment for discount; suitability depends on stable baseline demand.
Spot or preemptible capacity is cheapest but can be reclaimed with short notice; use for fault-tolerant batch work.
Egress and inter-region traffic are commonly overlooked cost drivers; architecture should minimize cross-zone data transfer where possible.
Autoscaling to zero eliminates idle cost for intermittent workloads; stateful services usually cannot scale to zero cheaply.
Cost anomaly detection and budget alerts catch drift before month-end; tagging hygiene is a prerequisite for attribution.
Performance testing in cloud must model network latency between zones and services, not just compute capacity.
Storage tiering (hot, cool, archive) reduces cost; retrieval latency and minimum storage duration are the trade-offs.
Cloud Operations and Management (Resilience)
RTO is the maximum acceptable time to restore service; RPO is the maximum acceptable data loss measured in time.
Backup, pilot light, warm standby, and active-active are increasing orders of resilience cost and decreasing orders of RTO.
Multi-region active-active requires data replication and conflict resolution; latency budgets constrain synchronous replication.
Chaos engineering tests resilience by injecting controlled failures; it validates assumptions rather than proving correctness.
Health checks and load balancer failover remove unhealthy instances; misconfigured thresholds cause flapping or slow detection.
Dependency mapping identifies single points of failure; a resilient design removes them or provides degraded-mode behavior.
Regular restore testing is required: an untested backup is an unverified assumption, not a recovery capability.
Graceful degradation and circuit breakers prevent cascading failure when a downstream dependency slows or fails.
Post-incident review without blame produces actionable findings; track corrective actions to closure.