CompTIA SY0-701: Cloud, Virtualization & Container Security — Study Guide

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Part of the CompTIA Security+ SY0-701 — Complete Study Guide. Practice with verified answers in the CompTIA exam hub, or take timed practice tests on ExamRoll.io.

Modern enterprises rarely operate in a single, self-contained data center. Workloads span public cloud providers, private virtualization clusters, container orchestrators, and ephemeral serverless functions. Each abstraction layer changes the threat model, the control surface, and — critically — who is accountable for which security controls.

The Shared Responsibility Model

Every major cloud provider publishes a shared responsibility model that partitions security duties between the customer and the cloud service provider (CSP). The dividing line shifts based on the service tier.

In Infrastructure as a Service (IaaS) — Amazon EC2, Azure Virtual Machines, Google Compute Engine — the CSP secures the physical facilities, hardware, hypervisor, and network fabric. Everything above the hypervisor belongs to the customer: the guest operating system, patching, host-based firewalls, middleware, runtime, application code, identity configuration, and the data itself. If a company deploys a MySQL database on an EC2 instance, securing that database is entirely the customer’s responsibility.

In Platform as a Service (PaaS) — AWS RDS, Azure App Service, Google App Engine — the provider additionally manages the operating system, database engine patching, and runtime. The customer remains responsible for application code, data classification, access controls, network exposure rules, and identity management.

In Software as a Service (SaaS) — Microsoft 365, Salesforce, Workday — the provider handles nearly the entire stack. The customer’s remaining responsibilities are non-trivial: account provisioning and deprovisioning, MFA enforcement, data classification, sharing permissions, DLP configuration, and integration with the corporate identity provider. A misconfigured SharePoint site that exposes payroll data to “Everyone” is not Microsoft’s breach — it is the tenant administrator’s.

A persistent misconception is that migrating to the cloud transfers all security responsibility to the provider. Data breaches involving misconfigured S3 buckets, exposed Elasticsearch clusters, and leaked API keys almost universally trace back to customer-side errors, not CSP compromise.

Virtualization and Hypervisor Risk

Virtualization pools physical hardware into logical guests using a hypervisor. Type 1 (bare-metal) hypervisors such as VMware ESXi, Microsoft Hyper-V, and KVM run directly on hardware. Type 2 (hosted) hypervisors like VirtualBox run atop a general-purpose OS and are unsuitable for production workloads.

The dominant virtualization-specific threats are VM escape and hypervisor compromise. VM escape occurs when malicious code inside a guest breaks out of its virtualization boundary and executes on the hypervisor or an adjacent VM. Historical examples include CVE-2015-3456 (VENOM, in QEMU’s floppy controller) and various VMware Tools vulnerabilities. Because a single hypervisor may host hundreds of workloads across multiple trust zones, a successful escape yields disproportionate access.

Mitigations include rigorous hypervisor patching, minimizing guest additions and unused emulated hardware, separating workloads by sensitivity onto distinct clusters, and isolating the management plane. The vCenter server, ESXi management interfaces, and cluster APIs must reside on a dedicated management network reachable only from privileged jump hosts with MFA.

Additional concerns include VM sprawl (orphaned, unpatched VMs accumulating over time) and resource reuse where memory or storage from a decommissioned VM is not properly zeroed before allocation to another tenant.

Containers, Microservices, and Kernel Sharing

Containers package an application with its dependencies but, unlike VMs, share the host operating system kernel. Docker, containerd, and CRI-O manage container lifecycles; Kubernetes orchestrates them at scale. This lightweight isolation is a feature — startup in milliseconds, dense packing — but also the primary risk.

Container isolation is not equivalent to VM isolation. A kernel vulnerability exploited from within a container can compromise the host and every other container on it. Namespaces (PID, network, mount, UTS, IPC, user) and cgroups provide isolation, but they are software constructs sharing a single attack surface.

Container security requires controls across the pipeline:

# Example: Pod security context enforcing hardening
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Images must be scanned for vulnerabilities before deployment (Trivy, Snyk, Clair), built from minimal base images (distroless or Alpine), and pulled only from trusted registries with image signing enforced (Cosign, Notary). Runtime protection tools (Falco, Aqua, Sysdig) monitor container behavior and alert on anomalies such as unexpected process execution or network connections.

Cloud Security Posture and IAM

Cloud IAM differs from on-premises Active Directory in important ways. In AWS, IAM policies are JSON documents attached to users, groups, or roles, and the effective permission is the intersection of identity-based policies and resource-based policies, with explicit denies always winning:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::company-data/*",
    "Condition": {
      "StringEquals": {"aws:RequestedRegion": "us-east-1"}
    }
  }]
}

Cloud Security Posture Management (CSPM) tools continuously scan cloud configurations against security benchmarks (CIS AWS Foundations, NIST), flagging public S3 buckets, overly permissive security groups, disabled CloudTrail logging, and unencrypted EBS volumes. Cloud Access Security Brokers (CASBs) sit between users and cloud services, enforcing DLP, access policies, and threat detection for SaaS applications.

Practical Scenario: Misconfigured S3 Bucket Exposing PII

A healthcare startup stored patient intake forms in an S3 bucket that had been created with public read access during a development sprint and never locked down before going to production. The bucket was discovered by a security researcher using a combination of DNS brute-forcing and the AWS S3 bucket enumeration technique. Approximately 87,000 patient records — including names, dates of birth, insurance IDs, and chief complaint descriptions — were accessible without authentication. The startup had no CSPM tool and no automated configuration scanning. A basic AWS Config rule checking for s3-bucket-public-read-prohibited would have flagged the misconfiguration within minutes of creation. The incident resulted in an HHS investigation, a $450,000 settlement, and reputational damage that contributed to the company’s acquisition at a distressed valuation.

← Application · All domains · Data Security →

Practice these questions → · Timed practice on ExamRoll.io →