Cloud Computing Foundations and Terminology

Introduction and Context

Cloud computing has become a foundational model for delivering computing capabilities. Organisations can obtain processing power, storage, databases, networking, platforms, and software through network-accessible services rather than purchasing and operating all infrastructure themselves. This transformation affects not only technology architecture but also budgeting, organisational design, procurement, risk management, software development, and business strategy.

Cloud computing is sometimes described simply as “computing over the Internet.” That description is incomplete. The defining idea is the provision of configurable computing resources as an on-demand, service-oriented, pooled, and often metered capability. A cloud customer does not necessarily know the physical location of a server, storage device, or network path. Instead, the customer consumes an abstracted service with specified performance, availability, security, and pricing characteristics.

The cloud model therefore represents both a technical architecture and an economic arrangement. Technically, it depends on virtualisation, distributed systems, automation, orchestration, high-speed networks, and large-scale data centres. Economically, it enables shared infrastructure, variable capacity, operational expenditure, and rapid access to resources. These benefits are accompanied by limitations involving security, governance, dependency, compliance, performance variability, and cost control.

The National Institute of Standards and Technology (NIST) definition provides a widely used conceptual foundation. NIST characterises cloud computing as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service-provider interaction. This chapter develops the terminology and reasoning needed to understand that definition critically.

Learning Objectives

After completing this chapter, students should be able to:

1. Explain the historical evolution from centralised computing to cloud computing.

2. Describe the NIST essential characteristics of cloud computing.

3. Distinguish elasticity, scalability, resource pooling, multitenancy, and measured service.

4. Explain cloud computing as a form of utility computing and relate it to economic theory.

5. Evaluate the benefits, limitations, and risks of cloud adoption.

6. Apply foundational cloud concepts to a realistic organisational scenario.

7. Use cloud terminology accurately in technical and managerial discussions.

The Evolution of Cloud Computing

From mainframes to distributed computing

Early commercial computing was highly centralised. Mainframes provided shared processing for many users through terminals. Users accessed computing capacity without owning the mainframe, an arrangement that resembles cloud computing in its service orientation. However, early mainframe systems were generally operated within a single organisation, and resource allocation was controlled centrally.

The development of minicomputers and personal computers moved processing closer to users. Client–server computing then distributed applications between client devices and servers. Organisations gained flexibility, but they also acquired responsibility for installing, maintaining, upgrading, securing, and replacing large amounts of infrastructure.

The Internet and service-oriented computing

The growth of the Internet enabled applications to be accessed remotely at global scale. Application service providers offered hosted software, while web hosting companies supplied externally operated servers and storage. These services established important components of the cloud model, although they did not always provide the high degree of automation, elasticity, and resource abstraction associated with modern cloud platforms.

Service-oriented architecture and web services further encouraged the idea that computing capabilities could be exposed through standard interfaces. Instead of treating software as a monolithic product installed on a local machine, organisations began composing applications from network-accessible services.

Virtualisation and data-centre consolidation

Virtualisation allows one physical computer to host multiple logical virtual machines. Each virtual machine can run its own operating system and applications while sharing the underlying hardware. A hypervisor mediates access to processors, memory, storage, and network interfaces.

Virtualisation improved server utilisation and enabled workload isolation. It also made it easier to create, copy, suspend, migrate, and delete computing environments. Data-centre operators could consolidate workloads, automate provisioning, and treat infrastructure as a pool rather than as individually assigned physical machines.

Virtualisation is important but not sufficient for cloud computing. A virtual machine hosted on a local server is not necessarily a cloud service. Cloud computing additionally requires on-demand access, automation, pooling, rapid provisioning, and service management. Some cloud services use containers, serverless execution, or specialised hardware rather than conventional virtual machines.

Utility and hyperscale computing

The expansion of large data centres made it economically feasible to operate computing infrastructure at immense scale. Providers could spread facilities, energy systems, specialist staff, security controls, and procurement costs across many customers. Automation enabled customers to request resources through portals, application programming interfaces (APIs), and infrastructure-as-code tools.

Cloud computing consequently combines ideas from time-sharing, utility services, distributed systems, virtualisation, grid computing, managed hosting, and service-oriented architecture. Its distinctive contribution is the integration of these ideas into a broadly accessible, programmable, elastic, and measured service model.

A Conceptual Model of Cloud Computing

Cloud computing should be understood at several layers.

Physical infrastructure consists of data centres, servers, storage devices, network equipment, power systems, and cooling systems. Customers usually do not manage these elements directly.

Virtualised or abstracted infrastructure exposes logical compute, storage, and networking resources. A customer may create virtual machines, virtual networks, volumes, or containers without handling physical equipment.

Platform services provide managed runtime environments, databases, messaging systems, analytics engines, development tools, and other capabilities. The provider manages more of the underlying stack.

Application services deliver complete software capabilities to end users. The customer normally configures the application and manages data and users rather than operating servers.

This layered view is related to, but distinct from, the service models Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). In IaaS, the customer generally manages operating systems, applications, and data while the provider manages physical infrastructure and virtualisation. In PaaS, the provider manages the operating system and runtime platform, allowing the customer to concentrate on application code and data. In SaaS, the provider operates almost the entire application stack, while the customer manages configuration, users, and business data.

Responsibility is not transferred completely in any model. Security, identity management, data classification, and appropriate configuration remain shared responsibilities. The exact boundary depends on the provider, service, deployment architecture, and contractual terms.

The NIST Essential Characteristics

NIST identifies five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. These characteristics provide a stronger test for identifying cloud computing than the mere fact that a system is remotely hosted.

On-demand self-service

A customer can provision computing capabilities automatically, without requiring direct human interaction with each provider employee. A user may create a database, allocate storage, deploy a virtual machine, or invoke a serverless function through a web portal, command-line tool, or API.

The important feature is not that no human is involved anywhere. Provider staff still maintain systems, approve some requests, and manage capacity. The characteristic means that routine customer provisioning is automated and available through a self-service mechanism.

Broad network access

Cloud capabilities are accessible over networks using standard mechanisms and from a range of client devices. Access may occur through browsers, mobile applications, enterprise systems, command-line interfaces, and APIs.

Broad network access does not mean unrestricted public access. A private cloud service can still require strong authentication, private connectivity, network segmentation, and policy enforcement. The characteristic concerns network-based availability and standard access mechanisms.

Resource pooling

The provider’s computing resources are pooled to serve multiple customers through a multitenant model. Physical and virtual resources are dynamically assigned and reassigned according to demand. Customers generally have limited knowledge of the precise physical location of resources, although they may be able to specify a geographical region, availability zone, or compliance boundary.

Pooling improves utilisation because capacity can be shared across workloads with different demand patterns. It also requires strong isolation, monitoring, scheduling, and capacity-management controls.

Rapid elasticity

Capabilities can be provisioned and released rapidly, often appearing to the customer as unlimited or highly flexible. Elasticity includes both expansion and contraction. A system that can add servers but cannot release unused resources is scalable but not fully elastic.

Elasticity is especially valuable when demand is uncertain or variable. Examples include ticketing systems during an event, online retailers during seasonal promotions, and analytical workloads that run intensively for short periods.

Measured service

Cloud systems automatically control and optimise resource use through metering. Usage may be measured by compute time, storage consumed, number of requests, data transferred, database capacity, or other service-specific units. The measured information supports monitoring, billing, capacity planning, chargeback, and governance.

Measurement does not guarantee low cost. A service can be metered precisely and still become expensive through inefficient architecture, excessive data transfer, idle resources, or uncontrolled consumption.

Foundational Terminology

Scalability

Scalability is the ability of a system to handle increased workload by adding resources or improving resource capacity. Vertical scaling increases the capacity of an existing resource, such as adding memory or processor power to a server. Horizontal scaling adds more instances, nodes, or replicas.

Scalability may be limited by application architecture. A stateless web tier often scales horizontally more easily than a database with tightly coupled state. Scaling also introduces coordination, consistency, licensing, networking, and operational complexity.

Elasticity

Elasticity is the ability to adjust capacity dynamically in response to changing demand. It includes provisioning and deprovisioning resources, preferably close to the time and magnitude of workload change. Elasticity is therefore a dynamic property, whereas scalability is a broader capacity property.

For example, a retailer may scale a web application from 10 instances to 100 during a promotion and return to 10 afterward. If the additional instances remain permanently allocated, the system has increased capacity but has not achieved the economic benefit of elasticity.

Multitenancy

Multitenancy occurs when multiple customers, called tenants, use shared application or infrastructure resources while remaining logically isolated. Tenants may share physical servers, storage systems, databases, networks, or application code.

Isolation can be implemented through virtual machines, containers, access-control policies, encryption, tenant-specific schemas, separate databases, network segmentation, and monitoring. Multitenancy improves utilisation and can reduce cost, but it creates risks such as accidental data disclosure, insecure configuration, noisy-neighbour effects, and shared-vulnerability exposure.

A multitenant system is not necessarily public. A private cloud may serve multiple departments or business units as tenants. Conversely, a public service may offer dedicated resources to a particular customer while still using shared provider facilities.

Resource pooling

Resource pooling is the operational practice of combining capacity into a managed pool and assigning it dynamically. It is broader than virtualisation. A provider may pool compute, storage, network bandwidth, database capacity, or specialised accelerators.

Pooling depends on statistical multiplexing: not all customers reach peak demand at the same moment. The provider can therefore support aggregate demand using less capacity than would be required if every customer maintained an independent peak-sized environment. This benefit is probabilistic rather than unlimited; correlated demand peaks can still produce shortages or service degradation.

Availability and reliability

Availability refers to the proportion of time a service is operational and accessible according to a defined criterion. Reliability concerns the probability that a system performs without failure for a specified period. They are related but not identical. A service may recover quickly after frequent failures and therefore have high availability but lower reliability.

Cloud providers commonly describe availability targets in service-level agreements (SLAs). An SLA is a contractual document, not a guarantee that failure is impossible. It should be examined for measurement methods, exclusions, service credits, maintenance provisions, and customer responsibilities.

Region and availability zone

A region is a geographical area containing cloud infrastructure. An availability zone is a distinct failure domain within a region, often consisting of one or more data centres with independent power, cooling, and networking arrangements. Terminology varies by provider.

Deploying across multiple zones can reduce the effect of a local failure. It does not automatically provide disaster recovery: data replication, application design, recovery procedures, and testing are also required.

Control plane and data plane

The control plane manages resources and configuration, such as creating instances, changing policies, or provisioning networks. The data plane carries the actual application traffic or processes workload data. A control-plane outage may prevent new changes while existing workloads continue operating, whereas a data-plane failure directly affects service execution. Understanding this distinction supports incident analysis and architecture design.

Cloud Computing as Utility Computing

Utility computing treats computing as a service consumed according to need, analogous to electricity or water. Customers obtain capacity without constructing the complete production system. The analogy is useful because it highlights availability, metering, variable consumption, and provider responsibility.

The analogy is not perfect. Electricity is generally standardised and interchangeable at the point of consumption, whereas cloud services differ in APIs, performance, security controls, data portability, and operational semantics. Cloud customers also retain architectural and governance responsibilities that electricity consumers usually do not.

The utility perspective explains why cloud services can change capital expenditure into operating expenditure. In a traditional data centre, an organisation purchases hardware in advance. This creates a capacity-planning problem: purchasing too little capacity causes service constraints, while purchasing too much creates idle assets. Cloud services allow the organisation to acquire capacity incrementally, although long-term reservations and committed-use discounts can reintroduce planning commitments.

A simplified total-cost model can be expressed as:

Total cost = fixed costs + variable consumption costs + operating and governance costs

Fixed costs may include migration, architecture, contracts, and baseline subscriptions. Variable costs may include compute time, storage, requests, and data transfer. Operating and governance costs include engineering labour, security controls, monitoring, compliance, and optimisation. This model is conceptual rather than a universal accounting formula; organisations must define cost categories consistently and include transition costs.

Cloud economics also depends on utilisation. A privately owned server may be paid for regardless of whether it is busy. A cloud resource may be billed according to allocation or consumption, depending on the service. Consequently, cloud adoption does not guarantee savings. A poorly governed cloud environment can accumulate idle instances, unnecessary storage, expensive network traffic, and duplicated services.

Benefits of Cloud Computing

Agility and speed

Self-service APIs and automation reduce the time required to obtain infrastructure. Development teams can create test environments quickly, experiment with new services, and deploy applications through repeatable pipelines.

Flexible capacity

Elastic resources help organisations respond to changing demand without permanently owning peak capacity. This is valuable for seasonal, unpredictable, or rapidly growing workloads.

Access to advanced capabilities

Cloud providers offer managed analytics, artificial intelligence platforms, high-performance computing, global content delivery, security services, and specialised hardware. Organisations can access capabilities that would be expensive or difficult to build independently.

Global reach

Providers operate infrastructure in multiple geographical locations. This can support lower latency, regional service delivery, business continuity, and compliance strategies, subject to data-residency requirements.

Operational focus

Managed services can reduce the amount of undifferentiated infrastructure administration. Staff can concentrate on application functionality, data quality, customer experience, and business outcomes. This does not eliminate operations; it changes the type of operations required.

Measurability and accountability

Usage data can support departmental chargeback, financial accountability, capacity planning, and evidence-based optimisation. When combined with tagging, budgets, and policy enforcement, measurement improves governance.

Limitations, Risks, and Trade-offs

Security and privacy

Cloud providers invest heavily in security, but customers remain responsible for correct configuration and identity management. Public exposure of storage, excessive permissions, weak credentials, insecure APIs, and inadequate logging are common sources of risk. Sensitive data may also be subject to privacy legislation, contractual restrictions, and cross-border transfer rules.

Vendor dependence and portability

Providers expose proprietary APIs, data formats, managed services, and operational tools. Moving an application may require redesign, data conversion, testing, and retraining. Portability should therefore be considered during architecture design rather than only when migration is imminent.

Availability and concentration risk

A provider outage, regional incident, identity-service failure, or network disruption can affect many customers simultaneously. Multi-zone or multi-region strategies can reduce risk but increase cost and complexity.

Performance variability

Shared infrastructure can cause contention, often called the noisy-neighbour effect. Network latency, storage performance, and resource availability may vary. Performance requirements should be measured using realistic workloads rather than assumed from nominal specifications.

Cost unpredictability

Consumption-based pricing can produce unexpected bills. Common causes include untagged resources, unbounded autoscaling, high-volume logging, data egress, abandoned test systems, and requests to managed services. Financial operations, or FinOps, combines engineering, finance, and management practices to address this issue.

Compliance and governance

Regulated organisations must establish controls for access, retention, auditability, encryption, incident response, supplier assurance, and data location. Compliance is a shared process involving provider documentation, contractual controls, technical evidence, and organisational procedures.

Environmental considerations

Large data centres consume electricity and water, although shared infrastructure and high utilisation may be more efficient than fragmented local systems. Environmental assessment should consider workload efficiency, energy sources, hardware lifecycle, data movement, and unnecessary resource consumption. Cloud migration alone is not proof of sustainability.

An Illustrative Applied Case: Regional Healthcare Analytics

Background

A regional healthcare network operates several hospitals and clinics. It maintains an ageing data centre and wants to analyse appointment patterns, equipment utilisation, and readmission indicators. Demand for analytics increases at the end of each month, while interactive dashboards are used throughout the day.

Problem

The existing environment has limited storage expansion, lengthy procurement cycles, and insufficient computing capacity during reporting periods. However, patient information is sensitive, and the organisation must comply with healthcare privacy and records-retention requirements.

Analysis

A direct migration of all data to a public environment would be inappropriate without classification, contractual review, identity redesign, and security assessment. The organisation distinguishes identifiable clinical records from de-identified analytical data. It also identifies recovery objectives, data residency requirements, user roles, and expected workload patterns.

The monthly analytical workload is well suited to elasticity: temporary processing capacity can be added for batch jobs and released afterward. Dashboards require predictable performance, so caching and workload isolation are considered. A managed database may reduce administration, but the team evaluates provider lock-in, export capability, encryption, audit logs, and service availability.

Approach and solution

The organisation adopts a controlled hybrid architecture. Identifiable records remain in a tightly governed environment, while approved de-identified datasets are processed in a cloud analytics platform. Access uses central identity federation and multifactor authentication. Data is encrypted in transit and at rest. Resources are placed in approved regions, tagged by department and project, and monitored through budgets and alerts.

The analytical pipeline is automated. It validates data quality, removes or masks identifying attributes, loads data into a governed store, and runs scheduled analytics jobs. Compute resources scale during batch processing and are released afterward. Independent recovery copies are maintained, and restoration procedures are tested rather than merely documented.

Outcome

The organisation reduces reporting delays and avoids purchasing permanent hardware for a short monthly peak. It also obtains better visibility into resource use. The project does not eliminate governance work: privacy reviews, access certification, cost management, vendor assessment, and operational monitoring become continuous responsibilities.

Learning points

1. Cloud adoption is an architectural and governance decision, not only a hosting decision.

2. Elasticity is valuable when workload demand is temporary or variable.

3. Data classification should precede service selection.

4. Managed services reduce some operational tasks but create provider-dependency considerations.

5. Security, resilience, and cost controls must be designed into the solution.

Best Practices for Foundational Cloud Adoption

Organisations should begin with business and workload requirements rather than selecting services based on novelty. Each workload should be assessed for sensitivity, performance, availability, latency, regulatory constraints, integration dependencies, and recovery objectives.

Identity should be treated as a primary security boundary. Strong authentication, least privilege, role separation, credential rotation, privileged-access monitoring, and periodic access review are essential. Network controls, encryption, vulnerability management, logging, and incident response should complement identity controls.

Infrastructure should be defined through version-controlled code where practical. Automated provisioning improves repeatability and reduces configuration drift. Resource tags, ownership metadata, budgets, quotas, and policy-as-code support accountability.

Architects should design for failure. They should identify failure domains, avoid unnecessary single points of failure, define recovery point and recovery time objectives, and test restoration. High availability is not the same as backup or disaster recovery.

Cost management should begin at design time. Teams should estimate demand, compare pricing models, use lifecycle policies for storage, remove idle resources, monitor data transfer, and review managed-service consumption. Cost optimisation must not undermine security, reliability, or legal obligations.

Finally, organisations should maintain a deliberate exit strategy. This does not require avoiding all proprietary services, but it does require understanding data export, contractual termination, portability, skill availability, and the cost of replacing a service.

Contemporary Developments

Cloud platforms increasingly combine virtual machines, containers, managed Kubernetes, serverless functions, event-driven services, and specialised accelerators. Serverless computing extends the utility model by abstracting server management and often charging according to invocations, execution duration, or provisioned capacity. It does not mean that servers do not exist; rather, their management is largely hidden from the customer.

Edge computing places processing closer to users, devices, or industrial sites to reduce latency and bandwidth use. Edge environments may complement rather than replace central cloud regions. Their distributed nature creates additional challenges involving physical security, intermittent connectivity, software updates, and fleet management.

Artificial intelligence services are increasingly consumed through cloud APIs and managed platforms. These services raise additional concerns about data provenance, confidentiality, model bias, explainability, intellectual property, and unpredictable consumption costs. AI workloads may also require accelerators whose availability and pricing differ from general-purpose compute.

Cloud-native architecture commonly uses automation, immutable deployment artefacts, containers, observability, continuous delivery, and loosely coupled services. These practices can improve delivery and resilience, but they also introduce complexity. Cloud-native does not mean automatically secure, inexpensive, or appropriate for every workload.

Chapter Summary

Cloud computing is a service-oriented model that provides network-accessible, pooled, configurable resources which can be provisioned and released rapidly. Its development draws on mainframes, time-sharing, the Internet, service-oriented architecture, virtualisation, distributed systems, and hyperscale data centres.

The NIST essential characteristics are on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Scalability concerns the ability to handle increased workload; elasticity concerns dynamic expansion and contraction. Multitenancy allows multiple customers or organisational units to share resources with logical isolation. Resource pooling improves utilisation through statistical multiplexing, while measurement supports billing, monitoring, accountability, and optimisation.

Cloud computing resembles a utility because customers consume capabilities without owning all underlying infrastructure and may pay according to use. Its economic rationale includes shared resources, reduced provisioning delay, variable capacity, and access to specialised services. Nevertheless, cloud adoption can increase costs when consumption is poorly governed and does not remove responsibilities for security, privacy, resilience, compliance, or architecture.

Effective cloud adoption requires workload assessment, identity-centred security, automation, observability, financial governance, failure planning, regulatory analysis, and an informed approach to portability. Cloud is best understood not as a location but as a model for delivering and managing computing capabilities.

Key Terms

Cloud computing: A model for delivering shared, configurable computing resources over networks with rapid provisioning and release.

On-demand self-service: Automated customer provisioning without requiring direct provider-employee interaction for each request.

Broad network access: Network-based access through standard mechanisms and diverse client devices.

Resource pooling: Dynamic aggregation and assignment of provider resources across workloads or tenants.

Rapid elasticity: The ability to expand and contract resource capacity quickly in response to demand.

Measured service: Automatic monitoring and metering of resource consumption.

Scalability: The ability of a system to handle increased workload by adding or improving resources.

Elasticity: Dynamic scaling up and down in response to changing demand.

Multitenancy: Shared use of resources by multiple customers with logical isolation.

Virtualisation: Abstraction of physical computing resources into logical machines or environments.

IaaS: A service model providing virtualised computing, storage, and networking resources.

PaaS: A service model providing managed application platforms and runtimes.

SaaS: A service model delivering complete applications as services.

Utility computing: The provision of computing capabilities as a metered utility.

Service-level agreement: A contractual statement of service commitments, measurements, and remedies.

Availability zone: A provider-defined failure domain within a geographical region.

Control plane: Components that manage resource configuration and administration.

Data plane: Components that execute workloads or carry application traffic.

FinOps: Collaborative financial-management practices for controlling and optimising cloud consumption.

Vendor lock-in: Dependence on a provider that makes migration or replacement difficult or costly.

Review Questions

Short Answer Questions

1. What are the five essential characteristics identified in the NIST cloud computing model?

2. Distinguish vertical scaling from horizontal scaling.

3. Why is virtualisation alone not sufficient to define cloud computing?

4. What is meant by multitenancy?

5. Why does measured service not automatically guarantee low cloud costs?

Long Answer Questions

1. Explain the historical evolution from mainframe computing to modern cloud computing.

2. Compare IaaS, PaaS, and SaaS, including the changing responsibilities of the provider and customer.

3. Discuss the economic rationale for cloud computing and explain why cloud adoption may not reduce total cost in every case.

4. Explain the relationship between resource pooling, multitenancy, statistical multiplexing, and elasticity.

5. Evaluate the principal security, compliance, availability, and vendor-dependence limitations of cloud computing.

Analytical / Application Questions

1. A university experiences a tenfold increase in online examination traffic for two weeks each semester. Analyse whether elasticity, horizontal scaling, or both should be used, and identify the main governance risks.

2. A regulated organisation wants to move identifiable customer records to a public cloud. Develop a decision framework covering data classification, identity, encryption, residency, resilience, contracts, and exit planning.

3. A development team reports that its cloud bill doubled even though user numbers remained constant. Propose a structured investigation using measured service, tagging, monitoring, architecture review, and FinOps practices.

Multiple Choice Questions with Answers

Question 1

Which characteristic means that customers can provision resources automatically without direct interaction with provider staff for each request?

A. Broad network access

B. On-demand self-service

C. Measured service

D. Resource pooling

Correct Answer: B. On-demand self-service

Question 2

Which statement best distinguishes elasticity from scalability?

A. Elasticity concerns only physical servers, while scalability concerns software

B. Scalability is always automatic, while elasticity is always manual

C. Elasticity includes dynamic expansion and contraction in response to demand

D. Scalability applies only to storage, while elasticity applies only to networks

Correct Answer: C. Elasticity includes dynamic expansion and contraction in response to demand

Question 3

What is the main economic benefit of statistical multiplexing in a cloud environment?

A. It guarantees that every customer receives peak capacity simultaneously

B. It allows pooled capacity to be shared across workloads with different demand patterns

C. It eliminates the need for monitoring and capacity planning

D. It prevents all performance variation between tenants

Correct Answer: B. It allows pooled capacity to be shared across workloads with different demand patterns

Question 4

Which service model generally leaves the customer responsible for the operating system and applications while the provider manages physical infrastructure and virtualisation?

A. Software as a Service

B. Platform as a Service

C. Infrastructure as a Service

D. Business Process as a Service

Correct Answer: C. Infrastructure as a Service

Question 5

A system increases from 10 application instances to 100 during a promotion and returns to 10 afterward. Which concept is most directly illustrated?

A. Elasticity

B. Data residency

C. Vendor lock-in

D. Encryption at rest

Correct Answer: A. Elasticity

Question 6

Which statement about multitenancy is correct?

A. It requires every tenant to have a physically separate data centre

B. It allows multiple tenants to share resources while requiring logical isolation

C. It means that all tenants can access one another’s data

D. It is possible only in private clouds

Correct Answer: B. It allows multiple tenants to share resources while requiring logical isolation

Question 7

Which item is primarily a control-plane activity?

A. Processing an end user’s transaction

B. Streaming application data to a customer

C. Creating a virtual network through an administration API

D. Serving a web page from an application instance

Correct Answer: C. Creating a virtual network through an administration API

Question 8

Why can a cloud deployment become unexpectedly expensive?

A. Cloud services are never metered

B. Elasticity always reduces resource consumption to zero

C. Idle resources, data transfer, unbounded scaling, and excessive logging can increase consumption

D. Resource pooling prevents providers from charging for usage

Correct Answer: C. Idle resources, data transfer, unbounded scaling, and excessive logging can increase consumption

Question 9

Which statement most accurately describes an availability zone?

A. A customer’s billing account

B. A distinct provider-defined failure domain within a region

C. A software licence for a virtual machine

D. A protocol used for encrypting data

Correct Answer: B. A distinct provider-defined failure domain within a region

Question 10

Which practice best supports cloud portability and exit planning?

A. Ignoring data-export requirements until contract termination

B. Documenting proprietary dependencies and testing data and application export procedures

C. Using the highest number of provider-specific services in every workload

D. Avoiding all monitoring to reduce operational complexity

Correct Answer: B. Documenting proprietary dependencies and testing data and application export procedures