ITIL 4 Cloud Services flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Utility and warranty

Utility is fitness for purpose, the functional outcome a cloud service delivers. Warranty is fitness for use, covering availability, capacity, continuity, and security. Strategy approval requires both.

Cloud deployment models

Public, private, hybrid, and community. Hybrid means two or more distinct models joined by technology enabling data and application portability. The choice follows residency, isolation, and cost constraints.

Shared responsibility boundary

The split of security and operational duties between provider and consumer. In IaaS the consumer owns the OS upward; in PaaS the application and data; in SaaS configuration and data governance.

Service catalogue versus pipeline

The service portfolio holds all services across pipeline, catalogue, and retired states. Only live services offered to customers appear in the catalogue and can be requested.

Exit and portability design

A design requirement covering data export formats, identity federation, contractual exit assistance, and transition periods, agreed before provider selection so lock-in risk is bounded.

Elasticity as design constraint

The ability to scale resources automatically with demand. Design must address capacity ceilings, cost of scale-out, stateful component behaviour, and isolation under multi-tenant load.

Demand tiering

Separating baseline, variable, and peak demand, then matching each tier to a sourcing pattern such as reserved capacity, on-demand instances, or spot capacity rather than sizing for peak.

Data sovereignty constraint

Legal requirement that data remains subject to the laws of the jurisdiction where it is stored. It determines eligible providers and regions before cost or feature comparison begins.

Standard change

A pre-authorised, low-risk change with a defined trigger and documented procedure. It is recorded but does not require case-by-case authorisation by the change authority.

Blue/green deployment

Two identical environments where traffic switches from live to new version at once. Rollback is fast because the previous environment remains intact and available.

Canary release

Progressive traffic shift to a new version for a small user subset, with monitoring before wider rollout. It limits blast radius but requires comparable metrics across versions.

Major incident

An incident with significant business impact requiring a separate escalation path, a dedicated coordinator, and scheduled stakeholder communications rather than standard queue handling.

Known error

A problem with a documented root cause and workaround, recorded in the known error database so the service desk can resolve recurrences faster.

Event classification

Every alert is classed as informational, warning, or exception. Only exceptions generate incidents, which prevents alert fatigue and keeps operational attention on actionable signals.

Service request fulfilment

Handling of standard, pre-approved user requests raised through the service catalogue. Requests follow an agreed procedure and do not pass through change authorisation.

Configuration item tagging

Cloud resources are discovered and recorded in the CMDB through tags. Untagged or unmanaged resources are invisible to inventory and treated as a control failure.

Rollback cost profile

The effort and risk of reversing a deployment. Blue/green keeps it low, canary moderate, rolling higher, because replaced instances may no longer be available.

Least privilege in cloud

Granting only the permissions needed for a task, using roles and scoped policies. Identity is the primary control plane, so excess permissions are the main breach path.

Provider attestation scope

Certifications such as ISO/IEC 27001, SOC 2, and PCI DSS evidence the provider's controls, not the consumer's configuration. Consumer-side evidence must be collected separately.

Policy as code

Governance intent expressed as automated guardrails, for example denying public storage or restricting regions. It scales to elastic environments where manual review cannot.

Sub-processor chain

The provider's own suppliers that handle data or deliver service components. Each layer adds dependency and must be recorded in the risk register and contract notices.

Cloud concentration risk

Dependence on a single provider or region for critical services. Treatment includes multi-region design, portable data formats, and documented exit plans.

Access recertification

Periodic review confirming each account still needs its roles. It detects privilege creep that accumulates as staff change teams or projects in elastic cloud environments.

Data classification controls

Classification determines retention period, encryption at rest and in transit, permitted geographic location, and verified deletion. Controls follow from the class, not from convenience.

Breach notification clause

A contractual term fixing how quickly the provider must inform the consumer of a security incident, enabling the consumer to meet its own regulatory reporting deadline.

Continual improvement model

Seven steps: vision, current position, target position, how to get there, take action, did we get there, keep momentum. Each cycle feeds the improvement register.

Error budget

One minus the service level objective. It quantifies acceptable unreliability and makes the trade-off between release velocity and stability explicit and negotiable.

Outcome-based measurement

Tracking indicators tied to customer outcomes rather than provider activity. Ticket volume and uptime percentages alone do not evidence value delivered.

Value co-creation

Value emerges from the provider's service plus the consumer's usage and configuration. Improvement must therefore span the boundary, not sit inside one organisation.

Improvement register entry

A recorded improvement with an owner, a baseline measure, a target, a review date, and expected value, so progress can be verified rather than assumed.

Cloud cost optimisation

Rightsizing, removing idle resources, and matching commitment models to demand. It reduces waste while preserving utility, and is a value lever rather than a finance task.

Post-implementation review

A check after a significant change confirming whether intended value was realised. Deviations are logged in the improvement register with follow-up actions.