1. Cloud Security Foundations and Responsibility Models

Introduction and Context

Cloud computing has changed the way organizations acquire, operate, and secure information technology. Instead of purchasing and maintaining all computing equipment within an organizational facility, a customer can obtain computing capacity, storage, databases, applications, and security services from a cloud provider through standardized interfaces and usage-based commercial arrangements. This shift creates substantial benefits: infrastructure can be provisioned rapidly, capacity can expand or contract, and specialized technology can become available without equivalent capital investment.

The security consequences of this shift are more complex than simply moving servers to another location. In traditional infrastructure, an organization generally owns or directly controls the physical facilities, networks, operating systems, and applications supporting its information assets. In cloud environments, these layers are distributed across a provider’s facilities, software-defined control systems, managed services, and contractual commitments. The customer retains responsibility for some controls, while the provider assumes responsibility for others. The precise boundary changes according to the service model, deployment model, technology used, and contractual arrangement.

Cloud security therefore requires two forms of understanding. The first is technical: how virtualization, software-defined networking, identity systems, storage platforms, and control planes operate. The second is organizational: who is accountable for a control, how evidence is obtained, how risk is accepted, and how obligations are divided between provider and customer. A failure to understand either dimension can result in misplaced trust, insecure configurations, or false assumptions about what a provider is protecting.

This chapter establishes the conceptual foundation for later study of cloud identity, data protection, workload security, monitoring, incident response, and compliance.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Define cloud computing and distinguish important cloud terminology.

2. Explain the principal service and deployment models.

3. Describe virtualization, software-defined infrastructure, and cloud control planes.

4. Analyze provider architecture, trust boundaries, and multitenancy.

5. Compare cloud security risks with those of traditional infrastructure.

6. Apply shared-responsibility principles to common cloud services.

7. Evaluate provider and customer accountability in practical situations.

8. Identify governance, ethical, regulatory, and professional issues in cloud adoption.

From Owned Infrastructure to Cloud Services

Traditional information infrastructure is usually organized around assets owned or directly administered by an organization. A data centre may contain physical servers, network switches, storage arrays, firewalls, backup systems, and environmental controls. Technical teams often control the operating systems, hypervisors, applications, and physical access arrangements. This model does not eliminate risk, but it makes the boundary of responsibility relatively visible.

Cloud computing separates the consumption of technology from the ownership of much of its underlying infrastructure. A generally accepted description of cloud computing emphasizes on-demand network access to a shared pool of configurable resources that can be rapidly provisioned and released with limited provider interaction. The important characteristics are not merely remote hosting or internet connectivity. They include resource pooling, measured usage, elasticity, broad network access, and self-service provisioning.

Several terms require careful distinction. A cloud provider owns or operates the platform and offers services. A cloud consumer, customer, or tenant uses those services. A cloud service is a capability delivered through a defined interface, such as virtual machines, object storage, an analytical database, or an identity service. A workload is an application, process, or collection of resources deployed to perform a business function. An account, subscription, project, or tenant is an administrative boundary used to organize resources, identities, billing, and policy.

Elasticity refers to the ability to increase or decrease resources in response to demand. Scalability is the capacity of a system to handle increased workload, either by adding resources or by using larger resources. Elasticity is especially important for security because changing infrastructure can alter attack surfaces, logging requirements, access paths, and configuration states. Automation can create hundreds of resources quickly, but it can also reproduce an insecure configuration at the same speed.

A region is a geographic area containing one or more provider facilities or availability zones. An availability zone is an isolated location designed to reduce the effect of certain infrastructure failures. These terms are provider-specific in implementation, but the underlying design idea is resilience through physical and logical separation. Geographic distribution may also support data residency, disaster recovery, and latency objectives; however, it can introduce legal and governance complexity when information crosses national borders.

Service Models: Where the Customer’s Control Begins and Ends

Service models describe the level of abstraction supplied by the provider. They are not merely commercial labels; they indicate which technical layers the customer can configure and which layers are managed by the provider.

Infrastructure as a Service

Infrastructure as a Service (IaaS) supplies fundamental computing resources such as virtual machines, virtual networks, block storage, and related infrastructure components. The provider normally manages physical facilities, servers, networking hardware, and the virtualization layer. The customer generally manages the guest operating system, installed software, applications, identities, data, and many network and security settings.

IaaS resembles traditional infrastructure in some respects because the customer still administers operating systems and applications. This familiarity can be misleading. The customer may have extensive logical control but no physical access to the host, hypervisor, or storage device. A vulnerability in a guest operating system remains a customer responsibility, while a defect in the provider’s hypervisor is ordinarily a provider responsibility.

Platform as a Service

Platform as a Service (PaaS) provides a managed environment for developing and running applications. The provider manages more of the operating system, runtime, middleware, patching, and infrastructure. The customer concentrates on application code, configuration, data, identities, and business logic.

PaaS can reduce the burden of operating systems and infrastructure, but it does not remove security responsibility. Insecure application programming interfaces, excessive privileges, exposed secrets, weak authorization logic, and improper data handling remain customer concerns. PaaS also requires careful attention to provider-specific features because portability, logging, and configuration options may differ from those in self-managed environments.

Software as a Service

Software as a Service (SaaS) delivers a complete application to the customer, usually through a web interface or application programming interface. The provider manages the application, runtime, operating system, infrastructure, and physical environment. The customer generally remains responsible for users, access permissions, data classification, configuration, integrations, and appropriate use.

SaaS security failures frequently arise from identity and configuration rather than from server patching. Examples include an administrator granting broad external sharing permissions, failing to enforce multifactor authentication, retaining departed users, or connecting an untrusted application through an API token. A provider can secure the application platform while the customer still exposes confidential information through an administrative decision.

Serverless and Managed Specialized Services

Serverless computing and managed database, messaging, analytics, and artificial-intelligence services move the customer further away from infrastructure administration. The provider manages the servers and much of the platform, while the customer manages functions, code, data, permissions, and service configuration. The label “serverless” does not mean that servers do not exist; it means that their operation is abstracted from the customer.

As abstraction increases, the customer’s responsibility shifts from host maintenance toward identity, data governance, secure development, dependency management, and configuration assurance. The responsibility model therefore changes with the service, not simply with the provider.

Deployment Models and Their Security Meaning

A public cloud is operated for broad use by multiple customers. Its principal security characteristic is provider-operated shared infrastructure with logically separated tenants. A private cloud is dedicated to one organization, although it may be operated by that organization or by a third party. A hybrid cloud combines private and public environments, often to support gradual migration, regulatory constraints, resilience, or specialized workloads. A community cloud is shared by organizations with common requirements, such as a sector or mission.

These models do not automatically determine security quality. A private cloud can be poorly governed, and a public cloud can have highly mature security controls. Deployment models influence control, isolation, cost, scalability, and governance, but risk depends on architecture and operation. Hybrid environments are especially challenging because identities, networks, monitoring systems, and data flows cross organizational and technical boundaries. An apparently secure private environment may be weakened by a poorly protected connection to a public service.

Multi-cloud refers to the use of services from more than one cloud provider. It may reduce dependence on a single provider or support specialized capabilities, but it also increases the number of identity systems, policy languages, logging formats, contractual relationships, and skills required. Multi-cloud is not automatically more resilient; poorly coordinated environments may multiply failure modes.

Virtualization and the Software-Defined Data Centre

Virtualization allows a physical computing resource to support multiple logical environments. A hypervisor allocates processor time, memory, storage, and network connectivity to virtual machines. Each virtual machine appears to have its own operating system and resources, although the underlying hardware is shared. Type 1 hypervisors run directly on hardware, while Type 2 hypervisors operate above a conventional host operating system. Large cloud providers generally use highly specialized, hardware-oriented virtualization architectures.

Virtualization provides abstraction, consolidation, rapid provisioning, snapshotting, migration, and flexible resource allocation. It also creates new security dependencies. The hypervisor becomes a high-value control point: compromise or misconfiguration could affect multiple guest environments. Isolation mechanisms, hardware support, secure management interfaces, monitoring, and controlled administrative access are therefore essential.

Containers provide process-level isolation rather than complete virtual-machine isolation. Containers share the host kernel, which makes them lightweight and fast but creates a different security model. A container escape, insecure image, excessive runtime privilege, or exposed orchestration interface can affect multiple workloads. Container orchestration platforms add further control layers, including clusters, nodes, namespaces, service accounts, admission policies, and deployment pipelines.

Cloud infrastructure is increasingly software-defined. Virtual networks, security groups, load balancers, storage volumes, and routing rules are represented as software objects and managed through APIs. Infrastructure as Code expresses these configurations in declarative files that can be reviewed, tested, versioned, and deployed automatically. This improves consistency and auditability when implemented properly, but a flawed template can create systemic exposure across many environments.

Provider Architecture and the Cloud Control Plane

A useful way to understand cloud security is to distinguish the data plane from the control plane. The data plane performs the customer’s workload activity: processing requests, storing objects, serving applications, and transmitting information. The control plane manages the data plane. It creates resources, assigns permissions, changes network rules, generates credentials, configures backups, and exposes administrative APIs.

The control plane is therefore a concentration of authority. A compromised or misused control-plane identity may create resources, disable logging, alter firewall policies, access data, or destroy workloads. Protecting the control plane requires strong authentication, least privilege, separation of duties, approval processes for sensitive actions, logging, anomaly detection, and carefully managed automation identities.

Provider architecture includes physical facilities, power and environmental systems, hardware, virtualization, storage platforms, network fabrics, management services, identity services, and support operations. Customers rarely see all of these layers directly. Instead, they receive provider documentation, security attestations, service-level commitments, audit reports, and configuration interfaces. This creates an assurance problem: the customer must make decisions about systems that cannot be physically inspected in the same way as an owned data centre.

A cloud provider may also operate multiple administrative planes. The customer-facing plane permits resource management; internal provider planes support hardware operations, capacity management, support, security monitoring, and maintenance. A professional assessment therefore asks not only whether a service has encryption or access control, but also who can administer the service, how privileged activity is supervised, what evidence is retained, and how incidents are communicated.

Trust Boundaries and Multitenancy

A trust boundary is a point at which assumptions about authority, identity, data handling, or technical isolation change. In cloud environments, boundaries may exist between a customer and provider, between customer accounts, between production and development, between regions, between a control plane and a workload, or between a provider service and a third-party integration.

Multitenancy means that resources or infrastructure are used by more than one customer. Tenants are expected to be isolated through identity controls, virtualization, access policies, storage authorization, network segmentation, and secure service design. Logical isolation is fundamental to public cloud operation, but it is not identical to physical exclusivity. Customers must understand the provider’s isolation mechanisms and the consequences of service-specific design choices.

Common multitenancy concerns include accidental cross-tenant data exposure, insecure direct object references, shared-resource side channels, improper deletion of residual data, and administrative mistakes. These risks are managed through provider engineering and customer configuration. A provider should design robust isolation, while a customer should avoid making data publicly accessible, should validate authorization logic, and should use appropriate encryption and classification controls.

Trust should not be treated as a single binary decision. It is better understood as a set of explicit assumptions supported by evidence. For example, a customer may trust the provider to protect physical facilities but not automatically trust every marketplace image, third-party integration, or customer administrator. Zero-trust principles reinforce this approach by requiring continuous verification of identities, devices, requests, and context rather than granting broad access because a resource is “inside” a cloud network.

The Shared-Responsibility Model

The shared-responsibility model states that cloud security is divided between provider and customer. The provider is generally responsible for security of the cloud: physical facilities, hardware, core networking, foundational virtualization, and the managed service platform. The customer is generally responsible for security in the cloud: data, identities, access decisions, workload configuration, application security, and compliance use of the service.

This statement is a useful starting point, not a complete risk assessment. Responsibilities vary by service. In IaaS, customers patch guest operating systems and secure applications. In PaaS, the provider manages more platform components, but the customer remains responsible for code, data, and authorization. In SaaS, the provider manages the application infrastructure, while the customer controls users, permissions, data governance, and configuration. Some responsibilities are shared, including vulnerability management, incident response, logging, encryption choices, business continuity, and regulatory compliance.

Accountability should be examined control by control. Consider backup. The provider may replicate storage and maintain infrastructure durability, but the customer may need to configure backup schedules, retention, immutability, recovery testing, and restoration permissions. Consider encryption. The provider may offer encryption at rest and in transit, but the customer may select keys, manage key access, classify information, and determine whether application-level encryption is necessary. Consider availability. The provider may maintain service infrastructure, but the customer must design resilient applications, deploy across failure domains where appropriate, and test recovery.

A responsibility matrix is an effective governance instrument. It lists controls such as identity management, physical security, patching, vulnerability scanning, logging, backup, incident response, data deletion, and regulatory reporting. For each control, the matrix identifies the responsible party, accountable executive, supporting parties, evidence required, and review frequency. It should be mapped to a specific service rather than applied generically to an entire provider.

Contracts and service agreements should address security commitments, audit rights, incident notification, data location, subcontractors, deletion, availability, recovery objectives, and exit assistance. A provider’s compliance certification is useful evidence, but it does not prove that a customer’s deployment is secure. Certifications generally demonstrate that specified controls and processes were assessed within a defined scope and period; they do not transfer customer accountability.

Comparing Cloud Risk with Traditional Infrastructure

Cloud adoption changes the distribution and character of risk rather than eliminating risk. Traditional infrastructure exposes an organization to physical theft, facility failure, hardware maintenance, local network attacks, outdated systems, insider misuse, and limited disaster-recovery capacity. Cloud environments may reduce some of these burdens because providers operate professionally managed facilities and large-scale resilience mechanisms.

At the same time, cloud environments introduce or intensify other risks. Internet-accessible management interfaces, automated provisioning, highly privileged APIs, rapid configuration changes, dependency on provider availability, opaque infrastructure, concentration of workloads, and complex supply chains can increase the impact of mistakes. A single permissive identity policy may expose many resources. A compromised automation pipeline may reproduce a vulnerability across every account.

The comparison should therefore be based on threats and controls rather than on the simplistic question of whether cloud is safer. Relevant questions include:

• Which assets and identities are exposed to networks or APIs?
• Which party can change security controls?
• How quickly can misconfigurations be detected and corrected?
• What evidence is available for investigation?
• How dependent is the organization on one provider or region?
• Can the organization recover if an account, provider, or integration fails?

Cloud security frequently benefits from centralized logging, policy automation, immutable infrastructure, managed detection services, and rapid scaling. These benefits are realized only when the organization designs for them. Cloud does not compensate for weak governance, excessive privileges, poor software development, or inadequate monitoring.

Applied Case: A Hybrid Migration of a Financial Services Workload

Background

A fictional regional financial institution, Meridian Credit Union, operates a customer-loan application in its own data centre. The institution plans to migrate the application front end and analytics components to a public cloud while retaining a regulated customer database in a private environment. The project is designed as a hybrid deployment.

Situation and Problem

The development team creates cloud resources rapidly through infrastructure templates. The application uses a managed database service and an object-storage service for documents. During a security review, auditors discover that a storage container is accessible through a broad policy, several administrator accounts do not use multifactor authentication, and the cloud activity logs are retained for only a short period. The project team argues that the provider is responsible for security because the provider owns the infrastructure.

Analysis

The provider is responsible for the physical cloud facilities, core service operation, and underlying platform. It is not responsible for deciding whether Meridian’s documents should be publicly accessible, whether administrators require multifactor authentication, or whether logs are retained long enough for investigation. The managed database reduces responsibility for operating-system patching, but Meridian remains responsible for database permissions, data classification, network exposure, credentials, and application authorization.

The hybrid architecture also creates a trust boundary between the public cloud and private database. Network connectivity alone does not establish trust. Requests must be authenticated and authorized, data flows must be monitored, and the connection must be resilient and restricted to necessary services. The infrastructure templates represent another boundary: a defect in the template could reproduce insecure storage or network policies.

Approach and Strategy

Meridian establishes a service-specific responsibility matrix. It classifies loan documents, prohibits public access by default, requires multifactor authentication for privileged accounts, and uses separate administrative roles for deployment, security review, and production approval. It centralizes control-plane logs in a protected account with longer retention and alerting for changes to storage policies, identities, network routes, and logging configuration.

The institution introduces policy-as-code checks into the deployment pipeline. Templates are tested for encryption, private endpoints, approved regions, restricted security groups, and mandatory tags. The hybrid connection is limited to required application services, and database access is mediated through service identities rather than shared credentials. Recovery procedures are tested, including the possibility that the cloud account or connection becomes unavailable.

Outcome

The migration proceeds with clearer accountability and stronger evidence for audit and incident response. The provider continues to manage the underlying platform, but Meridian accepts responsibility for its configuration, identities, data, and application. The project also identifies a residual risk: dependence on the provider’s managed database and identity services. That risk is documented, monitored, and addressed through contractual review and recovery planning rather than being incorrectly described as eliminated.

Learning Points

The case demonstrates that a cloud provider’s infrastructure security does not secure a customer’s deployment automatically. Hybrid systems create additional trust boundaries, and control-plane protection is as important as workload protection. Automation improves security when templates and policies are tested; otherwise, it scales error. Finally, accountability must be expressed in operational controls and evidence, not merely in general statements about shared responsibility.

Governance, Ethics, and Professional Accountability

Cloud security decisions affect privacy, safety, organizational continuity, and public trust. Data should be classified before selecting services and locations. Legal requirements may govern personal information, financial records, health information, intellectual property, retention, access by foreign authorities, and cross-border transfers. Compliance remains the organization’s obligation even when processing is outsourced.

Ethical practice requires transparency about data use, proportionality of monitoring, protection of vulnerable individuals, and responsible management of access. Security teams should avoid collecting excessive telemetry without a legitimate purpose and should protect logs because they may contain personal or commercially sensitive information. Provider personnel and customer administrators should receive only the access necessary for their roles, and privileged activity should be reviewable.

Vendor governance should include due diligence, subcontractor visibility, breach notification procedures, service termination, data portability, and secure deletion. Organizations should avoid treating a provider’s marketing claim as evidence of a control. Evidence should be obtained from contractual documents, independent assessments, technical tests, configuration reviews, and operational records.

Current Developments and Emerging Directions

Cloud security is moving toward identity-centric and policy-driven operation. Security teams increasingly use centralized identity federation, short-lived credentials, continuous posture assessment, software bills of materials, confidential-computing technologies, and automated policy enforcement. Confidential computing seeks to protect data while it is being processed through hardware-supported trusted execution environments, although deployment complexity and assurance limitations remain.

Cloud-native application development is also integrating security into development and operations. Infrastructure as Code, policy-as-code, automated dependency analysis, container scanning, and continuous monitoring can reduce configuration drift and shorten remediation time. Artificial intelligence may assist with anomaly detection, cloud-configuration analysis, and investigation, but automated recommendations require human validation. AI systems can produce false positives, misunderstand context, expose sensitive telemetry, or become targets themselves.

The growth of edge computing, managed artificial-intelligence platforms, and increasingly specialized services will continue to blur the boundary between infrastructure and application security. Professionals therefore need both technical literacy and governance discipline. The central question remains unchanged: which party controls each decision, what evidence demonstrates that the control operates, and what happens when the control fails?

Best Practices for Cloud Responsibility Management

Organizations adopting cloud services should begin with an inventory of accounts, services, data, identities, and external connections. Each workload should have an owner, classification, recovery objective, approved deployment location, and documented responsibility matrix. Secure defaults should include least privilege, multifactor authentication, encryption appropriate to the data, private access where feasible, centralized logging, and continuous configuration assessment.

Security architecture should separate production, development, and administrative environments. Privileged identities should be distinct from ordinary user identities and should use time-limited access where possible. Infrastructure templates should be version-controlled, peer-reviewed, tested, and scanned before deployment. Logs should be protected from unauthorized alteration and sent to a separate security boundary. Backups should be isolated, access-controlled, and regularly restored in testing.

Finally, organizations should conduct provider and customer exercises. These may include incident-response simulations, key-compromise scenarios, region failure tests, accidental public-exposure drills, and service-exit assessments. The goal is not to assume that failure will not occur, but to make responsibility, evidence, and recovery explicit before a crisis.

Chapter Summary

Cloud computing delivers shared, elastic, and programmable technology services, but it changes rather than removes security responsibility. IaaS gives customers substantial control over operating systems and applications; PaaS abstracts much of the platform; SaaS abstracts the application infrastructure while leaving customers responsible for users, data, and configuration. Public, private, hybrid, community, and multi-cloud deployments create different control and governance conditions.

Virtualization and software-defined infrastructure enable rapid provisioning and resource pooling, while control planes concentrate administrative authority. Trust boundaries occur wherever identity, authority, data handling, or isolation assumptions change. Multitenancy depends on strong provider isolation and careful customer configuration. The shared-responsibility model must be applied to specific services and controls, supported by responsibility matrices, contracts, evidence, and testing.

Cloud environments may improve resilience, automation, and visibility, but they also amplify the consequences of identity compromise, configuration error, automation defects, and provider dependence. Effective cloud security combines technical safeguards with governance, ethical judgment, regulatory awareness, and continuous verification.

Key Terms

Cloud computing: On-demand delivery of configurable computing resources through a network with rapid provisioning and measured use.

Cloud provider: An organization that operates cloud infrastructure and delivers cloud services.

Cloud consumer: An organization or individual that uses services supplied by a cloud provider.

IaaS: A service model providing virtualized computing, networking, and storage resources while leaving substantial system administration to the customer.

PaaS: A service model providing a managed application platform in which the provider operates much of the infrastructure and runtime.

SaaS: A service model delivering a complete provider-managed application to customers.

Public cloud: Cloud infrastructure offered for use by multiple customers through a provider-operated environment.

Private cloud: Cloud infrastructure dedicated to one organization.

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

Multitenancy: The use of shared infrastructure or services by multiple customers with logical separation between them.

Virtual machine: A software-defined computing environment that runs an operating system through a hypervisor.

Hypervisor: Software or firmware that creates and manages virtual machines.

Container: An isolated application execution environment that generally shares the host operating-system kernel.

Control plane: The set of management interfaces and services used to create, configure, authorize, and monitor resources.

Data plane: The part of a system that performs workload processing, communication, and data operations.

Trust boundary: A point where assumptions about authority, identity, isolation, or data handling change.

Elasticity: The ability to dynamically increase or decrease resources in response to demand.

Infrastructure as Code: The definition and deployment of infrastructure through version-controlled machine-readable descriptions.

Shared responsibility: The division of security duties between a cloud provider and its customer.

Configuration drift: The gradual divergence of deployed resources from approved or intended settings.

Review Questions

Short Answer Questions

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

2. What security responsibilities normally remain with a customer using SaaS?

3. Define the control plane and explain why it is security-critical.

4. What is multitenancy, and which security property must it preserve?

5. Why does a provider compliance certification not automatically prove that a customer deployment is secure?

Long Answer Questions

1. Compare IaaS, PaaS, and SaaS in terms of customer control and security responsibility.

2. Explain how virtualization and software-defined infrastructure influence cloud security.

3. Discuss the significance of trust boundaries in hybrid and multi-cloud environments.

4. Compare the principal security risks of cloud infrastructure with those of traditional data-centre infrastructure.

5. Explain how an organization should construct and use a service-specific shared-responsibility matrix.

Analytical / Application Questions

1. An organization uses a managed database, object storage, and virtual machines for a confidential application. Identify the likely provider and customer responsibilities for patching, access control, encryption, backup, and monitoring.

2. A cloud administrator disables centralized logging while troubleshooting a production problem. Analyze the control-plane risks and propose governance and technical safeguards.

3. A company argues that moving a regulated workload to a private cloud eliminates compliance risk. Evaluate this claim using deployment models, accountability, data governance, and operational controls.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the customer’s responsibility in a typical SaaS arrangement?

A. Maintaining the provider’s physical servers

B. Patching the provider’s hypervisor

C. Managing users, permissions, data, and service configuration

D. Replacing failed storage hardware

Correct Answer: C. Managing users, permissions, data, and service configuration

Question 2

Why is the cloud control plane a high-value security target?

A. It stores all customer data in plaintext

B. It can create resources, change permissions, and modify security controls

C. It operates independently of identity systems

D. It is used only for physical facility maintenance

Correct Answer: B. It can create resources, change permissions, and modify security controls

Question 3

A customer runs virtual machines in an IaaS environment. Which task is normally the customer’s responsibility?

A. Maintaining the provider’s physical access controls

B. Patching the guest operating systems

C. Repairing the provider’s network switches

D. Managing the hypervisor hardware

Correct Answer: B. Patching the guest operating systems

Question 4

Which situation best illustrates a trust boundary?

A. Two files stored in the same approved directory

B. A change from a private network to a public cloud service requiring new identity and authorization assumptions

C. A user reading a document already authorized for that user

D. A scheduled backup running within one trusted system

Correct Answer: B. A change from a private network to a public cloud service requiring new identity and authorization assumptions

Question 5

What is the principal security characteristic of multitenancy?

A. Every customer receives physically separate global infrastructure

B. Customers share infrastructure while relying on logical isolation

C. Customers do not require identity management

D. Provider administrators cannot access management systems

Correct Answer: B. Customers share infrastructure while relying on logical isolation

Question 6

An organization deploys an insecure network policy through Infrastructure as Code across 200 accounts. What does this demonstrate?

A. Automation always prevents configuration errors

B. Cloud services eliminate systemic risk

C. Automation can reproduce a security weakness at scale

D. The provider is solely responsible for customer templates

Correct Answer: C. Automation can reproduce a security weakness at scale

Question 7

Which statement most accurately compares public and private cloud security?

A. Private cloud is automatically secure because it has one tenant

B. Public cloud is automatically insecure because infrastructure is shared

C. Security depends on architecture and operation, not deployment label alone

D. Deployment model has no effect on governance or control

Correct Answer: C. Security depends on architecture and operation, not deployment label alone

Question 8

A provider replicates a customer’s storage, but the customer has not configured retention or restoration testing. Which conclusion is most appropriate?

A. The customer has no backup responsibility

B. Provider durability automatically guarantees business recovery

C. The provider may support durability, but the customer remains responsible for recovery configuration and testing

D. The application owner is responsible only for physical security

Correct Answer: C. The provider may support durability, but the customer remains responsible for recovery configuration and testing

Question 9

Which control most directly reduces the risk of a compromised privileged cloud account?

A. Public access to management interfaces

B. Multifactor authentication and least privilege

C. Long-lived shared administrator passwords

D. Disabling control-plane logging

Correct Answer: B. Multifactor authentication and least privilege

Question 10

Why should provider assurance reports be combined with customer configuration reviews?

A. Provider reports always contain customer-specific deployment evidence

B. Customer configuration cannot affect security in cloud environments

C. Provider reports cover defined provider controls but do not prove that the customer configured services securely

D. Configuration reviews replace all contractual controls

Correct Answer: C. Provider reports cover defined provider controls but do not prove that the customer configured services securely