Study guide
5.2 VMs vs Hosts, Cloud vs Virtual Hosting, SaaS and IaaS
TryHackMe Security Analyst Level 1 SAL1
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current SAL1 Exam Facts 1.2 24-Hour Window, Check-In, and Delivery 1.3 Scoring, Retakes, Validity, and Access 1.4 MCQ Section Strategy
2 SOC Simulator Exam Skills
2.1 Analyst VM, Splunk, and Dynamic Alerts 2.2 Classification and Escalation Scoring 2.3 Case Reports and Investigation Notes
3 Network Essentials
3.1 OSI, TCP/IP, Devices, and the Three-Way Handshake 3.2 HTTP, TLS, VPN, Web Browsing, and Email Transmission
4 Operating System Basics
4.1 Windows and Linux Architecture, Auth, Filesystems, Processes 4.2 Active Directory and Event Logs for Tracing Activity
5 Cryptography, Cloud, Web and Scripting Basics
5.1 Encoding, Encryption, Hashing, and Decoding Tools 5.2 VMs vs Hosts, Cloud vs Virtual Hosting, SaaS and IaaS 5.3 Web Apps, APIs, JSON/XML, Scripts vs Compiled Programs
6 Cybersecurity Fundamentals and MITRE ATT&CK
6.1 CIA, Least Privilege, Human Factors, Log4Shell, EternalBlue 6.2 Navigating MITRE ATT&CK: Tactics, Techniques, Sub-techniques 6.3 Mapping Real Attacks onto ATT&CK Techniques
7 Kill Chain, NIST CSF, and Attack Indicators
7.1 Cyber Kill Chain Stages vs MITRE ATT&CK 7.2 NIST CSF: Identify, Protect, Detect, Respond, Recover 7.3 IoC vs IoA and the Pyramid of Pain
8 Social Engineering and Network Attacks
8.1 Phishing: Impersonation, Typosquatting, Spoofing, Header Analysis 8.2 SPF, DKIM, DMARC, and Email Authentication Results 8.3 Port Scanning, DDoS, and Man-in-the-Middle 8.4 DNS Poisoning, ARP Spoofing, Exfiltration, and C2 Traffic Patterns
9 Web Exploitation and Endpoint Attacks
9.1 Client vs Server Vulnerabilities, XSS, and SQL Injection 9.2 Code Injection, Path Traversal, Input Validation, Patching, WAF 9.3 Initial Access (RDP/SSH), Persistence, Privilege Escalation 9.4 Credential Theft, Mimikatz, Sysmon, and Auditd
10 Command and Control, Malware, and LOLBAS
10.1 Forward vs Reverse Shells, Beaconing, Metasploit, Cobalt Strike 10.2 Malware Types, Static vs Dynamic Analysis, LOLBAS
11 EDR, Firewalls, and WAF
11.1 EDR vs AV, Telemetry, Containment, Remote Shell 11.2 Firewall Deployments, Limits, and Log Analysis 11.3 WAF Capabilities, Limits, and Rule Creation
12 SIEM and SOAR
12.1 SIEM Deployments, Parsing, and Raw Logs to Alerts 12.2 Alert Management, Threat Hunting, Triage, Reporting 12.3 SOAR Playbooks, Enrichment, and TI Integration
13 Threat Intelligence and Vulnerability Scanning
13.1 Feeds, Indicators, Classifying IPs, Domains, and Hashes 13.2 YARA and TI Integration with SIEM/SOAR 13.3 External vs Internal, Web vs Network Scanning
14 SOC Team, Activities, and Alert Triage
14.1 Blue/Red Teams, Hierarchy, and SOC Roles 14.2 Proactive vs Reactive: FP Remediation, Detection Engineering, Tabletop, DFIR, Threat Hunting 14.3 Workbooks; Ticket vs Alert vs Detection Rule 14.4 Triage Workflow, Severity, Status, and Verdicts
15 SOC Metrics, Escalation, and Communication
15.1 MTTA, MTTD, MTTR, SLA, and Lookups 15.2 Escalation Matrix, Urgent Remediation, and Cross-Team Communication
5.2 VMs vs Hosts, Cloud vs Virtual Hosting, SaaS and IaaS
Key Takeaways Explain This Topic AI
A virtual machine is a guest with virtual hardware; the physical host and hypervisor provide the real CPU, memory, and devices.
Type 1 hypervisors run on bare metal; Type 2 hypervisors run as software on a conventional host operating system.
On-prem virtual hosting is virtualisation on hardware the organization operates; public cloud is on-demand provider infrastructure reached through APIs and consoles.
IaaS examples are EC2-style virtual machines where the customer patches the guest OS; SaaS examples are Microsoft 365 and Gmail where the provider patches the platform.
Shared responsibility at analyst level starts with who patches the operating system: guest-VM owners in IaaS, the provider in PaaS and SaaS, while customers still own identity and data misconfiguration.
Last updated: September 2026
Virtual machines sit at the center of modern SOC work even when the ticket never uses the word hypervisor. An alert may name an EC2-style instance, a laptop running a local lab VM, or a Microsoft 365 mailbox that was never a VM at all. If you cannot tell a guest from a host, or Infrastructure as a Service (IaaS) from Software as a Service (SaaS), you will assign the patch to the wrong owner and look in the wrong logs. This independent study section covers virtualisation and cloud basics that appear in SAL1 training content, including service models with real-world examples.
Physical hosts versus virtual machines
A physical host is the real computer: CPU, RAM, storage, and network interfaces you could touch. It runs firmware and, unless it is a dedicated hypervisor appliance, a host operating system.
A virtual machine (VM) is a guest: software that presents virtual CPU, memory, disk, and a virtual NIC (network interface card) to a guest operating system . The guest believes it has hardware. The hypervisor schedules real hardware underneath and keeps guests isolated enough to share one box.
Consequences for analysts:
A process inside the VM is not visible on the physical host unless you have hypervisor-level or agent-level telemetry in that guest.
A compromised guest can still share a physical NIC, so network sensors outside the VM may see its traffic.
Snapshots and templates mean the same golden-image weakness can appear on many guests at once.
Time drift, cloned machine identifiers, and duplicated hostnames show up in investigations when VMs are copied carelessly.
The host and guest vocabulary matters in tickets. Patch the host might mean the hypervisor box, the laptop under a Type 2 product, or the guest OS. Write the layer you mean.
Hypervisors: Type 1 and Type 2
A Type 1 hypervisor (bare metal) runs directly on physical hardware. Datacenter products in this category include VMware ESXi, Microsoft Hyper-V in a server role, and Xen-based designs. There is no general-purpose desktop OS underneath the hypervisor as a required parent. Type 1 is what most on-prem server virtualisation and many cloud control planes resemble conceptually.
A Type 2 hypervisor runs as an application on a conventional host OS such as Windows, macOS, or Linux. Desktop lab tools such as VirtualBox and VMware Workstation are the usual examples. The host OS still owns devices; the hypervisor is a program. If malware owns the host OS, it can attack the hypervisor and every guest.
You do not need to memorize every vendor SKU for SAL1-style questions. You do need the layering: Type 1 sits on hardware; Type 2 sits on a host OS; guests sit on the hypervisor.
Hypervisor class Where it runs Typical use Analyst implication
Type 1, bare metal Directly on physical hardware Datacenter and cloud-style hosts Compromise of a guest does not automatically equal compromise of the hypervisor, but the physical NIC and storage still matter
Type 2, hosted As software on a host OS Analyst laptops and lab VMs Host-OS malware can see or attack guests; EDR on the laptop is as important as EDR in the VM
Cloud versus on-prem virtual hosting
On-premises virtual hosting means your organization, or a colocation site you control, owns or leases the physical servers and runs a hypervisor there. You still get VMs, snapshots, and virtual switches, but capacity planning, hardware failure, and hypervisor patching are yours or your datacenter vendor's. Access is typically over VPN or private circuits, not a public cloud API as the primary control plane.
Cloud computing means a provider pools hardware, exposes services through APIs and consoles, and bills for consumption. You pick a region, deploy in minutes, and share physical tenancy with other customers at the provider's layer; logical isolation is the provider's job. Key public providers analysts will see named in logs and documentation include Amazon Web Services (AWS) , Microsoft Azure , and Google Cloud Platform (GCP) . Naming them does not imply any exam-sponsor partnership; they are simply the platforms that dominate enterprise telemetry.
Differences that change investigations:
- Question On-prem virtual hosting Public cloud
- Who owns the hardware? The organization or its datacenter The provider
- How do you create a VM? Hypervisor console or internal automation Provider API, CLI, or portal
Where are logs? Local SIEM, hypervisor, and guest agents Guest agents plus provider audit logs for the management plane
- Identity boundary Active Directory and local accounts Cloud IAM plus optional directory sync
- Failure domain Your racks and WAN Provider region and availability zone plus your misconfiguration
Virtual hosting in this module is about virtualisation location and control, not the older web-hosting phrase that many websites share one HTTP server. If a question mentions websites sharing one Apache instance, that is a different idea.
Loading diagram... On-prem virtual hosting versus public cloud service models
SaaS, PaaS, and IaaS with real examples
Cloud service models describe how much of the stack you operate.
IaaS (Infrastructure as a Service) sells virtual machines, virtual networks, and virtual disks. An EC2-style VM — AWS Elastic Compute Cloud and equivalents such as Azure Virtual Machines or Google Compute Engine — is IaaS. You choose the image, log in with SSH (Secure Shell) or RDP (Remote Desktop Protocol), install software, and you patch the guest operating system . The provider patches the hypervisor and the physical plant.
PaaS (Platform as a Service) sells a managed runtime or data service. A managed database such as Amazon RDS, Azure SQL Database, or Cloud SQL is PaaS: you do not RDP into the database OS to apply engine patches; the provider does. You still configure firewall rules, accounts, and query-level security. Analysts should not open a patch Windows ticket against a managed database host they cannot log into.
SaaS (Software as a Service) sells the full application. Microsoft 365 and Gmail are the examples to keep. You do not patch Gmail's servers. You manage identities, sharing, mailbox rules, OAuth (Open Authorization) apps, and data classification. Compromise looks like inbox rules, token theft, and tenant misconfiguration, not a missing Windows KB on a mailbox server you own.
Model You operate Provider operates Analyst starting point
IaaS Guest OS, apps, data, VM firewall rules Hardware, hypervisor OS logs, EDR in the guest, cloud management events
- PaaS App config, data, access rules Runtime, OS, hardware Service audit logs, identity, data-plane anomalies
- SaaS Users, data, tenant settings App, OS, hardware Identity, email or SaaS audit, API grants
Shared responsibility at analyst level: who patches the OS?
Shared responsibility is the phrase cloud providers use for the split. For an entry-level analyst, translate it into one operational question: who is supposed to patch this operating system?
IaaS guest VM: the customer team that owns the instance, or the image pipeline, patches Windows or Linux. An unpatched SMBv1 finding belongs here.
PaaS managed database: the provider patches the OS and usually the engine; the customer patches nothing at the OS layer. A mis-set public IP or weak database user is still the customer's problem.
SaaS mailbox: there is no customer OS to patch. Multi-factor authentication (MFA) gaps and over-privileged OAuth apps are the customer problem.
If a playbook says isolate the host, confirm whether that host is a laptop, an IaaS VM, a hypervisor, or a SaaS tenant. Isolating a Microsoft 365 user is an identity action, not a hypervisor snapshot.
In practice: three alerts, three owners
Endpoint detection reports vulnerable OpenSSH on instance i-0a1b2c3d in AWS. This is IaaS. Check the guest, patch or replace the image, and review security groups.
A managed PostgreSQL instance accepts 0.0.0.0/0 on the data port. This is PaaS. You will not install a Windows patch; you will tighten the service firewall and credentials.
Impossible-travel sign-in on a Microsoft 365 mailbox. This is SaaS. Hunt refresh tokens and inbox rules; do not ask facilities to patch a Gmail OS.
Keep provider names factual and generic. AWS, Azure, and GCP appear in real SOC queues worldwide. Do not invent a special SAL1 relationship with any of them.
A final trap: lifting an on-prem VM into the cloud does not automatically make it SaaS. If you still RDP into Windows and install patches, you brought IaaS with you. If users only open a browser to a vendor app, you are in SaaS. Classify the stack you actually operate, not the billing brand on the invoice.