Cloud-specific vulnerabilities — SY0-701

WHAT IT IS

Cloud-specific vulnerabilities are weaknesses that arise from properties unique to cloud environments — on-demand shared infrastructure, layered service models, and distributed access — that could be exploited or triggered by a threat source. The term vulnerability is used here in the NIST sense: "weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source" (NIST SP 800-30 Rev. 1 via CSRC Glossary).

Cloud computing, as defined by NIST SP 800-145, is "a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources." The same properties that make it convenient — shared pools, rapid provisioning, broad network access — introduce vulnerabilities that do not appear (or appear differently) in traditional on-premises deployments.

Mental model

Think of cloud infrastructure as a multi-unit apartment building run by a landlord (the cloud service provider). The landlord owns and secures the building structure, HVAC, and locks on the front door. Each tenant is responsible for locking their own unit, keeping valuables off the windowsill, and not accidentally propping the stairwell door open for everyone else. When a tenant misconfigures their unit — leaves the door unlocked, runs a noisy appliance at 3 a.m. — it can affect the whole building. The landlord is not responsible for what happens inside each unit. That division is the shared responsibility gap, and it is the root cause behind most cloud-specific vulnerability categories.

When to use it

Cloud-specific vulnerabilities are the right lens whenever a question describes a weakness that originates from the cloud deployment model itself, not from a flaw in application code or user behavior alone.

Scenario	Correct framing	Why
A storage bucket is publicly readable because a default setting was not changed	Misconfiguration vulnerability	The configuration setting, not the software, is the weakness (NIST SP 800-128: "incorrect or suboptimal configuration... that may lead to vulnerabilities")
An attacker on one virtual machine reads memory belonging to a neighboring VM	Side-channel / isolation failure	Arises from shared physical hardware — a multitenancy property
A developer stores credentials in a public cloud repository	Insecure secrets management	Configuration / access control failure; not a flaw in the cloud platform itself
An IAM policy grants every user admin rights	Violation of least privilege	A least-privilege control gap (NIST SP 800-53 Rev. 5: "each entity is granted the minimum system resources and authorizations that the entity needs to perform its function")
A third-party cloud add-on receives excessive permissions	Supply chain risk	"Potential for harm or compromise that arises as a result of security risks from suppliers" (NIST SP 800-53 Rev. 5)

COMMON MISCONCEPTION

The most persistent trap is assuming the cloud provider secures everything. In the shared responsibility model, the provider secures the underlying infrastructure — compute, storage fabric, networking hardware — while the customer retains responsibility for what they deploy on top of it: identity and access management, data classification, configuration of storage buckets, network security groups, and API exposure.

A related misconception is that a vulnerability must involve malicious code. NIST defines a misconfiguration explicitly as "an incorrect or suboptimal configuration of an information system or system component that may lead to vulnerabilities" (NIST SP 800-128 via CSRC Glossary). No attacker needs to write a single line of code to exploit a publicly exposed storage bucket or an overly permissive IAM role — the misconfiguration itself is the vulnerability.

A third misconception: multitenancy is a risk only when tenants are in the same account. Isolation failures can occur at the hypervisor, container runtime, or network layer even when tenants have no visible relationship — because the underlying physical resources are shared.

How it shows up on the exam

The cognitive target is application — candidates must recognize which cloud property creates which category of vulnerability, and then select the control that addresses that specific property rather than a generic security control.

Watch for questions that:

• Describe a storage resource becoming publicly accessible after a routine change — the question tests whether you distinguish a misconfiguration vulnerability from a software vulnerability or an active attack.
• Present a scenario where two customers' workloads run on the same host — the question tests whether you recognize isolation failure as a multitenancy risk, not an insider threat.
• Frame a permissions error as the cloud provider's fault — the question is testing whether you understand the shared responsibility boundary: broad access control is "the process of granting or denying specific requests for obtaining and using information" (NIST SP 800-53 Rev. 5), and that process is the customer's obligation for the resources they own.
• Reference an IAM policy that grants more rights than a role needs — the question maps to least-privilege violations: NIST defines least privilege as a system that "restrict[s] the access privileges of users... to the minimum necessary to accomplish assigned tasks" (CNSSI 4009-2015 via NIST SP 800-12 Rev. 1).

The attack surface concept (NIST SP 800-53 Rev. 5: "set of points on the boundary of a system... where an attacker can try to enter, cause an effect on, or extract data from") expands significantly in cloud deployments because APIs, management consoles, and shared services all become additional boundary points.

Related concepts

• Memory Vulnerabilities — isolation failures in shared cloud hosts can have surface-level similarity to memory-based attacks, but differ in root cause and ownership.
• Race Conditions — concurrent access to shared cloud resources can introduce time-of-check/time-of-use weaknesses, a specific subcategory of cloud vulnerability.
• SQL Injection — a code-level vulnerability that can coexist with cloud deployments but is not caused by cloud properties; distinguishing them tests the same "right lens for the scenario" skill.