5. Cloud Security Architecture and Shared Responsibility

Introduction and Context

Cloud computing has changed the location, ownership, and operation of information systems. Compute capacity, storage, databases, identity services, analytics platforms, and security functions can be provisioned through software and consumed as services. This elasticity improves scalability and reduces capital expenditure, but it also changes the security problem. An organisation no longer protects only equipment inside a controlled data centre. It must govern identities, configurations, application interfaces, data flows, software pipelines, provider relationships, and services that may span several jurisdictions and cloud platforms.

Cloud security architecture is the deliberate design of controls, trust boundaries, operating processes, and technical patterns that protect cloud-hosted workloads and information. It is not synonymous with purchasing a cloud security product. A secure architecture connects business requirements with identity, network, data, workload, application, monitoring, and governance controls. The architecture must also recognise that responsibility is divided between the cloud service provider and the customer. The precise division depends on the service model, deployment model, contractual terms, and configuration choices.

For postgraduate security professionals, the important question is not whether cloud computing is secure in the abstract. The relevant questions are: secure for whom, against which threats, under what operating assumptions, and with what evidence? These questions provide the foundation for evaluating IaaS, PaaS, and SaaS; designing landing zones and guardrails; isolating tenants; and applying guidance from the Cloud Security Alliance (CSA), NIST, and major cloud providers.

Learning Objectives

After studying this chapter, students should be able to:

1. Distinguish IaaS, PaaS, and SaaS responsibilities and risks.

2. Compare public, private, hybrid, and multi-cloud security architectures.

3. Explain the cloud shared responsibility model and identify common responsibility gaps.

4. Design the security characteristics of a cloud landing zone.

5. Apply identity, network, data, workload, logging, and governance guardrails.

6. Analyse tenant-isolation risks and cloud-native control strategies.

7. Use CSA, NIST, and provider architecture guidance in security decision-making.

8. Evaluate an organisational cloud-security scenario and recommend a defensible approach.

The Cloud Service Models and the Location of Risk

The service model determines which technical layers the provider operates and which remain under customer control. It therefore changes both the attack surface and the evidence required to demonstrate security.

Infrastructure as a Service

In IaaS, the provider supplies virtual machines, networks, storage, and related infrastructure. The customer normally controls the guest operating system, installed software, identities, network rules, data, and workload configuration. IaaS resembles a virtual data centre, but it is not identical to one: APIs, ephemeral resources, provider-managed control planes, and automated provisioning introduce additional dependencies.

IaaS offers substantial control and flexibility, but misconfiguration is a dominant risk. Examples include publicly exposed storage, permissive security groups, unpatched images, excessive administrative privileges, disabled logging, and credentials embedded in code. The customer must also understand the limits of virtual isolation and the consequences of placing sensitive workloads in shared physical infrastructure.

Platform as a Service

PaaS abstracts operating systems and much of the runtime environment. The customer deploys application code and manages application configuration, identities, data, and access policies, while the provider manages the platform. PaaS can reduce patching and infrastructure-management burdens, but it does not eliminate security responsibility. Vulnerable application logic, insecure APIs, excessive database permissions, weak secrets management, and inadequate tenant controls remain customer concerns.

PaaS security requires careful attention to platform-specific defaults and dependencies. A database service may be highly resilient yet still expose data through an incorrectly configured endpoint. A serverless function may have no traditional server to patch, but its execution role can still permit destructive access to storage or administrative APIs.

Software as a Service

In SaaS, the provider operates nearly the entire application stack. The customer generally manages users, access, data classification, configuration, endpoint security, and integration choices. SaaS reduces infrastructure-management responsibilities but increases dependence on provider assurance, contractual commitments, application configuration, and export or recovery capabilities.

A common misconception is that SaaS transfers all security responsibility to the provider. In practice, customers remain responsible for choosing appropriate sharing settings, enforcing strong authentication, reviewing privileged roles, controlling third-party integrations, retaining records, and responding to compromised accounts. SaaS risk is often concentrated in identity compromise and data governance rather than operating-system vulnerabilities.

Responsibility as a Continuum

The service models should not be treated as rigid categories. Managed databases, container platforms, hosted Kubernetes, identity services, and event-processing platforms distribute responsibility in different ways. A useful method is to create a responsibility matrix for each service, identifying who controls and who provides evidence for:

• physical facilities and hardware;
• hypervisors, managed operating systems, and platform components;
• network exposure and segmentation;
• application code and dependencies;
• identities, keys, configurations, and data;
• vulnerability management, logging, backup, and incident response.

The matrix should be validated against provider documentation and the organisation’s contract, because marketing descriptions do not establish operational accountability.

Deployment Models and Their Security Trade-offs

A public cloud is operated by a provider and offers shared services to many customers. Its advantages include mature infrastructure, rapid scaling, and extensive security capabilities. Its risks include dependence on provider control planes, exposure through internet-accessible management interfaces, concentration risk, and the possibility of configuration errors across large environments.

A private cloud is dedicated to one organisation, although it may be operated internally or by a third party. It can support specialised control, data-residency, or isolation requirements, but it does not automatically provide better security. The organisation may have fewer resources for patching, resilience, detection engineering, and specialist operations than a major provider.

Hybrid cloud combines private and public environments. It can support gradual migration, regulatory separation, or proximity to legacy systems. However, hybrid architectures create trust boundaries between environments. Connectivity, identity federation, data replication, and inconsistent policy enforcement become important attack paths. A secure hybrid design makes data flows explicit rather than assuming that a private segment is inherently trusted.

Multi-cloud uses services from two or more cloud providers. It may reduce dependence on one provider, support specialised capabilities, or improve resilience. It also introduces multiple identity models, logging formats, network constructs, security tools, contractual relationships, and skill requirements. Multi-cloud is therefore not automatically more resilient: if the same identity provider, software pipeline, DNS service, or data dependency fails, the apparent diversity may be misleading.

The appropriate deployment model is a risk and business decision. Security architecture should evaluate confidentiality, integrity, availability, sovereignty, portability, operational capability, recovery objectives, and the consequences of provider or regional failure.

The Shared Responsibility Model

The shared responsibility model describes the division of security duties between provider and customer. Providers generally secure the cloud infrastructure: facilities, physical hardware, core networking, and the underlying service platform. Customers secure what they place in or configure on that platform. The boundary moves upward as services become more managed.

This model has two important implications. First, responsibility is shared, but accountability cannot simply be shared away. The organisation remains accountable to customers, regulators, boards, and business owners for the protection and lawful use of its information. Second, the customer’s responsibility includes configuration. A provider may supply encryption, logging, private endpoints, or multifactor authentication, but the customer may need to enable, configure, monitor, and use those capabilities correctly.

Responsibility gaps commonly arise when:

• ownership of a control is assumed rather than documented;
• teams use default settings without risk assessment;
• security teams cannot see provider control-plane activity;
• a service is adopted before its backup and recovery model is understood;
• an application team assumes that a managed service validates application-level security;
• evidence is not collected for audits or incident investigations.

A mature organisation maintains a service-specific responsibility matrix, assigns control owners, tests important controls, and incorporates cloud obligations into procurement, architecture review, and operational procedures.

Architecture Principles for a Secure Cloud Foundation

Landing Zones as Controlled Starting Environments

A landing zone is a predesigned cloud environment in which accounts or subscriptions, identity, networking, logging, security services, and governance are established before application teams deploy workloads. It should be treated as an operating model as well as a technical configuration.

A well-designed landing zone normally separates administrative, security, networking, shared-services, development, testing, and production contexts. Separation can be implemented through accounts, subscriptions, projects, resource groups, or comparable provider constructs. The aim is to reduce blast radius, simplify ownership, and prevent a compromise in a low-trust environment from becoming an enterprise-wide incident.

Central services should include an authoritative identity source, centralised audit logging, security monitoring, approved network connectivity, key-management functions, and policy enforcement. Application teams should retain sufficient autonomy to deliver services, but autonomy must operate within non-negotiable security boundaries.

Identity as the Primary Control Plane

Cloud management is API-driven, so identity is often the most important security boundary. Security architecture should apply federation, phishing-resistant multifactor authentication for privileged access where feasible, short-lived credentials, role-based access control, and just-in-time elevation. Human administrators should not routinely use permanent access keys or shared accounts.

Workload identities are equally important. Applications should obtain narrowly scoped permissions through managed identities, service accounts, or federated workload credentials rather than embedded secrets. Privilege should be granted to a specific resource and action set, with separation between deployment, runtime, security, and audit roles.

Access decisions should consider more than a user’s role. Device condition, network context, authentication strength, resource sensitivity, and session risk can support a zero-trust approach. Access should be continuously evaluated, logged, and periodically reviewed.

Network Architecture and Segmentation

Cloud networks are software-defined and highly dynamic. Traditional perimeter assumptions are inadequate because workloads communicate through APIs, managed services, private endpoints, and temporary connections. A secure design uses layered segmentation: separate environments, isolate management paths, restrict east-west communication, and expose only necessary services through controlled ingress points.

Private connectivity can reduce exposure to the public internet, but it is not a substitute for authentication and authorisation. Egress controls are also important because compromised workloads may attempt data theft, command-and-control communication, or exploitation of external services. Network security groups, firewalls, web application firewalls, service-mesh policies, route controls, and DNS protections should be combined according to the workload’s trust requirements.

Data Protection and Key Management

Data security begins with classification. The organisation should identify sensitive, regulated, mission-critical, and publicly releasable information, then define storage, processing, sharing, retention, and deletion requirements. Encryption in transit and at rest is expected for sensitive data, but encryption alone does not prevent an authorised but compromised identity from reading data.

Customer-managed keys may provide stronger control over use, rotation, separation of duties, and revocation, but they create operational obligations. Loss of key access can make data unavailable. Key policies should therefore be tightly controlled, monitored, backed up according to the provider’s design, and tested through recovery exercises. Tokenisation, masking, confidential computing, data-loss prevention, and access analytics may be appropriate for higher-risk workloads.

Secure Workloads and Delivery Pipelines

Cloud security begins before deployment. Infrastructure as code enables version control, peer review, repeatability, and automated policy checks. Image and dependency scanning, secret detection, software composition analysis, signed artifacts, and protected build pipelines reduce the probability that vulnerable or tampered components reach production.

Runtime protection should include vulnerability management, endpoint or workload telemetry where appropriate, container and orchestration controls, application logging, and rapid replacement of compromised instances. Immutable or declarative deployment patterns can reduce configuration drift, but only when the deployment pipeline itself is strongly protected.

Logging, Detection, and Recovery

A landing zone should centralise control-plane, identity, network, application, and data-access logs in a protected account or service. Logs require integrity protection, time synchronisation, retention rules, access restrictions, and monitoring. Merely storing logs does not create detection capability; use cases, alerts, triage procedures, and response ownership are required.

Cloud recovery planning must address more than backup frequency. It should identify provider-region dependencies, account compromise, ransomware, accidental deletion, key loss, and failure of automation. Backups should be logically separated, protected from unauthorised deletion, periodically restored, and measured against recovery time and recovery point objectives.

Guardrails and Policy-Based Governance

Guardrails are constraints that prevent or detect unacceptable activity while allowing approved delivery. Preventive guardrails may deny creation of resources in prohibited regions, block public storage, require encryption, restrict the use of unapproved images, or prevent disabling of audit logs. Detective guardrails may identify drift, excessive privileges, exposed services, anomalous access, and missing tags.

Effective guardrails are risk-based and proportionate. Excessive restrictions can encourage shadow IT or unsafe workarounds. Policies should be expressed as code where possible, tested in non-production environments, versioned, and associated with an exception process. Exceptions should have a business justification, an owner, an expiry date, compensating controls, and review evidence.

Security architecture should distinguish between policy, standard, and implementation. A policy may require protection of regulated information; a standard may require encryption and monitored access; an implementation may specify a provider-native key, logging, or policy service. This separation supports portability while allowing provider-specific enforcement.

Tenant Isolation and Cloud-Native Controls

Multi-tenancy means that customers share some provider resources while remaining logically separated. Isolation may exist at the account, virtual network, hypervisor, container, database-schema, or application level. The security strength of one layer should not be assumed to compensate for weaknesses in another.

Customers should understand whether a service provides dedicated tenancy, logical isolation, customer-managed encryption, network isolation, or provider-controlled physical separation. High-risk workloads may require dedicated hosts, isolated accounts, separate keys, or additional contractual commitments. Application-level tenant isolation is the customer’s responsibility in many SaaS and PaaS designs: authorisation checks must ensure that one tenant cannot query, modify, or infer another tenant’s data.

Cloud-native controls include identity and access management, policy engines, security posture management, cloud workload protection, cloud access security brokers, API gateways, service meshes, secrets managers, key-management services, security information and event management, and automated remediation. These controls are valuable only when integrated with architecture and operating processes. Automation that deletes resources or changes access policies without adequate validation can itself create an outage.

Guidance from CSA, NIST, and Cloud Providers

The CSA Cloud Controls Matrix provides a cloud-oriented catalogue of control domains and helps organisations map responsibilities, assurance needs, and provider capabilities. It is useful for procurement, control assessment, and identifying gaps across governance, infrastructure, application, and data concerns.

NIST guidance contributes complementary perspectives. NIST’s definition and architectural work clarify cloud characteristics and service models; its cybersecurity and risk-management approaches support governance, identification, protection, detection, response, and recovery; and its zero-trust guidance helps replace implicit network trust with policy-driven access. NIST publications should be adapted to organisational risk rather than applied as a checklist detached from business context.

Provider architecture frameworks translate general principles into provider-specific constructs such as account hierarchies, management groups, projects, identity roles, private connectivity, policy services, monitoring, and resilience patterns. These frameworks are valuable implementation references, but they are not substitutes for independent risk analysis. A provider’s “secure by design” recommendation may still require customer configuration, and provider-native controls may create portability or skills dependencies.

A practical method is to map business requirements to CSA and NIST outcomes, then map those outcomes to provider services and operating procedures. The resulting architecture should document assumptions, residual risks, control owners, evidence sources, and testing frequency.

Applied Case: A Regulated Retailer Moves to the Cloud

Background

Northstar Retail, an illustrative regional retailer, operates an online store, warehouse systems, and a loyalty programme. It plans to move customer-facing applications to a public cloud while retaining some warehouse workloads in a private data centre. Loyalty data includes personal information and transaction histories. The organisation has a small security team and separate development groups for commerce and analytics.

Situation and Problem

The initial proposal placed development and production resources in one cloud account, used long-lived administrator keys for deployment, allowed direct internet access to databases, and relied on each team to configure logging. The business expected rapid migration, but the security review identified excessive blast radius, uncertain data residency, weak credential management, and no tested cloud recovery process.

Analysis

The risks were not caused by the public-cloud model alone. They resulted from an unsuitable operating design. A compromised developer credential could reach production. Internet exposure increased the attack surface. Uncentralised logs would delay detection and make investigation difficult. The hybrid connection to warehouse systems also created a route through which a cloud compromise could affect legacy operations.

Strategy and Solution

The security architect proposed a landing zone with separate production, non-production, security, networking, and shared-services accounts. Identity was federated with the corporate directory, privileged access required multifactor authentication and time-limited elevation, and deployment used short-lived workload credentials. Production databases were placed on private networks and accessed through controlled application services.

Central logging was enabled for identity, control-plane, network, and data-access events, with copies protected from alteration. Policies blocked public storage, prohibited unapproved regions, required resource tags, and detected excessive permissions. Infrastructure was deployed through reviewed code, with scanning for secrets and vulnerable dependencies. The hybrid connection was restricted to explicit warehouse application flows, and recovery exercises tested restoration of both cloud and on-premises dependencies.

The retailer used the CSA controls as a coverage checklist, NIST risk-management concepts to prioritise controls, and the provider’s architecture guidance to implement account separation, policy enforcement, private connectivity, and monitoring. A data-governance committee approved retention and key-management rules, while application owners remained accountable for tenant and business-logic authorisation.

Outcome

The design reduced the impact of a single compromised account, improved evidence availability, and made security requirements repeatable across new workloads. Migration took longer than the original infrastructure-only plan, but the organisation gained clearer ownership and more reliable deployment. Residual risks remained, including provider dependency, application vulnerabilities, and the possibility of misuse by privileged insiders.

Learning Points

The case illustrates that a landing zone is a security and governance foundation, not merely an account-creation exercise. It also demonstrates that cloud-native controls must be combined with application responsibility, identity discipline, recovery testing, and executive ownership.

Challenges, Limitations, and Common Mistakes

Cloud security programmes frequently fail through ordinary operational weaknesses. Common mistakes include treating compliance certification as proof of secure customer configuration, granting broad administrative privileges for convenience, neglecting egress control, assuming private networking eliminates application risk, and deploying security tools without staffing their alerts.

Other difficulties include provider service complexity, rapidly changing interfaces, inconsistent terminology across clouds, limited portability of controls, unclear incident-response authority, and inadequate skills in identity, automation, and cloud forensics. Security teams may also create controls that are technically sound but unusable, causing developers to bypass approved processes.

A further limitation is concentration risk. Dependence on a provider, identity federation service, software repository, or managed security platform can create common-mode failure. Multi-cloud can reduce some dependencies but may increase complexity and create inconsistent protection. Architectural decisions should therefore be evaluated using failure scenarios rather than assumed benefits.

Governance, Regulation, and Professional Responsibility

Cloud governance must connect technical controls with legal, contractual, and ethical obligations. Data residency, cross-border transfer, breach notification, records retention, sector regulation, accessibility, and lawful access requirements may influence provider and region selection. Contracts should address security responsibilities, audit rights, subcontractors, incident notification, data return and deletion, service availability, and evidence provision.

Security professionals must avoid overstating assurance. A provider’s certification applies to a defined scope and does not validate every customer workload. Risk acceptance should be explicit, informed, time-bound, and approved by an accountable authority. Privacy principles such as purpose limitation, minimisation, access control, and retention should be built into architecture rather than added after deployment.

Automation and analytics raise additional concerns. Behavioural detection can identify anomalous access, but it may produce false positives or expose sensitive employee information. Automated remediation should be governed, tested, reversible where possible, and subject to human oversight for high-impact actions.

Emerging Directions and Best Practices

Cloud security is moving toward continuous control validation, identity-centric detection, policy as code, software supply-chain assurance, confidential computing, and more automated evidence collection. Artificial intelligence is increasingly used to summarise alerts, identify configuration relationships, and support investigation. These capabilities can improve scale, but they do not remove the need for reliable data, expert judgement, and accountable decisions.

A durable cloud-security programme should:

• establish a documented, service-specific responsibility matrix;
• build a governed landing zone before large-scale migration;
• make strong identity, least privilege, and short-lived credentials standard;
• separate environments and protect central security services;
• classify data and design keys, retention, backup, and recovery accordingly;
• use infrastructure as code with security testing in delivery pipelines;
• centralise, protect, and actively analyse security-relevant logs;
• implement preventive and detective guardrails with controlled exceptions;
• test tenant isolation, incident response, and disaster recovery;
• review provider, regional, identity, and supply-chain dependencies;
• measure outcomes such as remediation time, privileged-access exposure, logging coverage, policy compliance, and recovery performance.

Chapter Summary

Cloud security architecture is the design of technical controls, trust boundaries, governance, and operating practices for cloud-based services. IaaS provides control but leaves substantial responsibility with the customer; PaaS reduces infrastructure duties but retains application, identity, data, and configuration risks; SaaS shifts infrastructure operation to the provider while leaving customers responsible for users, data, integrations, and settings. Public, private, hybrid, and multi-cloud models involve different trade-offs rather than universally superior security.

The shared responsibility model must be made concrete through service-specific responsibility matrices and evidence requirements. Secure landing zones establish account or subscription separation, central identity, network controls, logging, policy enforcement, key management, and recovery foundations. Guardrails prevent or detect unsafe activity, while tenant isolation requires attention to provider and application-level boundaries. CSA, NIST, and provider architecture guidance can be combined to translate risk into controls, but none eliminates the need for governance, testing, and professional judgement.

Key Terms

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

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

PaaS: A service model in which the provider manages the platform while the customer manages applications, data, and configuration.

SaaS: A provider-operated application service consumed by customers over a network.

Landing zone: A governed foundational cloud environment prepared for secure workload deployment.

Guardrail: A preventive or detective policy constraint that limits unsafe cloud activity.

Tenant isolation: Logical or physical separation preventing one customer or application tenant from accessing another’s resources.

Cloud control plane: Provider APIs and management services used to create and administer cloud resources.

Infrastructure as code: Machine-readable definitions used to provision and manage infrastructure consistently.

Workload identity: A non-human identity used by an application, service, or automated process.

Least privilege: Granting only the access necessary for an authorised task.

Policy as code: Encoding governance and security rules in machine-evaluable form.

Cloud egress: Traffic leaving a cloud environment toward external networks or services.

Private endpoint: A mechanism enabling access to a managed service through private network paths.

Configuration drift: Unintended divergence between approved architecture and deployed settings.

Cloud posture management: Continuous assessment of cloud configurations against security requirements.

Control plane logging: Records of administrative and management actions performed through cloud APIs.

Customer-managed key: An encryption key whose lifecycle and access policies are controlled by the customer.

Zero trust: A security approach that does not grant implicit trust based solely on network location.

Residual risk: Risk remaining after security controls have been implemented.

Review Questions

Short Answer Questions

1. How does the customer’s responsibility differ between IaaS and SaaS?

2. What is the purpose of a cloud landing zone?

3. Why is identity often considered the primary cloud control plane?

4. Define a guardrail and distinguish preventive from detective guardrails.

5. What is configuration drift, and why is it dangerous?

Long Answer Questions

1. Explain the shared responsibility model and analyse why it must be documented for each cloud service.

2. Compare the security trade-offs of public, private, hybrid, and multi-cloud deployments.

3. Describe the major architectural components of a secure cloud landing zone.

4. Discuss how CSA, NIST, and provider architecture guidance can be used together.

5. Explain how identity, network, data, workload, logging, and recovery controls reinforce one another.

Analytical / Application Questions

1. An organisation stores regulated data in a SaaS platform and permits users to create external sharing links. Identify the main responsibility gaps and propose controls.

2. A multi-cloud enterprise has centralised identity but separate logging systems and inconsistent privileged-access policies. Analyse the risks and recommend a governance approach.

3. A development account can access production storage because both environments share a broad administrative role. Design a revised landing-zone and identity architecture, including guardrails and monitoring.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes customer responsibility in a typical IaaS arrangement?

A. The customer is responsible only for physical data-centre security.

B. The customer manages guest operating systems, configurations, identities, and data.

C. The provider is responsible for application code and customer access decisions.

D. The customer has no responsibility once virtual machines are provisioned.

Correct Answer: B. The customer manages guest operating systems, configurations, identities, and data.

Question 2

What is the primary purpose of separating production and development accounts or subscriptions in a landing zone?

A. To eliminate the need for identity controls

B. To increase the number of internet-facing services

C. To reduce blast radius and establish clearer administrative boundaries

D. To ensure all workloads use identical configurations

Correct Answer: C. To reduce blast radius and establish clearer administrative boundaries

Question 3

Which control most directly reduces the risk created by permanent administrator access keys?

A. Increasing storage capacity

B. Using short-lived federated credentials and just-in-time elevation

C. Disabling audit logging

D. Allowing shared administrator accounts

Correct Answer: B. Using short-lived federated credentials and just-in-time elevation

Question 4

Why does private network connectivity not by itself guarantee secure access to a managed database?

A. Private networks cannot carry encrypted traffic

B. Authentication and authorisation are still required

C. Private connectivity automatically grants public access

D. Managed databases cannot be monitored

Correct Answer: B. Authentication and authorisation are still required

Question 5

Which is an example of a preventive guardrail?

A. An alert reporting an exposed storage bucket

B. A report showing excessive privileges after deployment

C. A policy denying deployment in an unauthorised region

D. A dashboard displaying historical incidents

Correct Answer: C. A policy denying deployment in an unauthorised region

Question 6

In a SaaS environment, which responsibility generally remains with the customer?

A. Maintaining the provider’s physical servers

B. Patching the provider’s hypervisor

C. Configuring user access, sharing settings, and data governance

D. Replacing failed provider networking hardware

Correct Answer: C. Configuring user access, sharing settings, and data governance

Question 7

What is a significant security concern in multi-cloud environments?

A. The complete disappearance of configuration complexity

B. Uniform identity and logging controls without additional effort

C. Inconsistent policies, tools, identities, and evidence across providers

D. The impossibility of using encryption

Correct Answer: C. Inconsistent policies, tools, identities, and evidence across providers

Question 8

Which practice best supports reliable and repeatable cloud deployment?

A. Manual configuration by an administrator without review

B. Infrastructure as code with version control and automated security checks

C. Disabling change records to accelerate delivery

D. Embedding permanent secrets in deployment scripts

Correct Answer: B. Infrastructure as code with version control and automated security checks

Question 9

Why should cloud logs be copied to a protected central security service or account?

A. To make logs easier for attackers to modify

B. To reduce the need for incident response

C. To improve integrity, central analysis, and investigation after account compromise

D. To prevent all application errors

Correct Answer: C. To improve integrity, central analysis, and investigation after account compromise

Question 10

Which conclusion is most consistent with the chapter’s discussion of provider certifications?

A. Certification automatically proves that every customer workload is secure.

B. Certification removes the need for customer configuration reviews.

C. Certification provides assurance only within a defined scope and does not remove customer duties.

D. Certification makes contractual security terms unnecessary.

Correct Answer: C. Certification provides assurance only within a defined scope and does not remove customer duties.