Establish cloud characteristics and service boundaries

A cloud specialist begins with an operational question: what capability will the team receive, and how can its cloud claim be checked? An Internet-facing application, a monthly invoice, or a virtual machine alone is insufficient evidence. NIST defines a model for convenient, on-demand network access to configurable resources that can be provisioned and released rapidly with little management effort or provider interaction. Its five essential characteristics are a lens for examining a particular offer, not a quality certificate or a promise that the offer is secure or suitable for every workload. An organization can use a genuine cloud service and still design a poor application. It can also run a useful application on a fixed rented server that does not exhibit all the model's characteristics. Keep classification separate from fitness for purpose.

First, on-demand self-service means a consumer can provision a defined capability, such as compute or storage, automatically when needed without a human ticket for each request. Observe an actual provisioning path and its permission boundary rather than relying on a marketing screenshot. Second, broad network access means capabilities can be reached through standard mechanisms by different client platforms. This does not mean every resource must be public. A public endpoint may lead to a protected private service; authorization requires a separate identity and network design. Third, resource pooling means the provider dynamically assigns and reassigns pooled resources across multiple consumers, with limited knowledge of the exact physical machine. A customer may choose a high-level location such as a region without owning a particular host. A claim that a data centre is nearby does not demonstrate pooling.

Fourth, rapid elasticity means capacity can expand and contract in response to demand using a real mechanism. Manually increasing a server size a week later does not show rapid elasticity, although it may suit a steady workload. Record the trigger, time to scale, capacity limit, and effect on application state. Fifth, measured service means resource use is metered, controlled, monitored and reported at an appropriate level. A fixed invoice alone does not demonstrate metering. Conversely, a metered service may include fixed charges, so inspect usage counters rather than inferring the mechanism from the invoice format. Metering can inform capacity and cost decisions, but it cannot by itself assign shared spend correctly to teams.

Build a five-row evidence table with columns for characteristic, claim, observable evidence, result (shown, not shown, or contradicted), and observation limit. Ask for dated evidence specific to the offer and region under consideration. If no evidence is available, record 'not shown' rather than 'contradicted': an absent record is not proof of an absent capability. A successful small test cannot be generalized automatically to every product tier or region. A responsible result may be 'verify before classification' instead of a premature binary verdict. After classification, examine latency, data location, operating roles, recovery and cost separately. The five characteristics do not answer these design questions by themselves.

Distinguish a resource, a service, and a workload. A resource is a unit such as compute or storage. A service packages resources with an operating and billing model. A workload is the application, data and traffic using those services. For a course-booking application, rising demand is a workload observation. 'Automatically expands within two minutes' is a service claim. Completed bookings under peak traffic are a workload test result. If compute expands while database connections fail, first identify the bottleneck rather than saying the compute service did not scale. Do not infer lower total cost from elasticity alone: idle capacity, data transfer, or a contractual minimum can change the arithmetic.

The specialist's role here is to prepare an evidence record, a safe small test and a conditional recommendation. It is not to approve a contract, certify a provider, or claim legal compliance. State assumptions, what can be tested safely, and who owns purchasing and operating decisions. Do not put real customer data in an unapproved lab. When comparing offers, hold the unit of comparison constant: requests per minute, scaling delay, usage meter and region. A label such as 'cloud' without these particulars is not a sufficient decision record. A polished console does not replace one measured, documented experiment.

In the decision record, separate service capability from organizational policy. A provider console may allow immediate provisioning while an internal approval rule prevents staff from using it without authorization. Record these in separate fields: what the service can technically do and what the organization permits. A mandatory manual action by the provider on every request is different evidence that affects self-service for the offer being assessed. Record the request time, resource-ready time, and actor. This allows the conclusion to be revisited if account rights or the package change instead of turning a provider name into a fixed judgment.

Give each characteristic row a confidence level. A single screenshot can show that a feature appeared in a trial account, but does not establish availability for the enterprise account or suitability of its operating limit at peak. Attach a specific document or test request, owner, and date to every 'not shown' result; do not treat it as tacit approval. When new evidence arrives, reassess the affected row and document the decision change. The classification record can then be audited without becoming an untested promise of performance or security. This matters when an offer differs by region or between trial and production. Do not generalize a short observation to an entire season; identify the workload range, observation period and limits under which the result was seen.