Compare and contrast security implications of different architecture models

Every architecture model has different security tradeoffs. The exam tests whether you can evaluate which model fits a given scenario and what security controls each requires.

Cloud Models

Infrastructure as a Service (IaaS)

Provider manages: physical hardware, networking, virtualization. Customer manages: OS, middleware, runtime, applications, data.

• Most control, most responsibility. You patch the OS, configure firewalls, manage access.
• Examples: AWS EC2, Azure VMs, Google Compute Engine
• Security implication: Misconfiguration is on you. A misconfigured security group is your problem, not the provider’s.

Platform as a Service (PaaS)

Provider manages: everything in IaaS + OS, middleware, runtime. Customer manages: applications and data.

• Less control, less operational burden. Provider handles patching the underlying platform.
• Examples: AWS Elastic Beanstalk, Azure App Service, Heroku
• Security implication: You can’t harden the OS directly. Trust the provider’s security or don’t use the platform.

Software as a Service (SaaS)

Provider manages: everything. Customer manages: data and user access configuration.

• Least control. You configure the application; the provider runs everything underneath.
• Examples: Microsoft 365, Salesforce, Google Workspace
• Security implication: Your security levers are limited to access controls, data policies, and API integrations. Shadow IT risk — users adopt SaaS without IT approval.

Anything as a Service (XaaS)

Catch-all for other service models: Security as a Service (SECaaS), Desktop as a Service (DaaS), etc.

Shared Responsibility Model

The single most important concept in cloud security:

Layer	IaaS	PaaS	SaaS
Data	Customer	Customer	Customer
Application	Customer	Customer	Provider
OS/Runtime	Customer	Provider	Provider
Infrastructure	Provider	Provider	Provider
Physical	Provider	Provider	Provider

Exam trap: Questions will describe a cloud security incident and ask who’s responsible. Data classification and access control are ALWAYS the customer’s responsibility regardless of model.

Deployment Models

Public Cloud

Shared infrastructure operated by a third-party provider. Multi-tenant — your workloads run alongside other customers’.

• Cost-effective, scalable, but you share the physical infrastructure

Private Cloud

Dedicated infrastructure for a single organization. Can be on-premises or hosted.

• More control, higher cost. May be required for compliance (HIPAA, classified data)

Hybrid Cloud

Combination of public and private. Workloads move between them based on requirements.

• Sensitive data stays private; burstable/scalable workloads go public
• Security challenge: Consistent policy enforcement across both environments

Community Cloud

Shared infrastructure for organizations with common requirements (e.g., government agencies, healthcare providers).

On-Premises

All infrastructure owned, operated, and maintained in your own facilities.

• Full control, full responsibility. You own every layer of the stack.
• Security advantage: Data never leaves your physical control
• Security disadvantage: You need the expertise and budget for every aspect of security
• Increasingly rare as a pure model — most orgs are hybrid

Edge and Fog Computing

Edge Computing

Processing data near the source (IoT devices, local gateways) rather than in a central data center.

• Reduces latency, reduces bandwidth to central systems
• Security challenge: Many distributed nodes, each a potential attack surface. Physical security of edge devices is often weak.

Fog Computing

Intermediate layer between edge devices and the cloud. Local processing with cloud coordination.

• Aggregates and pre-processes edge data before sending to cloud

Containerization and Microservices

Containers

Lightweight, isolated environments that package an application with its dependencies.

• Docker, Podman, containerd
• Share the host OS kernel (unlike VMs which have their own OS)
• Security considerations:
  • Container escape vulnerabilities (breaking out to the host)
  • Image security — base images may contain vulnerabilities
  • Registry security — only pull from trusted registries
  • Least privilege — containers shouldn’t run as root
  • Immutable deployments — don’t patch running containers, replace them

Microservices

Architecture pattern where an application is composed of small, independent services communicating via APIs.

• Each service can be developed, deployed, and scaled independently
• Security considerations:
  • Service-to-service authentication (mTLS, service mesh)
  • API security for every service boundary
  • Increased east-west traffic that must be monitored
  • More components = larger attack surface to manage

Serverless

Functions that run on-demand without managing servers. Provider handles all infrastructure.

• AWS Lambda, Azure Functions, Cloudflare Workers
• Security considerations: Execution environment is ephemeral. You control the code; the provider controls everything else. Function permissions must follow least privilege. Cold-start timing can leak information.

Infrastructure as Code (IaC)

Defining infrastructure through machine-readable configuration files rather than manual setup.

• Terraform, CloudFormation, Pulumi, Ansible
• Security benefit: Repeatable, auditable, version-controlled deployments. Drift detection catches unauthorized changes.
• Security risk: IaC templates with hardcoded secrets or overly permissive defaults become a vulnerability at scale.

Software-Defined Networking (SDN)

Separating the control plane (routing decisions) from the data plane (packet forwarding).

• Centralized network management, programmable policies
• Security benefit: Granular microsegmentation, rapid policy changes, consistent enforcement
• Security risk: The SDN controller is a high-value target — compromise it and you control the entire network

SCADA/ICS and Embedded Systems

Industrial Control Systems (ICS)

Systems that manage physical processes — power grids, water treatment, manufacturing.

SCADA (Supervisory Control and Data Acquisition)

Specific type of ICS for remote monitoring and control of industrial processes.

• Often legacy systems with long lifecycles (15-25 years)
• May run outdated, unpatched operating systems
• Originally designed for isolated networks, now increasingly connected
• Security considerations:
  • Air gapping (physical isolation) where possible
  • Network segmentation between IT and OT (Operational Technology)
  • Availability is the priority — downtime can cause physical damage or safety hazards
  • Patching is complex — requires maintenance windows and vendor coordination

IoT (Internet of Things)

Connected devices: cameras, sensors, smart appliances, medical devices.

• Often have weak default credentials, limited update mechanisms, minimal security features
• Massive attack surface — billions of devices, many unmanaged

Offensive Context

Architecture choices determine the attack surface before a single line of code is written. An attacker evaluating a target asks: cloud or on-prem? What’s the shared responsibility boundary? Are containers hardened or running default Docker Hub images as root? Is the ICS network truly air-gapped or is there a forgotten VPN bridge? The architecture model you choose doesn’t just affect how you defend — it determines what the attacker targets first.