Cloud, Container, and Virtualization Operations

CompTIA Security+ SY0-701

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

Current Exam Facts and How Security+ Tests Judgment Domain Weighting and an 8-12 Week Study Plan Practice Questions, PBQs, and the Missed-Question Notebook

2 Domain 1: General Security Concepts (12%)

CIA and Non-Repudiation Control Types and Categories with Scenario Classification Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust Change Management and Business Impact

3 Domain 1: Identity, Trust, and Cryptography Basics

AAA and IAM Concepts Authentication Factors and MFA Traps Authorization Models: RBAC, ABAC, MAC, DAC, and Least Privilege Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules

4 Domain 2: Threat Actors, Vectors, and Social Engineering

Threat Actors and Motivations Attack Vectors and Attack Surface Social Engineering Types and Clues Supply Chain and Insider Threat Scenarios

5 Domain 2: Threats, Vulnerabilities, and Mitigations - Attacks

Malware Behaviors and Indicators Credential and Password Attacks Network and Wireless Attacks Application, API, and Cloud Attacks with Mitigation Mapping

6 Domain 2: Threats, Vulnerabilities, and Mitigations - Vulnerabilities

Vulnerability Types and Misconfiguration Vulnerability Scanning and Prioritization Secure Coding and Application Mitigations Remediation, Compensating Controls, and Risk-Based Decisions

7 Domain 3: Security Architecture - Secure Architecture Models

Architecture Models and Trust Boundaries Cloud Shared Responsibility and Service Models Zero Trust, SASE, and SSE Concepts Secure Design Review Scenarios

8 Domain 3: Security Architecture - Network Security Architecture

Segmentation, VLANs, DMZ, and Microsegmentation Firewalls, WAF, IDS, IPS, and Proxies VPN, Remote Access, and NAC Wireless Security and Enterprise Network Design

9 Domain 3 Part C: Data Protection and Resilience

Data Classification and Handling Encryption at Rest, in Transit, in Use, and Key Management DLP, Privacy, and the Data Lifecycle Backups, RTO, RPO, BCP, DR, and Resilience

10 Domain 4 Part A: Secure Operations for Hosts, Cloud, Mobile, and IoT

Endpoint and Server Hardening Cloud, Container, and Virtualization Operations Mobile, BYOD, and MDM Embedded, IoT, OT, and Physical Device Security

11 IAM Operations and Access Control

Provisioning, Deprovisioning, and Access Reviews PAM, JIT, JEA, and Service Accounts Federation, SSO, SAML, OIDC, and OAuth Account Attacks and IAM Monitoring

12 Logging, Monitoring, and Detection

Log Sources and Telemetry SIEM Correlation and Alert Triage SOAR, Playbooks, and Automation Detection Use Cases and False-Positive Handling

13 Incident Response

IR Phases and Roles Containment, Eradication, and Recovery Decisions Communication, Escalation, Legal, and Regulatory Considerations Post-Incident Lessons Learned and Metrics

14 Digital Forensics and Investigation

Evidence Handling and Chain of Custody Disk, Memory, Network, and Log Artifacts Order of Volatility and Acquisition Choices Forensic Reporting and Anti-Forensics Traps

15 Vulnerability, Patch, Asset, and Automation Operations

Asset Inventory and Data Classification in Ops Vulnerability Lifecycle and CVSS/Risk Priority Patch, Change, and Configuration Management Automation, Orchestration, SCAP, and Security Tooling

16 Governance, Policies, and Risk Management

Governance Documents: Policy, Standard, Procedure, and Baseline Risk Register and Risk Treatment Quantitative/Qualitative Risk and BIA Exceptions, Acceptance, Ownership, and Reporting

17 Third-Party Risk, Compliance, and Privacy

Vendor Risk Lifecycle and Agreements Due Diligence, Questionnaires, and Monitoring Privacy Concepts and Data Rights Compliance Reporting and Consequences

18 Audits, Penetration Testing, and Awareness

Internal and External Audits and Evidence Penetration Test Types and Rules of Engagement Security Awareness, Training, and Phishing Metrics Personnel and Physical Security Program Controls

19 Final Review and PBQ Labs

PBQ Workflow and Timing Ports, Protocols, and Acronyms High-Yield Tables Firewall, IAM, Log, and Risk PBQ Mini-Labs Final 7-Day Review Plan Mixed Exam Strategy and Missed-Question Remediation

Cloud, Container, and Virtualization Operations

Key Takeaways Explain This Topic AI

The shared responsibility model defines who secures each layer; the customer always owns identity, data, and configuration even in SaaS.

Misconfiguration, not provider breach, is the dominant cloud risk: public storage buckets, over-permissive IAM, and exposed management interfaces.

Container security covers trusted/signed images, minimal base images, scanning in CI, externalized secrets, and dropping privileges at runtime.

Virtualization risk includes VM escape, VM sprawl, insecure golden images, and unprotected snapshots; harden the hypervisor and templates.

Infrastructure as code delivers consistency but can deploy the same insecure setting at scale, so templates need scanning and change review.

Last updated: June 2026

Shared Responsibility Is a Guaranteed Exam Topic

Cloud does not remove security operations; it changes who manages each layer and how fast a single mistake scales. The shared responsibility model is one of the most frequently tested cloud concepts on SY0-701. Memorize the dividing line: the provider secures the cloud (facilities, hardware, the service itself) and the customer secures what they put in the cloud (identity, data, configuration).

Model Provider manages Customer manages
IaaS Facilities, hardware, host hypervisor Guest OS, apps, data, IAM, network rules, patching
PaaS Platform runtime, OS, scaling App code, data, IAM, app configuration
SaaS Application, platform, all infrastructure Users, access, data, sharing/retention settings

The classic question: in SaaS, who disables a departing employee's account? The customer. The provider patches the application, but identity, access, data, and sharing configuration always stay with the customer .

Cloud Operations Controls

Control Purpose
IAM least privilege Scope each role to the minimum API and resource access
MFA for administrators Protect the management plane from credential theft
Security groups / network ACLs Restrict allowed network paths
Cloud audit logging Record API calls, authentication, and resource changes
CSPM (Cloud Security Posture Management) Continuously find risky misconfigurations such as public buckets
Secrets manager Store credentials outside code, images, and repos
Resource tagging Drive ownership, classification, cost, and incident response
IaC scanning + review Stop insecure templates from being deployed repeatedly
Containers Are Not Full VMs

A container shares the host kernel; it is process-level isolation , not a full virtual machine with its own kernel. That distinction drives the controls: protect the image and the runtime.

Image source : pull from trusted, signed registries; verify provenance.

Base image : use minimal, maintained images (for example distroless or slim) to shrink attack surface.

Scanning : scan images in the CI/CD pipeline and during the runtime lifecycle.

Secrets : inject at runtime via a secrets manager; never bake them into image layers or commit .env files.

Privileges : avoid --privileged , run as non-root, and drop unneeded Linux capabilities.

Virtualization and Hypervisor Risks

Risk Control
VM escape / hypervisor compromise Patch the hypervisor; restrict and MFA admin access
VM sprawl Inventory, ownership, and lifecycle decommissioning
Insecure templates Harden the golden image before cloning
Snapshot exposure Encrypt, restrict, and expire snapshots with sensitive data
Lateral movement Microsegmentation and least privilege between workloads
Worked Scenario

A team deploys a containerized API into a cloud account. A strong posture uses least-privilege service roles, private subnet placement, TLS terminated at the ingress, image scanning in CI, no hardcoded secrets, runtime logging to the cloud audit trail, CPU/memory limits, patched worker nodes, and an infrastructure-as-code template that passed a policy scan in code review.

Common Exam Traps

Trap answer Better reasoning

"The provider secures everything." Shared responsibility leaves identity, data, and configuration with the customer.

"A container is just a small VM." Containers share the host kernel and need image and runtime controls.

"Snapshots are harmless temp files." Snapshots can contain full disk data and must be protected.

"IaC is automatically secure." Templates need scanning, review, and change control.

The Misconfiguration Problem Dominates Cloud Breaches

The exam echoes industry reality: the most common cause of cloud data exposure is not a provider failure but a customer misconfiguration . Know the recurring offenders and the control that catches each.

Misconfiguration Detection / fix
Public object storage bucket CSPM rule flags public ACL; default to private + bucket policy
Over-permissive IAM (wildcard * actions) Access analyzer + least-privilege policy review
Exposed management interface (SSH/RDP open to 0.0.0.0/0) Security group restriction + bastion/jump host
Disabled or unmonitored audit logging Enforce logging via organization policy
Long-lived static access keys Rotate keys; prefer short-lived roles and federation
Cloud Network and Identity Architecture

Cloud security operations lean heavily on identity as the new perimeter . Prefer federated identity and short-lived tokens over static keys, and require MFA on every privileged role. Network controls layer on top: place sensitive workloads in private subnets , expose only what is needed through a load balancer or API gateway, and use VPC/VNet peering or transit gateways with explicit routes rather than broad open connectivity.

A cloud access security broker (CASB) sits between users and cloud services to enforce data loss prevention, visibility, and access policy across sanctioned and unsanctioned SaaS. The exam pairs CASB with discovering shadow IT (unsanctioned SaaS adopted by business units).

Serverless and the Vanishing OS

With serverless functions (for example, function-as-a-service), the customer no longer patches an operating system at all, but still owns code dependencies, function permissions, secrets handling, and event-source configuration. The exam uses serverless to reinforce that responsibility does not disappear; it concentrates into identity, code, and configuration.