10 Architecture Models and Their Security Implications · Security+

Exam objective 3.1: Compare and contrast security implications of different architecture models. This objective asks you to evaluate where and how systems run—public, private, hybrid, and community clouds; serverless platforms and multicloud strategies; infrastructure as code (IaC); operational technology (OT); traditional on-premises data centers; air-gapped networks; microservices; and logical versus physical segmentation—and to weigh each against a set of technical considerations (availability, resilience, proprietary versus open source, usability, responsibility, compute, power requirements, and ease of recovery) and business considerations (data sovereignty, data classification, cost, ownership, environmental requirements, scalability, and risk).

"Compare and contrast" is the key verb. You will rarely be asked to define "public cloud" in isolation. Instead, expect questions that describe an organization's constraints—a regulator requiring data to stay in-country, a factory that cannot tolerate downtime, a startup with no capital budget—and ask which architecture fits best, or which security consequence follows from a choice that was already made. Study each model alongside its trade-offs, and practice explaining why one model is better than another for a given situation.

Why Architecture Choices Matter

An architecture model is a decision about where computing happens, who operates each layer, and how components are connected and separated. That decision determines which controls you can deploy, who patches what, where logs come from, and how quickly you can recover. A control that is trivial in one model may be impossible in another: you can patch a server you own, but not a public cloud provider's hypervisor.

Architecture choices also shape the attack surface (see Chapter 7). Good architecture minimizes and isolates entry points; poor architecture multiplies them.

Cloud Computing Fundamentals

Cloud computing delivers on-demand computing resources—servers, storage, databases, networking, software—over a network, with rapid provisioning, elastic scaling, and metered (pay-as-you-go) billing. NIST SP 800-145 lists five essential characteristics: on-demand self-service, broad network access, resource pooling (multitenancy), rapid elasticity, and measured service.

Service Models

The objective lists deployment models, but cloud responsibility depends on the service model. Infrastructure as a Service (IaaS) provides virtual machines, storage, and networks; the customer manages everything from the operating system up. Platform as a Service (PaaS) provides a managed runtime; the customer deploys code and manages data. Software as a Service (SaaS) provides a complete application; the customer manages users, access settings, and data. Function as a Service (FaaS), the basis of serverless computing, is covered below.

The Shared Responsibility Model

The shared responsibility model divides security duties between the cloud service provider (CSP) and the customer. The provider is always responsible for the physical data centers, hardware, and the virtualization layer—"security of the cloud." The customer is always responsible for its data, its identities and access decisions, and how it configures the services it uses—"security in the cloud." The middle layers shift depending on the service model.

Layer On-premises IaaS PaaS SaaS
Data and classification Customer Customer Customer Customer
Identities and access Customer Customer Customer Customer
Application Customer Customer Customer Provider
Runtime and middleware Customer Customer Provider Provider
Operating system Customer Customer Provider Provider
Virtualization Customer Provider Provider Provider
Physical hardware and facility Customer Provider Provider Provider

A responsibility matrix (sometimes called a RACI or shared responsibility matrix) documents these duties in writing for a specific provider and contract. It is the place to resolve questions such as "who reviews the access logs?" or "who encrypts the backups?" before an incident, not during one.

Common trap

Moving to the cloud never transfers responsibility for your data or your access configuration. Most cloud breaches result from customer-side misconfiguration—publicly readable storage buckets, overly permissive identity policies, exposed management keys—not from failures of the provider's infrastructure. If a question asks who is responsible for a misconfigured storage bucket, the answer is the customer.

Cloud Deployment Models

A deployment model describes who owns and uses the cloud infrastructure. SY0-801 lists four: public, private, hybrid, and community.

Public Cloud

A public cloud is owned and operated by a third-party provider and offered to the general public over the internet. Many unrelated customers (tenants) share the same physical infrastructure, separated logically by the provider's virtualization and identity controls.

Security implications:

Multitenancy means your workloads share hardware with strangers. Isolation failures such as hypervisor escape are rare but high-impact.
The provider's scale gives you capabilities you could not afford alone: global redundancy, DDoS absorption, built-in encryption, and compliance certifications.
You give up physical control and visibility, relying instead on attestations such as SOC 2 reports and ISO 27001 certifications.
Management happens through internet-facing consoles and APIs, so identity becomes the perimeter. A stolen administrator credential or API key can expose the entire environment.

Private Cloud

A private cloud provides cloud capabilities—self-service, automation, elasticity—to a single organization. It can be hosted in the organization's own data center or by a third party on dedicated hardware.

Security implications: greater control over hardware, location, and configuration; no multitenancy with outside organizations; easier alignment with strict regulatory requirements. The costs are higher capital expense, the need for in-house expertise, and elasticity limited by the hardware the organization has purchased.

Hybrid Cloud

A hybrid cloud combines two or more deployment models—most commonly on-premises or private cloud with public cloud—connected so that data and applications can move between them. A typical pattern keeps sensitive databases on-premises while running customer-facing web tiers in a public cloud, or uses public cloud capacity to absorb seasonal peaks ("cloud bursting").

Security implications:

Complexity is the dominant risk. Two environments mean two sets of controls, logging formats, and identity systems, and the seams between them are where misconfigurations hide. Policies enforced on-premises must be replicated in the cloud.
Connectivity between environments (site-to-site VPNs or dedicated private links) becomes critical infrastructure, and identity federation is usually needed so users have one identity across both.

Community Cloud

A community cloud is shared by several organizations with common requirements—for example, government agencies, a group of hospitals, or universities in a research consortium. It may be managed by one of the members or by a third party.

Security implications: costs are shared, and the cloud can be built to the community's specific compliance requirements (for example, a government community cloud meeting a national security baseline). However, members must trust each other's security practices, agree on governance, and decide who owns and is responsible for shared data and incidents.

Model Tenants Control Cost profile Key security concern

Public Many unrelated customers

Lowest Operational expense, pay as you go

Misconfiguration, identity compromise, multitenancy

Private One organization Highest High capital expense

Cost, in-house expertise, limited elasticity
Hybrid One organization across
models

Mixed Mixed Complexity, inconsistent policy, interconnection

Communit

Several organizations with shared needs

Shared Shared among members

Governance, trust among members, ownership

Exam tip

Look for the clue words. "Shared by several organizations with similar compliance needs" points to community. "Dedicated to one organization" points to private. "Combines on-premises and public cloud" points to hybrid. "Available to anyone, resources shared among unrelated customers" points to public.

Serverless Computing

Serverless computing lets developers run code without provisioning or managing servers. In the FaaS form, a function is triggered by an event—an HTTP request, a file upload, a message on a queue—runs for seconds or minutes, and then disappears. The provider handles the operating system, scaling, and availability; the customer pays only for execution time. The term also covers fully managed back-end services such as serverless databases.

Security implications:

Reduced customer responsibility. There is no OS to patch and no server to harden, but code and dependencies—vulnerable libraries, injection flaws—remain the customer's responsibility.
Function permissions are critical. Each function runs with an identity (an execution role). Overly broad roles are a common flaw; a function that only reads one storage bucket should not be able to write to every bucket in the account. Apply least privilege per function.
Limited visibility. Traditional host agents (EDR, HIDS) cannot be installed. Monitoring depends on provider logging and application-level instrumentation.
Ephemerality hinders attacker persistence but also complicates forensics, since there is no disk to image.
Denial of wallet. Automatic scaling means an attacker who floods a function with requests may not cause an outage but can cause a large bill. Concurrency limits and budget alerts mitigate this.

Multicloud

Multicloud means using services from two or more public cloud providers. It differs from hybrid cloud, which mixes deployment types; multicloud mixes providers. An organization can be both—on-premises plus two public clouds is hybrid multicloud.

Figure 10.1: Hybrid cloud mixes deployment models, while multicloud mixes public cloud providers

Organizations adopt multicloud to avoid vendor lock-in, to use each provider's best services, to meet data residency requirements in regions where only certain providers operate, and to improve resilience against a single provider's outage (a theme revisited in Chapter 13).

Security implications:

Each provider has different identity models, policy languages, logging formats, and defaults. Skill gaps lead to misconfiguration.
Visibility is fragmented, so organizations use cloud security posture management (CSPM) tools and a central SIEM to normalize checks and logs across providers.
The attack surface grows: more consoles, more API keys, more administrator accounts to protect, and more inter-provider data flows to encrypt.

Note

Hybrid versus multicloud is a common source of confusion. Hybrid = different deployment models working together (for example, private plus public). Multicloud = multiple providers (for example, two different public clouds). The two are not mutually exclusive.

Infrastructure as Code (IaC)

Infrastructure as code is the practice of defining infrastructure—networks, virtual machines, firewall rules, storage, identity policies—in machine-readable configuration files rather than by clicking through consoles. Tools such as Terraform, AWS CloudFormation, Azure Resource Manager templates and Bicep, and configuration-management tools such as Ansible read these files and build or modify the environment to match.

IaC is usually declarative: the file describes the desired end state, and the tool works out how to reach it. Applying the same file twice yields the same result (idempotence).

This Terraform snippet ensures a log bucket can never be made public—and because it is code, the setting is reviewed, versioned, and applied identically everywhere.

Figure 10.2: An IaC workflow in which templates are reviewed, scanned, deployed, and checked for drift Security benefits of IaC Security risks of IaC

Consistency: every environment is built from the same reviewed template, eliminating "snowflake" servers

Mistakes replicate at scale: one insecure line deploys the

same flaw everywhere

Version control: changes are reviewed and traceable, supporting change management (Chapter 2)

Secrets in code: hard-coded keys end up in repositories; use a secrets manager and secrets scanning (Chapter 14)

Pre-deployment scanning catches open ports or unencrypted storage in the CI/CD pipeline

The repository and pipeline become high-value targets, since whoever controls them controls production

Rapid recovery: environments can be rebuilt from code; drift detection reveals unauthorized changes

Manual console changes (drift) undermine the model if not detected and reverted

Real-world scenario

A retailer's cloud team builds environments by hand, and an auditor finds that the production database allows connections from any IP address while the test copy is restricted. The team migrates to IaC: all network rules now live in templates stored in a version-controlled repository, every change requires a pull request approved by a second engineer, and a pipeline scanner rejects any template that opens a database port to 0.0.0.0/0. Six months later, a developer makes an emergency console change; the nightly drift report flags it and the change is reverted. Consistency, review, and automated scanning are the security payoff of IaC.

On-Premises Architecture

An on-premises architecture places systems in facilities the organization owns or leases and operates itself. Before the cloud, this was the default.

The organization gets full control: it chooses hardware, configures every layer, controls physical access, and knows exactly where data resides—attractive for strict sovereignty or classification requirements. It also takes full responsibility: patching, monitoring, power, cooling, physical security, and investment in backups and alternate sites are all its own job, and capacity must be purchased in advance. On-premises is not inherently more or less secure than cloud. It is more controllable, which is a strength only when the organization has the expertise and budget to exercise that control well.

Operational Technology (OT)

Operational technology is hardware and software that monitors and controls physical processes— manufacturing lines, power grids, water treatment, pipelines, building management, and transportation systems. Related terms you should know:

Industrial control systems (ICS) is the umbrella term for systems that control industrial processes.
Supervisory control and data acquisition (SCADA) systems monitor and control geographically dispersed assets such as pipelines and substations.
Programmable logic controllers (PLCs) are ruggedized computers that directly operate machinery; human-machine interfaces (HMIs) are the screens operators use to view and control the process.

How OT Differs from IT

OT priorities differ from IT priorities in ways that change how security is applied.

Consideration Traditional IT Operational technology

Top priority Confidentiality and integrity of data

Availability and safety of the physical process

System lifespan 3-5 years 15-30 years or more

Patching Regular, often automated Rare; requires planned outages and vendor certification Reboots Acceptable during maintenance

May halt production or create safety hazards

Protocols Modern, often encrypted Legacy industrial protocols (Modbus, DNP3) often lacking authentication and encryption

Endpoint agents Standard Often unsupported or prohibited by the vendor
Consequence of
failure

Data loss, financial loss Physical damage, environmental harm, injury, or loss of life Security implications:

Safety and availability come first. An aggressive scan, automatic patch, or IPS that drops a legitimate control command can cause more harm than the attack it prevents. Passive monitoring is preferred.
Legacy, unpatchable systems and insecure protocols are common. Compensating controls (Chapter 1)—segmentation, allow-list firewalls, application allow listing, and monitoring—protect what cannot be patched.
IT/OT convergence. Connecting plant networks to corporate networks brings IT threats such as ransomware into environments never designed to resist them. Segment IT from OT, typically with an industrial DMZ and controlled jump hosts; the Purdue model is a common reference that organizes ICS networks into levels from the physical process up to enterprise IT.

Real-world scenario

A water utility's SCADA vendor needs remote access to perform diagnostics. Rather than opening a direct connection from the internet to the PLC network, the utility places a jump server in an industrial DMZ, requires MFA and approval for each session, records all vendor sessions, and permits the jump server to reach only the specific HMI the vendor supports. The PLCs remain unreachable from the corporate network and the internet. This layered approach respects OT's availability priority while sharply reducing the attack surface.

Exam tip

When a question involves ICS, SCADA, or a manufacturing plant, prioritize availability and safety. Answers that call for frequent patching, rebooting, or active scanning of production controllers are usually wrong; segmentation and compensating controls are usually right.

Air-Gapped Networks

An air-gapped network is physically isolated from all other networks, including the internet and the organization's own corporate network. There is no wired or wireless connection—data moves in or out only by physically carrying media across the gap. Air gaps protect classified military systems, critical safety systems, certain financial and cryptographic key-management systems, and offline backup vaults. Security implications:

Strongest isolation available. Remote network attacks are not possible because no network path exists.
Removable media becomes the attack vector. Stuxnet, which damaged Iranian uranium centrifuges, is the classic example of malware crossing an air gap on USB drives. Air-gapped environments need strict media controls: scanning stations, approved and encrypted devices, write-once media, and one-way data diodes where data must flow out but never in.
Insider threat is the dominant remaining risk, since only authorized personnel can bridge the gap.
Usability suffers. Patches and signatures must be carried in manually, so air-gapped systems often lag on updates.
Hidden connections—a forgotten wireless card or "temporary" cable—defeat the gap entirely, so it must be verified periodically.

Common trap

A network separated only by VLANs or firewall rules is not air-gapped—it is logically segmented. An air gap means no physical or wireless path exists at all. If a question says "no connection to any other network," it describes an air gap; if it says "firewall between segments," it describes segmentation.

Microservices

A microservices architecture builds an application as a collection of small, independent services, each responsible for one business function (user accounts, product catalog, payments, notifications), communicating over the network through APIs—typically HTTP/REST, gRPC, or message queues. It contrasts with a monolithic application, in which all functions are built and deployed as one unit. Microservices are usually packaged as containers and orchestrated by platforms such as Kubernetes.

Figure 10.3: A monolith exposes every function to a single breach, while microservices sit behind an API gateway and authenticate each other with mTLS

Security benefits include isolation (a compromised notification service need not compromise payments, if each has its own identity and network policy), independent patching (one service can be fixed and redeployed without touching the others), granular least privilege, and independent scaling and restart. Security challenges:

Larger internal attack surface. Every service exposes APIs, and east-west (service-to-service) traffic multiplies. Services typically authenticate each other with mutual TLS (mTLS), in which both sides present certificates; a service mesh can enforce mTLS and policy consistently.
API gateways provide a single controlled entry point for external requests, handling authentication, rate limiting, and input validation.
Secrets sprawl. Many services need credentials; a centralized secrets manager is essential.
Distributed logging. A single request may cross a dozen services, so investigations require centralized logs and correlation IDs. Container images must also be scanned and signed.

Memory aid

Monolith versus microservices: a monolith is one big house with one front door—break in once and you are in every room. Microservices are a neighborhood of small houses, each with its own lock—more doors to guard, but breaking into one house does not give you the others.

Segmentation: Logical and Physical

Segmentation divides a network into zones so that traffic between systems with different security needs can be controlled and inspected. It limits lateral movement, contains breaches, and reduces compliance scope (for example, isolating the PCI DSS cardholder data environment).

Logical Segmentation

Logical segmentation separates traffic using configuration on shared physical infrastructure. Common techniques include:

VLANs (virtual LANs), which divide one physical switch into multiple broadcast domains using 802.1Q tagging. Traffic between VLANs must pass through a router or firewall, where it can be filtered.
Subnetting with ACLs and firewall rules, and cloud virtual networks (VPCs/VNets) with security groups.
Microsegmentation, which applies policy at the level of individual workloads, often using host-based firewalls or hypervisor-level controls, so that even two servers in the same subnet cannot talk unless policy allows it. Microsegmentation is a core Zero Trust technique (Chapter 11). Logical segmentation is flexible and inexpensive, but it depends on correct configuration of shared hardware: a misconfigured trunk port or a VLAN hopping attack (switch spoofing or double tagging) can let traffic cross segments.

Physical Segmentation

Physical segmentation separates networks using different hardware—separate switches, routers, cabling, and sometimes separate rooms or buildings. Traffic between physically segmented networks can pass only through a deliberately installed device such as a firewall, or not at all. An air gap is the extreme form of physical segmentation.

Factor Logical segmentation Physical segmentation

Method VLANs, subnets, ACLs, SDN, microsegmentation Separate hardware and cabling Cost Low High

Flexibility High; changed by configuration Low; requires rewiring and hardware Assurance of isolation

Depends on correct configuration Strong; no shared hardware

Typical failure Misconfiguration, VLAN hopping Unauthorized cable or bridging device Typical use Separating departments, guest Wi-Fi, server tiers

Classified networks, OT safety systems, high-assurance environments

Exam tip

If a scenario stresses cost and flexibility, choose logical segmentation (VLANs). If it stresses the highest assurance that a misconfiguration cannot connect two networks, choose physical segmentation. If it stresses that no connection may exist at all, choose an air gap.

Technical Considerations

The objective lists eight technical considerations to weigh when comparing architectures. For each, think about how the different models compare.

Availability

Availability is the proportion of time a system is accessible and functioning, often expressed as a percentage ("five nines" = 99.999 percent, about five minutes of downtime per year). Public cloud providers offer multiple availability zones and regions with published SLAs, but one provider outage can affect thousands of customers at once. On-premises availability depends on the organization's own investment in redundancy. OT environments typically demand the highest availability of all, because downtime halts production.

Resilience

Resilience is the ability to withstand disruption and keep operating, or recover quickly. Availability is the outcome; resilience is the design that produces it. Microservices isolate failures where monoliths fail as a whole, and multicloud adds resilience against a single provider failing. Chapter 13 covers resilience in depth.

Proprietary Versus Open Source

Proprietary (closed-source) software and hardware are owned by a vendor who controls the code, updates, and support. Open-source software publishes its source code for anyone to inspect, modify, and redistribute under a license.

Factor Proprietary Open source

Code visibility

Hidden; trust the vendor Public; anyone can audit

Support Vendor contract and SLA Community, or paid third-party support

Patching Vendor's schedule Community or self-patched; can be fast, can be slow if a project is abandoned

Cost License fees Usually free to obtain; support and expertise cost money Lock-in Higher risk Lower risk; portable

Typical risk Vendor goes out of business or ends support

Unmaintained projects, supply-chain tampering, license compliance

Neither is automatically more secure. Open source benefits from many eyes only if those eyes are actually looking; proprietary products offer contractual accountability but require trust in code you cannot see.

Usability

Usability is how easy the system is to use correctly. Controls that make work harder invite workarounds —shadow IT, shared passwords, files emailed to personal accounts. Air-gapped networks have poor usability by design. A good architecture makes the secure path the easy path.

Responsibility

Responsibility concerns who performs each security task. On-premises puts it all on the organization; IaaS, PaaS, SaaS, and serverless progressively shift operational duties to the provider. Ambiguous responsibility is itself a vulnerability: tasks each party believes the other is doing do not get done.

Compute

Compute refers to the processing resources—CPU, memory, GPU—that an architecture can provide. Cloud offers elastic compute on demand; on-premises compute is fixed by what was purchased; serverless imposes limits on execution time and memory. Edge and OT devices often have so little compute that they cannot run encryption, endpoint agents, or modern authentication, forcing reliance on network-based controls instead.

Power Requirements

Power requirements are the electrical capacity and quality an architecture needs. On-premises data centers must provision utility feeds, UPS systems, generators, and cooling, and available power can limit how much equipment—especially high-density GPU racks for AI workloads—a facility can hold. Cloud providers handle power for their customers. Remote OT sites and low-power IoT devices may lack the energy budget for additional security appliances or strong cryptography. Power redundancy is covered in Chapter 13.

Ease of Recovery

Ease of recovery describes how quickly and simply an architecture can be restored after a failure or attack. IaC-defined environments, serverless functions, and containers can be rebuilt from code and images in minutes. On-premises systems may require hardware replacement and manual rebuilds. OT systems are especially hard to recover because configurations are unique and replacement parts for decades-old equipment may be scarce.

Real-world scenario

A logistics company is hit by ransomware that encrypts its on-premises application servers. Rebuilding those servers by hand takes four days. Its cloud-hosted customer portal, also affected, is restored in two hours: the team destroys the compromised environment, redeploys it from the IaC templates stored in version control, and restores data from immutable backups. The difference in recovery time is an ease-of-recovery consideration, and it becomes a major input to the company's decision to migrate more workloads to an IaC-managed cloud environment.

Business Considerations

Technical fit is not enough. The objective lists seven business considerations that frequently decide the architecture.

Data Sovereignty

Data sovereignty is the principle that data is subject to the laws of the country (or region) in which it is physically stored or processed. Data stored in another country's data centers may be accessible to that country's courts and authorities and may be subject to its privacy rules. Related terms are data residency (where data is physically stored, often by contractual or regulatory requirement) and data localization (laws requiring certain data to stay within national borders).

Public cloud customers must choose regions deliberately and verify that backups, replicas, and logs do not cross borders; some choose sovereign clouds or on-premises hosting to guarantee location. The EU's GDPR restricts transfers of personal data outside the EU without adequate safeguards (Chapter 25). If a question mentions a law requiring that citizens' data remain within the country, or concern about a foreign government compelling access to data, the concept is data sovereignty. The architectural response is to select in-country cloud regions, sovereign clouds, or on-premises hosting.

Data Classification

Data classification assigns labels such as public, confidential, restricted, or secret based on sensitivity (Chapter 12). Classification drives architecture: public content can live on a public CDN, regulated health data may require customer-managed encryption keys, and classified government data may require a dedicated community cloud or an air gap. Determine the highest classification a workload will process before choosing where it runs.

Cost

Cost includes capital expenditure (CapEx—buying hardware and facilities up front) and operational expenditure (OpEx—ongoing payments for services, power, staff, and licensing). Cloud shifts spending from CapEx to OpEx, but costs can rise unpredictably with usage and data egress. On-premises requires large up-front investment but may be cheaper for steady, predictable workloads. Security controls carry cost too: physical segmentation and dedicated private clouds cost more than logical or shared alternatives. Total cost of ownership (TCO) should include staff, training, and potential breach costs.

Ownership

Ownership concerns who owns the infrastructure, the data, and the risk. On-premises, the organization owns the hardware. In public cloud, the provider owns the infrastructure while the customer retains ownership of its data—contracts must say so clearly, including what happens to data at termination. Internally, every system and data set should have a named owner who accepts its risk (Chapter 23).

Environmental Requirements

Environmental requirements are the physical conditions an architecture needs or must survive: temperature, humidity, dust, vibration, space, and cooling. Data centers require precise HVAC and fire suppression; OT and edge devices on factory floors or in outdoor cabinets need ruggedized hardware. Regional hazards such as floods and earthquakes influence where facilities and cloud regions should be located. Moving to a cloud provider transfers most data center environmental requirements to that provider.

Scalability

Scalability is the ability to handle increased load. Vertical scaling adds power to an existing system; horizontal scaling adds more systems; elasticity scales automatically up and down with demand. Cloud, serverless, and microservices scale elastically; on-premises and OT scale slowly. Security tools must scale too: a SIEM sized for today's traffic may start dropping events when the business grows.

Risk

Risk ties the other considerations together. Moving to public cloud reduces some risks (hardware failure, physical security) and introduces others (misconfiguration, provider dependency, sovereignty). Each option must be evaluated against the organization's risk appetite (Chapter 23), including third-party and concentration risk from providers (Chapter 24).

Memory aid

To recall the business considerations, think "Some Companies Count Only Expensive Servers' Risk": Sovereignty, Classification, Cost, Ownership, Environmental, Scalability, Risk.

Chapter Summary

The shared responsibility model divides duties between provider and customer. The customer always owns its data, identities, and configuration; the provider always owns the physical facility.
Public clouds are shared by many unrelated tenants; private clouds serve one organization; hybrid clouds combine models; community clouds serve organizations with common needs.
Serverless removes OS management but leaves code, dependencies, and function permissions with the customer, and limits visibility.
Multicloud uses multiple providers to avoid lock-in and improve resilience, at the cost of complexity and fragmented visibility.
Infrastructure as code provides consistent, reviewable, scannable, and rapidly recoverable infrastructure, but replicates mistakes at scale and must keep secrets out of templates.
On-premises offers full control with full responsibility. OT prioritizes availability and safety and relies on segmentation and compensating controls for legacy systems.
Air-gapped networks have no network connection to anything; removable media and insiders are the main risks.
Microservices improve isolation and independent patching but multiply APIs and require service-to-service authentication such as mTLS.
Logical segmentation (VLANs, subnets, microsegmentation) is flexible and cheap; physical segmentation uses separate hardware for stronger assurance.
Technical considerations: availability, resilience, proprietary versus open source, usability, responsibility, compute, power requirements, ease of recovery.
Business considerations: data sovereignty, data classification, cost, ownership, environmental requirements, scalability, risk.

Key Terms

Cloud computing; shared responsibility model; responsibility matrix; IaaS; PaaS; SaaS; FaaS; public cloud; private cloud; hybrid cloud; community cloud; multitenancy; serverless; denial of wallet; multicloud; vendor lock-in; cloud security posture management (CSPM); infrastructure as code (IaC); declarative; idempotence; configuration drift; on-premises; operational technology (OT); industrial control system (ICS); SCADA; PLC; HMI; IT/OT convergence; Purdue model; air-gapped network; data diode; microservices; monolithic application; container; API gateway; service mesh; mutual TLS; segmentation; logical segmentation; VLAN; microsegmentation; physical segmentation; availability; resilience; proprietary; open source; usability; compute; power requirements; ease of recovery; data sovereignty; data residency; data localization; data classification; CapEx; OpEx; total cost of ownership; ownership; environmental requirements; vertical scaling; horizontal scaling; elasticity; risk.

Review Questions

1. A consortium of regional hospitals wants to share a cloud environment built specifically to meet healthcare privacy requirements, with costs divided among the members. Which deployment model BEST fits?

A. Public cloud
B. Private cloud
C. Community cloud
D. Hybrid cloud

2. A company stores customer files in a public cloud storage service. An investigation finds that a bucket was configured to allow anonymous public reads, exposing thousands of records. Under the shared responsibility model, who is responsible for this exposure?

A. The cloud provider, because it operates the storage service
B. The customer, because it configured access to its data
C. Both equally, because storage is a shared layer
D. The provider's auditor, who certified the service

3. A manufacturer's plant uses PLCs running firmware that the vendor will not update, and the controllers cannot be rebooted outside an annual shutdown. Which approach BEST reduces risk without affecting production?

A. Install endpoint detection agents on each PLC
B. Run weekly authenticated vulnerability scans against the controllers
C. Place the controllers in an isolated segment with allow-list firewall rules and passive monitoring
D. Enable automatic firmware updates from the vendor's website

4. A development team defines all network, compute, and identity resources in version-controlled templates that are scanned for misconfigurations before deployment. Which TWO security benefits does this approach provide? (Select TWO.)

A. Elimination of all vulnerabilities in application code
B. Consistent configuration across environments
C. Removal of the need for change management
D. Rapid rebuilding of environments after a compromise
E. Guaranteed data sovereignty

5. A national law requires that citizens' tax records be stored and processed only within the country's borders. Which business consideration does this requirement represent?

A. Data classification
B. Scalability
C. Data sovereignty
D. Ownership

6. A defense contractor must ensure that a design workstation network has no possible network path to the internet or to the corporate LAN. Updates are delivered on scanned, approved media. Which architecture is described?

A. Logical segmentation using VLANs
B. Air-gapped network
C. Private cloud
D. Microsegmentation

7. An organization runs workloads on two different public cloud providers to avoid dependence on any single vendor. Which challenge is MOST likely to increase?

A. Physical security of data centers
B. Hypervisor patching
C. Consistent configuration and visibility across different identity and policy models
D. Capital expenditure on hardware

8. A developer deploys a serverless function that resizes uploaded images. The function's execution role grants full read and write access to every storage resource in the account. What is the PRIMARY risk?

A. The provider cannot patch the operating system
B. A compromise of the function could be used to read or modify unrelated data
C. The function will not scale under load
D. The function cannot be monitored at all

9. A security architect needs to separate the guest Wi-Fi network from internal servers at low cost and with the ability to change the design easily. Which approach BEST meets the requirement?

A. Physical segmentation with separate switches and cabling
B. An air gap between guest and internal networks
C. Logical segmentation using VLANs and firewall rules between them
D. Moving internal servers to a community cloud

10. An e-commerce application is being re-architected from a monolith into microservices. Which security controls become MORE important as a result? (Select TWO.)

A. Mutual TLS between services
B. Air-gapping each service
C. Centralized logging with request correlation
D. Removing all API authentication to reduce latency
E. Running all services under one shared administrator account

11. A company compares two options for a new analytics platform: an on-premises cluster requiring a large up-front purchase, or a cloud service billed monthly by usage. Which consideration is the company PRIMARILY evaluating?

A. Cost (CapEx versus OpEx)
B. Environmental requirements
C. Data classification
D. Usability

12. Which statement BEST describes the difference between hybrid cloud and multicloud?

A. Hybrid uses multiple providers; multicloud combines on-premises and cloud
B. Hybrid combines different deployment models; multicloud uses multiple cloud providers
C. Hybrid is only for SaaS; multicloud is only for IaaS
D. They are identical terms

Answers and Explanations

1. C. A community cloud is shared by organizations with common requirements, such as healthcare compliance, with costs shared among the members. A public cloud serves unrelated customers, a private cloud serves a single organization, and a hybrid cloud combines models rather than serving a community.
2. B. The customer is always responsible for its data and for how it configures access to services. The provider secures the underlying infrastructure but does not decide who may read a customer's bucket. Responsibility for configuration is not split equally, and an auditor's certification does not transfer responsibility.
3. C. Segmentation with strict allow-list rules and passive monitoring is a compensating control that protects unpatchable OT devices without interrupting the process. PLCs generally cannot run endpoint agents, active scanning can disrupt fragile controllers, and automatic updates are both unavailable and inappropriate for systems that cannot reboot.
4. B, D. IaC builds every environment from the same reviewed templates, ensuring consistency, and allows environments to be destroyed and rebuilt quickly. It does not fix application code flaws, it supports rather than replaces change management (changes are reviewed in version control), and it does not by itself guarantee where data is stored.
5. C. A requirement that data stay within national borders is a data sovereignty (or localization) requirement. Classification concerns sensitivity labels, scalability concerns growth, and ownership concerns who owns the data or infrastructure.
6. B. No network path at all, with data carried across on media, defines an air gap. VLANs and microsegmentation are logical separation on connected infrastructure, and a private cloud is a deployment model that is normally networked.
7. C. Multicloud's main security challenge is that each provider has different identity systems, policy languages, and logging, making consistent configuration and visibility difficult. Physical security and hypervisor patching remain the providers' responsibilities, and multicloud does not require buying hardware.
8. B. The excessive permissions violate least privilege: if the function is exploited (for example, through a malicious uploaded file), the attacker inherits access to every storage resource. OS patching is the provider's job in serverless, scaling is automatic, and functions can be monitored through provider logs.
9. C. VLANs with firewall rules between them provide inexpensive, flexible logical segmentation. Physical segmentation and air gaps provide stronger isolation but at higher cost and lower flexibility, and moving servers to a community cloud does not address guest network separation.
10. A, C. Microservices multiply service-to-service communication, so mutual authentication with mTLS and centralized logging with correlation IDs become essential. Air-gapping services would prevent them from working, removing API authentication would expose every service, and a shared administrator account defeats per-service least privilege.
11. A. The comparison of a large up-front purchase (capital expenditure) against monthly usage billing (operational expenditure) is a cost consideration. Environmental requirements, classification, and usability are not the focus of the comparison.
12. B. Hybrid cloud combines different deployment models, such as private and public; multicloud uses services from more than one provider. Option A reverses the definitions, the terms are not limited to particular service models, and they are not identical—though an organization can be both at once.