Cloud Architecture and Service Selection

Introduction and Context

Cloud architecture is the planned arrangement of computing, storage, networking, security, data, and operational components that delivers a business capability through cloud services. Service selection is the disciplined process of choosing among infrastructure, platform, software, and managed services so that the resulting solution satisfies technical, financial, regulatory, and operational requirements.

A cloud solution should not begin with a preferred vendor or a list of fashionable services. It should begin with the workload. A workload is a set of applications, data, users, processes, and operating characteristics that together consume computing resources. Different workloads have different priorities. A public website may require rapid elasticity and global availability; a financial reporting system may prioritise data integrity, auditability, and predictable performance; a scientific batch workload may value low cost and throughput more than immediate response time.

The central professional skill is therefore translation: converting business requirements into measurable workload requirements, then converting those requirements into an architecture and a justified service choice.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain the principal characteristics and layers of cloud architecture.
2. Translate business requirements into measurable technical criteria.
3. Distinguish scalability, elasticity, availability, resilience, performance, and portability.
4. Select appropriately among infrastructure, platform, software, serverless, and managed services.
5. Compare architectural alternatives using total cost of ownership and risk.
6. Design a basic resilient cloud architecture and identify its limitations.
7. Evaluate governance, security, compliance, vendor-lock-in, and operational concerns.

1. From Business Need to Workload Profile

Architecture decisions are reliable only when requirements are explicit. A useful requirements statement includes the following dimensions:

Functional and non-functional requirements

Functional requirements describe what a system does, such as accepting an order or generating an invoice. Non-functional requirements describe how well it does it. Cloud architecture is strongly influenced by non-functional requirements because they determine redundancy, capacity, monitoring, security controls, and service type.

Requirements should be testable. “The application must be fast” is weak. “95% of catalogue requests must complete within 300 ms under 2,000 requests per second” is measurable, although it still requires a defined test method and measurement location.

Demand classification

Demand commonly has four components:

• Baseline demand: the normal, relatively predictable load.
• Peak demand: the highest expected load during ordinary operation.
• Burst demand: a sudden increase caused by an event, campaign, or failure.
• Growth demand: the expected increase over months or years.

A workload may be steady, seasonal, bursty, or unpredictable. This classification influences whether capacity should be provisioned permanently, scaled automatically, queued, or purchased through a flexible consumption model.

2. The Cloud Architecture Model

A practical cloud architecture can be understood as a set of cooperating layers rather than as a single product.

1. User and access layer: browsers, mobile applications, partner systems, identity providers, and APIs.
2. Edge and delivery layer: DNS, content delivery networks, web application firewalls, and load balancers.
3. Application layer: web services, business logic, background workers, containers, functions, and integration components.
4. Data layer: relational databases, non-relational databases, object storage, caches, search indexes, and message stores.
5. Network layer: virtual networks, subnets, routing, gateways, private links, and network security controls.
6. Management layer: identity and access management, monitoring, logging, configuration, automation, and policy.
7. Physical and regional foundation: data centres, availability zones, regions, power, cooling, and hardware operated by the provider.

The layers are logically distinct but operationally connected. A database cannot deliver its required performance if the network path is poorly designed. An application cannot be secure if identities and secrets are inadequately controlled. A multi-zone design does not provide genuine resilience if all traffic still depends on one unprotected gateway.

Figure: A layered cloud architecture with redundant application and data components across two availability zones.

3. Core Quality Attributes

Scalability and elasticity

Scalability is the ability of a system to accommodate increased workload by adding resources or improving resource capacity. Vertical scaling increases the size of an instance; horizontal scaling adds instances. Horizontal scaling is often preferred for stateless application services because instances can be added or removed without changing the application’s logical function.

Elasticity is the ability to provision and release resources in response to changing demand. A system can be scalable without being elastic: an organisation may be able to add servers, but only through a slow manual process. Elasticity requires automation, suitable metrics, fast provisioning, and an application design that tolerates changing capacity.

A common scaling trigger is utilisation, but utilisation alone is not sufficient. Queue depth, request latency, concurrency, and business throughput may be better indicators. Scaling policies also require a stabilisation period; otherwise, rapid scale-out and scale-in can produce oscillation and unnecessary cost.

Availability and resilience

Availability describes the proportion of time a service is operational and accessible. A simple availability ratio is:

Both uptime and downtime must use the same time unit. If a service is available for 99,900 minutes and unavailable for 100 minutes, availability is 99,900 ÷ 100,000 = 99.9%.

A target of 99.9% permits approximately 43.2 minutes of unavailability in a 30-day month, using 43,200 minutes. A target of 99.99% permits approximately 4.32 minutes. These figures are targets, not guarantees, and the measurement definition must specify exclusions, maintenance, dependencies, and the observation period.

Resilience is the ability to withstand, recover from, and adapt to faults. Availability measures an outcome; resilience describes the capability and behaviour that produce acceptable outcomes during failure. Resilience techniques include redundancy, health checks, retry policies, circuit breakers, queueing, replication, backups, graceful degradation, and tested recovery procedures.

Recovery objectives are particularly important:

• Recovery time objective (RTO): the maximum acceptable time to restore service after a disruptive event.
• Recovery point objective (RPO): the maximum acceptable amount of data loss measured in time. An RPO of 15 minutes means that losing up to 15 minutes of changes is considered acceptable.

Low RTO and low RPO generally increase complexity and cost. Synchronous replication may reduce data loss but can introduce latency and dependence between locations. Asynchronous replication can improve distance and performance characteristics but permits some replication lag.

Performance and capacity

Performance includes latency, throughput, concurrency, and resource efficiency. Latency is the time taken to complete an operation; throughput is the amount completed per unit of time. Percentiles are often more informative than averages. A p95 latency of 300 ms means 95% of observations are no slower than 300 ms; it does not describe the worst 5%.

A basic capacity estimate is:

The safety factor is dimensionless and represents uncertainty, burst tolerance, and operational headroom. This is an engineering approximation, not a universal sizing law. It must be validated through load testing because application efficiency, dependency limits, and workload mix affect actual capacity.

For a service expecting 800 requests per second and a safety factor of 1.25, estimated capacity is at least 1,000 requests per second. If one instance sustains 250 requests per second under the agreed latency target, at least four instances are required before considering failure tolerance. A design requiring continued service after one instance fails would normally add another instance or use a capacity policy that maintains sufficient surviving capacity.

Queueing can separate producers from consumers and absorb temporary bursts. However, queues do not eliminate work; they delay it. A queue-based design must define maximum acceptable waiting time, duplicate-message handling, ordering requirements, dead-letter processing, and consumer failure behaviour.

Portability and interoperability

Portability is the ease with which an application, data set, or operational process can be moved between environments. It is affected by proprietary APIs, managed database features, identity models, networking assumptions, infrastructure-as-code tools, data formats, and operational skills.

Portability is not automatically the same as multi-cloud. A deliberately portable design may reduce dependency risk, but strict portability can prevent use of valuable managed capabilities and increase cost. The correct choice depends on the probability and impact of migration, the organisation’s bargaining position, regulatory requirements, and the value of provider-specific services.

4. Cloud Service Models and Selection

Infrastructure as a Service

Infrastructure as a Service (IaaS) provides virtual machines, disks, networks, and related primitives. The customer normally controls the operating system, installed software, configuration, and much of the security maintenance. IaaS is appropriate when the organisation needs operating-system control, must run legacy software, or requires specialised configurations.

Its disadvantages include patching responsibility, larger operational workload, slower delivery, and more opportunities for configuration error.

Platform as a Service

Platform as a Service (PaaS) supplies a managed application runtime, database, integration platform, or development environment. The provider manages more of the underlying infrastructure, while the customer manages application code, data, and configuration. PaaS can improve delivery speed and reduce routine administration, but available runtimes, networking, scaling behaviour, and migration options must be assessed.

Containers and container orchestration

Containers package application code and dependencies in a repeatable unit. They improve consistency between development and production and can support portability. An orchestration platform manages scheduling, networking, service discovery, scaling, and rolling deployment. Containers do not remove operational complexity: image security, cluster upgrades, observability, resource limits, and persistent storage remain important responsibilities.

Serverless and Functions as a Service

Functions as a Service executes short-lived units of code in response to events or requests. It is attractive for irregular workloads because capacity management is largely automated and billing commonly follows invocation and execution measures. Limitations can include startup delay, execution duration limits, provider-specific interfaces, difficult local testing, and complex distributed tracing.

Serverless does not mean “without servers”; it means that the provider abstracts server management from the customer. The application still requires secure identities, monitoring, error handling, data management, and cost controls.

Software as a Service

Software as a Service (SaaS) delivers a complete application managed by a provider. It is generally the highest level of abstraction. SaaS may be preferable for standard business functions such as collaboration, customer relationship management, or human resources, where differentiation through custom software is limited. Selection should examine data location, integration, identity federation, service-level commitments, export facilities, configuration limits, and exit arrangements.

A selection decision rule

Service selection should consider the following sequence:

1. Is the requirement a standard business capability that can be safely purchased as SaaS?
2. If custom logic is required, can a managed PaaS or serverless service meet it?
3. If runtime control or legacy compatibility is essential, is IaaS justified?
4. What operational responsibilities, failure modes, limits, and exit costs accompany the choice?
5. Does the service satisfy security, performance, availability, compliance, and cost requirements under realistic load?

The least abstract service is not automatically the most flexible, and the most managed service is not automatically the cheapest. The decision should optimise business value and risk rather than control for its own sake.

5. Architectural Patterns for Common Workloads

Three-tier web architecture

A conventional three-tier design separates presentation, application logic, and data. A public load balancer distributes traffic to multiple application instances. The application tier remains stateless where possible, allowing horizontal scaling. A managed database provides persistence, while object storage may hold media and backups. A cache reduces repeated database reads.

This pattern is understandable and widely supported, but it requires careful session handling, database scaling, cache invalidation, and protection against cascading failure.

Event-driven architecture

In an event-driven design, components publish events and other components consume them asynchronously. This reduces direct coupling and supports independent scaling. It is useful for order processing, notifications, audit pipelines, and integration. It introduces eventual consistency, duplicate delivery, ordering concerns, and more complex diagnosis.

Batch architecture

Batch workloads process accumulated data at scheduled or triggered times. They can use queues, temporary compute fleets, object storage, and workflow services. Cost can be reduced by using interruptible or spare capacity where the workload can retry. The architecture should define checkpointing, idempotency, partial failure handling, and completion deadlines.

Hybrid architecture

A hybrid design connects on-premises infrastructure with cloud services. It may be required because of latency, existing investments, sovereignty, or equipment constraints. Hybrid networking must address routing, bandwidth, encryption, identity integration, DNS, monitoring, and failure of the interconnection. It should not be assumed that a private link removes the need for application-level security.

6. Total Cost of Ownership and Economic Selection

Cloud economics include more than the hourly price of virtual machines. Relevant cost categories include compute, storage, data transfer, managed services, licences, support, observability, security tooling, labour, migration, training, backup, and the cost of downtime.

A simplified monthly cost model is:

Each term represents a monthly monetary cost, and the model is useful only when the terms are defined consistently. C_risk may include expected loss from outages, security incidents, or contractual penalties, but estimating it requires explicit assumptions and should not be presented as precise fact.

For example, a design with monthly infrastructure charges of £2,400, managed-service charges of £900, network charges of £300, and operations labour allocated at £1,400 has a direct estimated monthly total of £5,000. If an alternative reduces infrastructure to £2,000 but increases operations labour to £2,500 and introduces £600 of additional tooling, its estimated total is £5,100. The lower infrastructure invoice does not make it the lower-cost architecture.

Cost optimisation practices include rightsizing, automatic shutdown of non-production resources, storage lifecycle policies, suitable purchasing commitments, workload scheduling, caching, and monitoring of anomalous consumption. Optimisation must not undermine required resilience or security. A cheaper architecture that fails to meet the service objective is not economically successful.

7. A Practical Architecture Selection Framework

A repeatable selection process can be organised into five stages.

Stage 1: Discover

Document business objectives, users, dependencies, data classifications, workload patterns, legal constraints, and current pain points. Identify assumptions and unknowns rather than hiding them.

Stage 2: Quantify

Define targets for throughput, latency, availability, RTO, RPO, growth, and cost. Specify how each will be measured. Distinguish hard constraints from preferences.

Stage 3: Propose alternatives

Develop at least two plausible architectures. For each, show service choices, trust boundaries, data flows, failure domains, scaling mechanisms, operational ownership, and migration implications.

Stage 4: Evaluate

Use a weighted decision matrix, but do not let numerical scoring conceal critical constraints. A design that violates a regulatory requirement cannot compensate through a high score in convenience. Test performance and failure behaviour with prototypes or proof-of-concept work.

Stage 5: Decide and govern

Record the decision, assumptions, rejected alternatives, risks, owners, and review date. Architecture is not complete at deployment; monitoring, incident learning, cost review, and technology change may require revision.

8. Illustrative Case: Regional Online Bookstore

The following is a fictional illustrative case.

Background

A regional bookstore operates an online catalogue and ordering system. Normal traffic is 300 requests per second, but marketing campaigns can produce 1,500 requests per second. Orders must not be lost. Catalogue pages should respond within 400 ms at p95 during normal operation. The business can tolerate up to 30 minutes of service restoration after a regional failure and up to five minutes of order-data loss. The initial monthly technology budget is £8,000.

Problem

The existing system runs on one virtual machine with a local database. A traffic spike causes slow responses, and a machine failure causes an extended outage. The business wants to scale without buying permanent capacity for campaign peaks.

Analysis

The workload is bursty, has a relatively read-heavy catalogue, and contains a transactionally important order path. Catalogue traffic can be cached, but order creation requires durable data and controlled concurrency. The requirement of five-minute RPO makes infrequent daily backups insufficient.

Approach and solution

A suitable target architecture is:

• A CDN and web application firewall for static catalogue content and basic protection.
• A load balancer distributing traffic across at least two availability zones.
• Stateless application instances in an automatically scaling group.
• A managed relational database with high availability and backups, plus replication suitable for the five-minute RPO.
• An in-memory cache for frequently accessed catalogue data, with explicit invalidation rules.
• A durable queue for non-critical asynchronous tasks such as email and stock-notification processing.
• Centralised logs, metrics, traces, alerts, and an operational dashboard.
• Encrypted secrets managed through a dedicated secrets service rather than source code.
• A tested recovery procedure for a regional incident, with an explicit decision about whether a second region is financially justified.

The design should keep order creation synchronous through the database transaction, while allowing email and reporting to be asynchronous. Idempotency keys should prevent a retried request from creating duplicate orders. Database connection pooling and load testing are essential because adding application instances does not automatically increase database capacity.

Outcome

The proposed architecture addresses burst capacity through horizontal scaling and caching, improves availability through multiple failure domains, and reduces operational burden through managed services. It remains subject to testing. In particular, the team must verify p95 latency, database transaction capacity, cache behaviour, queue recovery, restore time, and the actual cost during campaign traffic.

Learning points

1. Different paths in one application can require different consistency and scaling strategies.
2. A managed service reduces some responsibilities but does not remove design accountability.
3. Recovery objectives must be demonstrated through exercises, not merely written in a document.
4. Cost must include operations, data transfer, monitoring, backups, and resilience.
5. Scalability is useful only when dependencies, especially databases, can support it.

9. Governance, Security, Ethics, and Regulation

Cloud architecture operates within a shared-responsibility model. The provider secures the underlying service infrastructure, while the customer remains responsible for appropriate configuration, identities, data use, application security, and compliance obligations. The exact division varies by service model and must be confirmed from authoritative provider documentation.

Important controls include least-privilege access, multi-factor authentication, separation of duties, encryption in transit and at rest, secure key management, vulnerability management, centralised audit logs, backup protection, network segmentation, and incident response. Logs may contain personal or confidential information; retention and access therefore require governance.

Data protection laws may regulate collection, processing, retention, transfer, and deletion. Data residency is not the same as complete legal compliance. Organisations must also examine processor agreements, sub-processors, breach notification duties, sector standards, and records of processing.

Ethical concerns include opaque automated decisions, excessive monitoring, unequal access to digital services, energy consumption, and the concentration of critical infrastructure in a small number of providers. AI services require additional scrutiny of training-data rights, confidentiality, output reliability, bias, human oversight, and reproducibility. AI should be selected because it satisfies a validated business requirement, not simply because it is available.

10. Challenges and Limitations

Cloud architecture does not eliminate complexity; it redistributes it. Common difficulties include:

• Vendor lock-in: provider-specific APIs and data services may make migration expensive.
• Uncontrolled consumption: elastic resources can produce unexpected bills.
• Distributed-system failure: networks fail, messages duplicate, clocks differ, and dependencies become unavailable.
• Configuration risk: insecure storage, excessive permissions, and exposed management interfaces remain common causes of incidents.
• Observability gaps: a service may appear healthy while users experience dependency or data-path failures.
• False resilience: redundant application servers do not help if the database, identity service, or deployment pipeline is a single point of failure.
• Skills and organisational change: successful adoption requires automation, operational learning, and clear ownership.

Trade-offs must be made explicit. Higher availability often requires redundancy and operational effort. Greater portability may limit provider-native capabilities. Stronger consistency may reduce geographical flexibility. Faster delivery through managed services may increase dependence on a provider. There is no universally optimal cloud architecture.

11. Contemporary Practices and Best Practices

Infrastructure as Code expresses environments in version-controlled definitions and supports repeatable deployment. Continuous integration and continuous delivery automate testing and controlled release. Immutable deployment, blue-green release, canary release, and automated rollback reduce change risk when supported by suitable monitoring.

Platform engineering provides internal teams with standardised, governed paths for deploying applications. FinOps combines engineering, finance, and business accountability to manage cloud value rather than merely reduce invoices. Policy as code can enforce approved regions, encryption, tagging, and network controls automatically.

A professional implementation should:

1. Start with measurable requirements and documented assumptions.
2. Design for failure rather than assuming infrastructure is permanently available.
3. Prefer managed services when their operational and strategic trade-offs are acceptable.
4. Keep application components stateless where practical and externalise durable state.
5. Test scaling, restoration, dependency failure, security controls, and cost behaviour.
6. Use least privilege and treat identity as a primary security boundary.
7. Monitor user outcomes, not only infrastructure utilisation.
8. Tag resources and assign cost ownership.
9. Document service limits, exit options, and operational responsibilities.
10. Review architecture as workload, regulation, technology, and business priorities change.

Chapter Summary

Cloud architecture translates business capabilities and workload characteristics into a coordinated design of applications, data, networks, security, and operations. Effective selection begins with measurable requirements for demand, performance, availability, resilience, recovery, cost, compliance, and portability.

Scalability accommodates increased demand, while elasticity automates capacity changes. Availability measures operational accessibility; resilience describes the ability to withstand and recover from failure. Performance requires attention to latency, throughput, concurrency, and dependency limits. Service models range from IaaS, which offers control, to SaaS, which offers the greatest abstraction. PaaS, containers, and serverless services occupy important intermediate positions.

Architecture decisions should compare alternatives using total cost, operational responsibility, failure behaviour, security, portability, and business value. Patterns such as multi-zone web systems, event-driven processing, batch architectures, and hybrid connectivity are useful starting points, but each carries trade-offs. Governance, testing, observability, identity management, cost controls, and recovery exercises are essential to professional practice. There is no universally best cloud architecture; there is only an architecture appropriate to clearly understood requirements and accepted risks.

Key Terms

Cloud architecture: The structured design of cloud-based computing, data, networking, security, and management components.

Workload: An application, data set, users, processes, and operating characteristics treated as a unit for planning.

Scalability: The ability to accommodate increased workload by adding or improving resources.

Elasticity: The ability to provision and release resources automatically as demand changes.

Availability: The proportion of a defined period during which a service is operational and accessible.

Resilience: The ability to withstand, recover from, and adapt to failures.

Latency: The time taken to complete an operation or deliver a response.

Throughput: The quantity of work completed per unit of time.

RTO: Recovery time objective; the maximum acceptable restoration time after disruption.

RPO: Recovery point objective; the maximum acceptable period of data changes that may be lost.

IaaS: Infrastructure as a Service, providing virtualised infrastructure primitives.

PaaS: Platform as a Service, providing a managed runtime or development platform.

SaaS: Software as a Service, providing a complete managed application.

Serverless: A model in which the provider abstracts server management and scales execution for the customer.

Portability: The ease of moving an application, data, or process between environments.

Total cost of ownership: The full cost of acquiring, operating, supporting, securing, and eventually replacing a solution.

Availability zone: An isolated provider location within a region, designed to reduce correlated failure.

Idempotency: The property that repeating an operation produces the same intended result without harmful duplication.

Observability: The ability to understand internal system behaviour from outputs such as metrics, logs, and traces.

Shared responsibility model: The allocation of security and operational duties between cloud provider and customer.

Review Questions

Short Answer Questions

1. What is the difference between scalability and elasticity?
2. Define RTO and RPO and explain why they influence architecture cost.
3. Why can a system have multiple application servers and still possess a single point of failure?
4. What responsibilities commonly remain with a customer when using PaaS?
5. Why are latency percentiles often more useful than average latency?

Long Answer Questions

1. Explain how business requirements can be translated into a measurable cloud workload profile.
2. Compare IaaS, PaaS, containers, serverless, and SaaS in terms of control, operational effort, and portability.
3. Discuss the relationship among scalability, elasticity, availability, and resilience.
4. Explain how total cost of ownership should be used when comparing two cloud architectures.
5. Describe the design and governance considerations for a multi-availability-zone web application.

Analytical / Application Questions

1. A service expects 1,200 requests per second at peak and uses a safety factor of 1.25. Each application instance sustains 300 requests per second under the required latency target. Estimate the minimum number of instances before adding failure headroom, and explain why the database must also be tested.
2. An organisation requires an RTO of 20 minutes and an RPO of 5 minutes for an order system. Propose a recovery approach and identify at least three assumptions that must be validated.
3. Compare a low-cost single-region design with a higher-cost multi-region design for a regulated financial application. Recommend a design and justify the decision using availability, recovery, compliance, portability, and total-cost criteria.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes elasticity from scalability?

A. Elasticity concerns security, while scalability concerns compliance.

B. Elasticity automatically adjusts resources with demand, while scalability is the ability to accommodate increased workload.

C. Elasticity applies only to databases, while scalability applies only to networks.

D. Elasticity measures uptime, while scalability measures downtime.

Correct Answer: B. Elasticity automatically adjusts resources with demand, while scalability is the ability to accommodate increased workload.

Question 2

A service is available for 99,900 minutes and unavailable for 100 minutes. What is its availability?

A. 90%

B. 99%

C. 99.9%

D. 99.99%

Correct Answer: C. 99.9%

Question 3

Which requirement is represented by an RPO of 15 minutes?

A. Service must be restored within 15 minutes.

B. The system may lose no more than 15 minutes of data changes after a failure.

C. The system must respond within 15 minutes.

D. The system must operate in 15 regions.

Correct Answer: B. The system may lose no more than 15 minutes of data changes after a failure.

Question 4

Which service model generally gives the customer the greatest control over the operating system?

A. Software as a Service

B. Function as a Service

C. Platform as a Service

D. Infrastructure as a Service

Correct Answer: D. Infrastructure as a Service

Question 5

A workload requires 800 requests per second and uses a safety factor of 1.25. What estimated capacity is required?

A. 640 requests per second

B. 800 requests per second

C. 1,000 requests per second

D. 1,250 requests per second

Correct Answer: C. 1,000 requests per second

Question 6

Which design feature most directly supports horizontal scaling of an application tier?

A. Keeping all user sessions only in local instance memory

B. Using stateless application instances behind a load balancer

C. Placing the application and database on one server

D. Disabling health checks

Correct Answer: B. Using stateless application instances behind a load balancer

Question 7

What is a principal limitation of a queue-based architecture?

A. It cannot absorb temporary bursts.

B. It eliminates the need for error handling.

C. It may introduce eventual consistency and duplicate-message handling requirements.

D. It prevents independent scaling of consumers.

Correct Answer: C. It may introduce eventual consistency and duplicate-message handling requirements.

Question 8

Which cost item is most likely to be missed when considering only a cloud provider’s compute invoice?

A. Operational labour and monitoring

B. The colour of the user interface

C. The number of business requirements

D. The application’s product name

Correct Answer: A. Operational labour and monitoring

Question 9

What does idempotency help prevent in a retried order request?

A. All network latency

B. Duplicate creation of the same order

C. All database backups

D. The need for authentication

Correct Answer: B. Duplicate creation of the same order

Question 10

Which statement about the shared responsibility model is most accurate?

A. The provider is always responsible for application code and customer data.

B. The customer has no security responsibility when using managed services.

C. Responsibilities vary by service model, but customers retain duties such as appropriate access control and configuration.

D. The model applies only to physical data-centre security.

Correct Answer: C. Responsibilities vary by service model, but customers retain duties such as appropriate access control and configuration.