1. Cloud Computing and Deployment Foundations

Introduction and Context

Cloud deployment has become a central concern in modern software engineering. Applications that were once installed on dedicated servers are now commonly delivered through elastic infrastructure, managed platforms, containers, serverless runtimes, and globally distributed services. For a full-stack developer, this change is not merely a change in hosting location. It changes how applications are designed, secured, monitored, scaled, priced, and governed.

Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) provide broadly similar categories of capability, although their product names, architectures, pricing models, and operational interfaces differ. A sound understanding of cloud foundations therefore begins with concepts rather than with memorising vendor-specific services. The essential questions are: What is being delivered as a service? Who is responsible for operating it? Where is it located? How does it respond to changing demand? What happens when infrastructure fails? And which deployment model best fits the organisation's technical, regulatory, and financial requirements?

Cloud computing brings together several older ideas—distributed systems, virtualisation, utility computing, networking, automation, and managed services—within a commercially accessible model. Its value lies not simply in remote storage or virtual machines, but in the ability to provision computing resources rapidly, use them programmatically, and adjust them to changing requirements.

Learning Objectives

After studying this chapter, students should be able to:

1. Define cloud computing and explain its relationship with distributed systems and virtualisation.

2. Distinguish elasticity from scalability and explain why both matter in deployment.

3. Describe regions, availability zones, fault domains, and global cloud architecture.

4. Compare public, private, hybrid, and multi-cloud deployment models.

5. Differentiate IaaS, PaaS, SaaS, and FaaS according to control and responsibility.

6. Apply the shared-responsibility model to security and operations.

7. Evaluate cloud choices using technical, organisational, financial, governance, and ethical criteria.

8. Identify common deployment risks and emerging developments in cloud computing.

From Dedicated Infrastructure to Cloud Computing

Traditional information technology commonly relied on physical servers purchased, installed, and maintained by an organisation. Capacity planning was performed in advance. If a business expected substantial growth, it might purchase additional servers even though they would remain underused for long periods. If demand exceeded the forecast, procuring and installing new hardware could take weeks or months.

Cloud computing changes this arrangement by making computing resources available on demand through network-accessible services. The National Institute of Standards and Technology (NIST) describes cloud computing through characteristics such as on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. These characteristics distinguish cloud computing from simply placing an existing server in a remote data centre.

A cloud customer typically requests resources through a web console, command-line interface, software development kit, or infrastructure-as-code system. The provider allocates resources from a large pool of physical infrastructure and charges according to an agreed pricing model. Resources may include compute capacity, storage, databases, networks, analytics, security controls, artificial intelligence services, and application platforms.

The term “cloud” does not mean that technology has become intangible. Cloud services depend on physical data centres, power systems, cooling, networking equipment, servers, storage devices, and operational personnel. Cloud abstraction hides much of this complexity from the customer, but it does not eliminate it. Understanding this distinction is important when considering performance, resilience, location of data, environmental impact, and provider dependency.

Distributed Systems and Virtualisation

A distributed system consists of multiple computing components that cooperate through a network to provide a service. The components may be located in the same facility or across different geographical locations. From the user's perspective, the system may appear to be a single application even though requests are processed by many machines.

Distributed systems provide opportunities for performance, availability, and geographical reach, but they also introduce complexity. Networks can fail, messages can be delayed or duplicated, clocks are not perfectly synchronised, and different components may temporarily hold different versions of data. Consequently, cloud deployment requires more than selecting a server size. Developers must consider failure detection, retries, consistency, idempotency, observability, and recovery.

Virtualisation is one of the principal technologies that enabled modern cloud services. A hypervisor allows several virtual machines (VMs) to share the hardware of a physical host. Each VM generally has its own operating system, virtual CPU, memory allocation, storage devices, and network interfaces. The hypervisor isolates workloads and schedules their use of physical resources.

Virtual machines improve utilisation and make infrastructure easier to provision, copy, and manage. However, they still include complete operating systems, which creates overhead in image management, patching, and startup time. Containers provide a lighter form of isolation by allowing multiple applications to share the host operating system kernel while remaining separated through operating-system mechanisms. Containers are portable and efficient, but they are not automatically secure; their images, runtime permissions, dependencies, and orchestration systems require careful management.

Serverless computing extends abstraction further. In a serverless model, the provider manages the underlying servers and commonly executes application code in response to events or requests. The customer remains responsible for application logic, permissions, data handling, and configuration. “Serverless” therefore means that server management is abstracted from the customer, not that servers do not exist.

Core Cloud Characteristics

On-demand self-service and automation

Users can provision resources without waiting for manual intervention from a provider's operations team. This capability is especially valuable when combined with automation. Infrastructure can be described in code, reviewed, tested, versioned, and reproduced across environments. Tools such as Terraform, AWS CloudFormation, Azure Resource Manager, and Google Cloud Deployment Manager support this general approach, although their features differ.

Resource pooling and abstraction

Providers pool physical resources and allocate them among customers using logical isolation and scheduling. Customers normally do not know the exact physical server on which a workload runs. They may, however, select a region, availability zone, hardware class, or compliance-related location.

Measured service

Cloud usage is metered through dimensions such as compute time, storage volume, requests, data transfer, database capacity, or function invocations. This enables usage-based charging but also creates financial risk. A misconfigured application can generate unexpected requests, storage, or network traffic.

Elasticity

Elasticity is the ability of a system to acquire or release resources in response to changing demand. It is dynamic and closely associated with automation. For example, an application may add instances when request latency rises and remove them when demand falls.

Scalability

Scalability is the ability of a system to handle increased workload by adding resources or improving its design. Vertical scaling increases the capacity of an individual resource, such as assigning more memory to a virtual machine. Horizontal scaling adds more instances or nodes. Horizontal scaling often supports greater resilience, but it may require stateless application design, shared session storage, load balancing, and careful data management.

Elasticity and scalability are related but not identical. A system may be scalable because additional instances can be added, but not elastic if this process requires manual intervention. Conversely, automatic elasticity cannot compensate for an application architecture that has a fixed database bottleneck or inefficient code.

Regions, Availability Zones, and Failure Domains

Cloud providers organise infrastructure geographically. A region is a defined geographical area containing one or more physically separate data-centre groupings. Regions are selected according to latency, legal requirements, data residency, service availability, disaster-recovery objectives, and cost.

An availability zone (AZ) is an isolated location or group of locations within a region, designed to reduce the effect of failures in another zone. The precise architecture differs by provider, but zones generally have independent power, cooling, and networking arrangements. Deploying an application across multiple zones can protect against a failure affecting one zone, provided that the application and its data services are also designed for such distribution.

A region is not automatically a disaster-recovery strategy. If a workload operates in only one zone, it may remain vulnerable to zone-level failure. If it operates in only one region, it may remain vulnerable to a major regional disruption, configuration error, or regional network problem. Multi-region design can improve resilience but introduces additional cost, latency, data-replication complexity, and governance challenges.

Cloud providers also offer global services, including content delivery networks, domain name systems, identity services, and global traffic management. These services may not map neatly to a single region. A deployment plan must therefore distinguish between the location of application compute, data storage, management control planes, and end users.

The Shared-Responsibility Model

Cloud security is a shared responsibility between the provider and the customer. The provider is generally responsible for the security of the cloud: physical facilities, hardware, foundational networking, and the managed infrastructure underlying a service. The customer is responsible for security in the cloud, including identity permissions, application code, data classification, configuration, operating-system patching where applicable, and network rules.

The boundary changes according to the service model. With an IaaS virtual machine, the customer commonly manages the guest operating system, installed software, access controls, and much of the network configuration. With a managed database, the provider manages the database infrastructure and often the database engine's maintenance, while the customer remains responsible for identities, schemas, data access, backups selected, and appropriate configuration. With SaaS, the provider manages most technical components, but the customer still controls users, data, business settings, and access policies.

A frequent professional mistake is to assume that using a reputable provider makes an application secure by default. Cloud platforms provide security capabilities, but those capabilities must be configured and operated correctly. Excessive permissions, publicly exposed storage, unencrypted secrets, unpatched images, weak logging, and insecure application programming interfaces remain customer-side risks.

A useful method is to create a responsibility matrix for every deployed component. The matrix should identify who provisions, patches, monitors, backs up, secures, and recovers each layer. It should also specify escalation paths and evidence required for audits.

Service Models: Choosing the Level of Abstraction

Infrastructure as a Service (IaaS)

IaaS provides fundamental computing resources such as virtual machines, block storage, networks, and firewalls. It offers substantial control and is suitable when an organisation needs a particular operating system, network design, legacy application environment, or specialised configuration. The trade-off is operational responsibility. Customers must manage more of the stack, including patching, hardening, capacity planning, and often high availability.

Platform as a Service (PaaS)

PaaS provides a managed environment for deploying applications without requiring the customer to administer the underlying operating system and much of the runtime infrastructure. Examples include managed application platforms, database services, and development environments. PaaS can improve developer productivity and standardisation, but it may impose restrictions on runtime, networking, deployment methods, or portability.

Software as a Service (SaaS)

SaaS delivers a complete application to end users, usually through a browser or client application. The provider operates the application and underlying infrastructure. Customers configure the service, manage users and permissions, govern their data, and assess contractual and compliance conditions. SaaS reduces infrastructure work but can create dependence on the provider's features, availability, data formats, and pricing.

Function as a Service (FaaS)

FaaS executes discrete functions in response to events such as HTTP requests, file uploads, messages, or scheduled triggers. It supports fine-grained scaling and can reduce the need to manage servers. However, functions may have execution limits, startup latency, statelessness requirements, complex distributed tracing, and provider-specific interfaces. FaaS is particularly useful for event processing, automation, lightweight APIs, and integration tasks, but it is not suitable for every workload.

The service models form a spectrum of control and responsibility. IaaS gives the customer more control and more operational work; SaaS gives the customer less infrastructure control and less infrastructure work. PaaS and FaaS occupy intermediate or specialised positions. The appropriate choice depends on the required customisation, skills, compliance, performance, portability, and speed of delivery.

Deployment Models: Public, Private, Hybrid, and Multi-Cloud

A public cloud is operated by a third-party provider and offers services to multiple customers through shared underlying infrastructure and logical isolation. Public cloud provides rapid access to broad capabilities and usually avoids the capital expense of owning data-centre infrastructure. Its challenges include variable operating costs, provider dependency, configuration complexity, and the need to understand data location and contractual terms.

A private cloud is dedicated to one organisation. It may be operated in the organisation's own facilities or by a third party. Private cloud can support specialised security, control, or regulatory requirements, but the organisation may retain significant responsibility for hardware, capacity, upgrades, and operations. Merely owning servers does not create a private cloud; self-service, automation, pooling, and measured resource management are also relevant.

A hybrid cloud combines private infrastructure with public-cloud services. It may be used to keep sensitive systems in a controlled environment while using public cloud for burst capacity, analytics, backup, or customer-facing services. Hybrid architecture is technically demanding because it requires secure connectivity, consistent identity, compatible data processes, monitoring across environments, and reliable integration.

Multi-cloud means using services from two or more public-cloud providers. Organisations may adopt this approach to access specialised capabilities, negotiate commercial terms, reduce dependence on one provider, or meet geographical requirements. However, multi-cloud does not automatically improve resilience. If the same application design, identity weakness, or operational error is reproduced across providers, risk may increase rather than decrease. Multi-cloud also requires broader skills, more complex observability, and careful data-portability planning.

A Decision Framework for Cloud Deployment

A cloud decision should begin with workload analysis rather than with a preference for a particular product. Important dimensions include:

• Workload characteristics: transaction volume, latency, peak demand, statefulness, storage needs, and integration requirements.
• Resilience objectives: acceptable downtime, recovery time objective (RTO), and recovery point objective (RPO).
• Security and compliance: sensitivity of data, identity controls, encryption, auditability, residency, and sector-specific obligations.
• Economics: capital expenditure, operating expenditure, utilisation, licensing, migration cost, support, data transfer, and exit cost.
• Skills and operating model: internal expertise, DevOps maturity, support coverage, and responsibility for incidents.
• Portability and strategic dependence: use of open standards, proprietary services, data export capability, and contractual flexibility.
• Sustainability: resource efficiency, workload utilisation, data retention, and provider transparency concerning energy and environmental performance.

This framework prevents a common error: treating cloud migration as a simple relocation project. Some workloads benefit from rehosting with minimal change. Others should be refactored into managed services, containers, or event-driven components. In some situations, retaining or retiring a workload is more appropriate than migrating it.

Practical Deployment Architecture

Consider a web application composed of a browser-based frontend, an application programming interface, a relational database, an object-storage system, and an asynchronous job processor. A foundational cloud architecture might place the frontend behind a content delivery network, distribute application instances across at least two availability zones, place them behind a load balancer, and keep the database in a private network segment. Object storage can hold uploaded files, while a managed queue can separate user requests from slow background tasks.

This design illustrates several principles. The application tier can scale horizontally. The database requires a separate availability and backup strategy. Queues reduce tight coupling and help absorb bursts. Identity and access management should assign narrowly scoped permissions to each component. Logs, metrics, traces, alerts, and audit events should be collected centrally. Infrastructure should be reproducible through code, and deployment should progress through development, test, staging, and production environments using controlled pipelines.

A full-stack developer does not need to administer every infrastructure layer personally, but must understand how application decisions affect cloud behaviour. For example, storing sessions only in local memory may fail when requests move between instances. Retrying a non-idempotent payment request may create duplicate transactions. Large uncompressed assets may increase latency and transfer costs. These are cloud deployment concerns as much as they are programming concerns.

Illustrative Case Study: Moving an Online Learning Platform to the Cloud

Background

LearnSphere, a fictional education company, operates an online learning platform for video courses, assessments, instructor dashboards, and learner discussions. Its original deployment uses two physical application servers and a single database in a rented facility.

Situation and Problem

At the beginning of each academic term, traffic increases sharply. During the previous enrolment period, response times became unacceptable and the database reached its connection limit. The company also experienced a prolonged outage when the facility's network equipment failed. Management wants faster delivery and improved resilience but has a limited operations team.

Analysis

The platform has several different workload patterns. Video files are large and mostly read-only, making them suitable for object storage and content delivery. The web and API tiers experience unpredictable traffic and can be made largely stateless. Assessment submissions require transactional consistency, while email notifications and report generation can occur asynchronously. Student records are sensitive and require strong access control, auditability, backups, and defined retention practices.

A direct move of the two servers to two virtual machines would improve provisioning but would not solve the database bottleneck or create an elastic architecture. A managed relational database, object storage, a queue service, and automated horizontal scaling are more appropriate for the workload.

Approach and Strategy

The company adopts a public-cloud architecture in one region with application instances distributed across multiple availability zones. A load balancer distributes traffic. Static frontend assets and course videos are served through a content delivery network. The database is placed in a private network area with automated backups and a tested recovery procedure. A queue handles notification and report-generation tasks. Identity roles are created for the application, deployment pipeline, support engineers, and auditors, each with limited permissions.

The team defines an RTO of two hours and an RPO of fifteen minutes for the core learning database. These targets guide backup frequency, replication choices, and recovery testing. Infrastructure is defined as code, and deployments use automated tests followed by staged release. Monitoring includes latency, error rate, database connections, queue depth, storage access, and unusual authentication activity.

Outcome

The architecture can add application capacity during enrolment and reduce it afterwards. Video delivery no longer consumes application-server bandwidth, and background tasks do not block user requests. The company also gains clearer operational ownership. However, monthly cost becomes more variable, and the team must continuously review permissions, resource limits, backup restoration, and spending alerts.

Learning Points

The case demonstrates that cloud value comes from architectural alignment, not from relocation alone. Different workload components may require different service models. Availability must be designed across failure domains. Recovery objectives should be explicit. Managed services reduce some operational work but do not remove governance, security, testing, or cost-management responsibilities.

Risks, Limitations, and Common Mistakes

Cloud systems introduce or amplify several risks. Misconfiguration is a major source of exposure, particularly in identity policies, network rules, storage permissions, and secrets management. Insecure application code remains insecure after migration. Excessive reliance on a proprietary service can make later migration expensive. Data transfer charges may be overlooked when services communicate across regions or providers.

Other common mistakes include selecting a region without considering legal requirements, assuming that a backup is usable without testing restoration, placing every component in one availability zone, scaling the application tier while ignoring the database, and creating excessive operational complexity through premature microservices or multi-cloud adoption.

Cloud outages also demonstrate that no provider offers absolute availability. A responsible design uses redundancy appropriate to business objectives, graceful degradation, circuit breakers, retry limits, health checks, and documented incident procedures. High availability is not the same as disaster recovery, and disaster recovery is not the same as business continuity. Business continuity includes people, processes, suppliers, communication, and organisational decision-making.

Governance, Ethics, and Professional Responsibility

Cloud deployment involves governance as well as engineering. Organisations should classify data, define retention periods, document processing purposes, control privileged access, and preserve audit evidence. Applicable privacy and sector regulations may require controls over personal data, cross-border transfers, breach reporting, or third-party risk.

Ethical practice includes avoiding unnecessary collection and retention of personal information, protecting users from preventable exposure, and communicating service limitations honestly. Cost controls are also a professional responsibility: an abandoned test resource may waste organisational funds, while uncontrolled autoscaling may create a financial incident. Environmental responsibility requires attention to utilisation, storage retention, inefficient data movement, and workload design.

Automation should be governed rather than trusted blindly. Deployment pipelines need review controls, protected production environments, secret rotation, policy checks, and rollback procedures. When automated systems make security or scaling decisions, teams should retain sufficient logging and human oversight to investigate unexpected outcomes.

Current Developments and Emerging Directions

Cloud platforms increasingly combine managed Kubernetes, serverless containers, event-driven systems, confidential-computing options, edge services, and specialised artificial-intelligence infrastructure. Platform engineering seeks to provide internal developer platforms that standardise deployment, security, observability, and governance while allowing development teams to work efficiently.

FinOps has emerged as a collaborative discipline connecting engineering, finance, and business teams. Its focus is not simply reducing expenditure, but obtaining measurable value from cloud consumption through forecasting, allocation, rightsizing, architectural decisions, and accountability.

Artificial intelligence is also influencing cloud deployment through managed model services, automated operations, anomaly detection, and code assistance. These capabilities introduce additional concerns involving data privacy, model security, cost, explainability, and supplier dependence. Edge computing places processing closer to users or devices, reducing latency in selected use cases but increasing the difficulty of software distribution and fleet management.

These developments do not replace foundational principles. Identity, least privilege, resilience, observability, data governance, automation, and explicit responsibility remain necessary regardless of the provider or deployment style.

Best Practices for Foundational Cloud Deployment

A disciplined organisation generally:

1. Begins with business and workload requirements rather than product selection.

2. Uses least privilege, strong authentication, encryption, and centralised audit logging.

3. Defines RTO and RPO and tests restoration and failover procedures.

4. Designs for failure across appropriate zones or regions.

5. Automates infrastructure and deployment using version-controlled definitions.

6. Establishes budgets, tagging, ownership, and spending alerts.

7. Treats observability as a design requirement, not as an afterthought.

8. Prefers managed services when their operational and strategic trade-offs are understood.

9. Documents provider responsibilities and customer responsibilities.

10. Reviews portability, compliance, sustainability, and exit implications before committing to critical services.

Chapter Summary

Cloud computing provides on-demand, network-accessible, metered computing resources through shared and automated infrastructure. It is built on virtualisation, distributed systems, networking, automation, and managed services. Elasticity describes dynamic adjustment to demand, while scalability describes the capacity to handle greater workload through vertical or horizontal growth. Regions and availability zones provide geographical and failure-domain choices, but resilience must be designed and tested rather than assumed.

The shared-responsibility model divides duties between provider and customer, with the boundary varying across IaaS, PaaS, SaaS, and FaaS. Public, private, hybrid, and multi-cloud models offer different combinations of control, agility, complexity, and dependency. Sound decisions consider workload behaviour, security, compliance, economics, skills, recovery objectives, portability, and sustainability. Cloud deployment is therefore an architectural and governance decision, not simply a hosting decision.

Key Terms

Cloud computing: Delivery of computing resources and services over a network with on-demand provisioning and measured usage.

Distributed system: A set of networked components that cooperate to provide a service.

Virtualisation: Abstraction of physical computing resources into isolated logical environments.

Hypervisor: Software that creates and manages virtual machines on physical hardware.

Container: A process-isolated software package that shares the host operating-system kernel.

Elasticity: The ability to add or remove resources dynamically as demand changes.

Scalability: The ability of a system to handle increased workload through additional capacity or improved design.

Region: A geographical area containing cloud infrastructure and one or more availability zones.

Availability zone: An isolated cloud infrastructure location within a region, designed to limit the effect of local failure.

Failure domain: A set of components likely to be affected by the same fault.

Shared responsibility: A security model dividing operational duties between a cloud provider and its customer.

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

PaaS: A managed application platform that reduces responsibility for underlying infrastructure.

SaaS: A complete software application delivered and operated by a provider.

FaaS: An event-driven execution model in which providers run discrete functions on demand.

Public cloud: Cloud infrastructure operated by a provider for multiple customers.

Private cloud: Cloud infrastructure dedicated to one organisation.

Hybrid cloud: An architecture combining private infrastructure with public-cloud services.

Multi-cloud: Use of services from two or more public-cloud providers.

RTO and RPO: Recovery time objective defines acceptable restoration time; recovery point objective defines acceptable data loss measured in time.

Review Questions

Short Answer Questions

1. What characteristics distinguish cloud computing from ordinary remote hosting?

2. Define elasticity and explain how it differs from scalability.

3. What is the purpose of an availability zone?

4. Why does the shared-responsibility boundary change between IaaS and SaaS?

5. State one principal benefit and one challenge of PaaS.

Long Answer Questions

1. Explain how virtualisation and distributed systems support modern cloud computing.

2. Compare IaaS, PaaS, SaaS, and FaaS in terms of control, responsibility, and suitable use cases.

3. Discuss the differences among public, private, hybrid, and multi-cloud deployment models.

4. Explain how regions, availability zones, and failure domains influence high-availability design.

5. Develop a framework for evaluating whether an organisation should migrate a workload to the cloud.

Analytical / Application Questions

1. A web application receives unpredictable traffic, stores sensitive customer data, and performs long-running report generation. Propose an appropriate cloud architecture and justify your service-model choices.

2. An organisation claims that adopting two cloud providers automatically guarantees resilience. Critically assess this claim using concepts from the chapter.

3. A company has moved its application to cloud virtual machines but still experiences outages and escalating costs. Diagnose likely architectural and governance problems and recommend corrective actions.

22. Multiple Choice Questions with Answers

Question 1

Which characteristic most directly distinguishes cloud computing from simply placing a server in a remote data centre?

A. The server uses a physical hard disk

B. Resources can be provisioned on demand and usage can be measured

C. The application has a graphical user interface

D. The data centre is owned by a government

Correct Answer: B. Resources can be provisioned on demand and usage can be measured

Question 2

A system automatically adds application instances when demand rises and removes them when demand falls. This is primarily an example of:

A. Elasticity

B. Encryption

C. Vertical partitioning

D. Data residency

Correct Answer: A. Elasticity

Question 3

Which statement best describes an availability zone?

A. A billing category for a virtual machine

B. A programming language used in cloud functions

C. An isolated infrastructure location within a region

D. A private cloud operated by a customer

Correct Answer: C. An isolated infrastructure location within a region

Question 4

Under the shared-responsibility model, which activity is generally the customer's responsibility when using a cloud virtual machine?

A. Maintaining the provider's physical cooling system

B. Replacing failed provider-owned hardware

C. Managing the guest operating system and application permissions

D. Securing the provider's data-centre perimeter

Correct Answer: C. Managing the guest operating system and application permissions

Question 5

An organisation wants to deploy application code without managing the operating system or server runtime. Which service model most closely fits this requirement?

A. IaaS

B. PaaS

C. Colocation

D. Bare-metal hosting

Correct Answer: B. PaaS

Question 6

Which scenario best represents a hybrid-cloud deployment?

A. Using only one public-cloud provider in one region

B. Using two laptops for development

C. Combining an organisation's private infrastructure with public-cloud services

D. Running two virtual machines on the same physical server

Correct Answer: C. Combining an organisation's private infrastructure with public-cloud services

Question 7

Why does deploying an application across multiple availability zones not automatically guarantee disaster recovery?

A. Availability zones cannot host databases

B. The application and its data services must also be designed and tested for failure

C. Zones always belong to different countries

D. Multiple zones eliminate the need for backups

Correct Answer: B. The application and its data services must also be designed and tested for failure

Question 8

A team chooses FaaS for event-triggered image processing. Which design consideration is especially relevant?

A. Functions normally require permanent local server sessions

B. Functions may have execution limits and should usually be designed as stateless units

C. FaaS requires customers to purchase physical servers

D. FaaS prevents all vendor dependence

Correct Answer: B. Functions may have execution limits and should usually be designed as stateless units

Question 9

Which factor is least appropriate as the sole basis for selecting a cloud deployment model?

A. Regulatory and data-residency requirements

B. Recovery objectives and workload behaviour

C. A preference for a provider's product name without workload analysis

D. Available organisational skills and operating capability

Correct Answer: C. A preference for a provider's product name without workload analysis

Question 10

A company uses two cloud providers but duplicates the same weak identity policy and has no cross-provider monitoring. What does this demonstrate?

A. Multi-cloud automatically removes operational risk

B. Multi-cloud can increase complexity without guaranteeing resilience

C. Private cloud is always less secure

D. Elasticity eliminates governance requirements

Correct Answer: B. Multi-cloud can increase complexity without guaranteeing resilience