7.3 Infrastructure & Platform Risks (Domain 3.3)

Certified Cloud Security Professional CCSP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current CCSP Exam Facts 1.2 CAT Format, Scoring & Logistics 1.3 Eligibility, Experience & Certification Maintenance

2 Domain 1: Cloud Concepts & Architecture Foundations

2.1 Cloud Computing Concepts (Domain 1.1) 2.2 Cloud Reference Architecture (Domain 1.2) 2.3 Security Concepts Relevant to Cloud (Domain 1.3)

3 Domain 1: Secure Design, CSP Evaluation & AI/ML

3.1 Design Principles of Secure Cloud Computing (Domain 1.4) 3.2 Evaluate Cloud Service Providers (Domain 1.5) 3.3 AI/ML in Cloud Security (Domain 1.6)

4 Domain 2: Data Concepts, Storage & Protection Technologies

4.1 Cloud Data Concepts (Domain 2.1) 4.2 Cloud Data Storage Architectures (Domain 2.2) 4.3 Data Security Technologies & Strategies (Domain 2.3)

5 Domain 2: Discovery, Classification & Information Rights Management

5.1 Data Discovery (Domain 2.4) 5.2 Data Classification (Domain 2.5) 5.3 Information Rights Management (Domain 2.6)

6 Domain 2: Retention, Auditability & AI/ML Data Protection

6.1 Retention, Deletion & Archiving (Domain 2.7) 6.2 Auditability, Traceability & Accountability (Domain 2.8) 6.3 AI/ML Data Protection (Domain 2.9)

7 Domain 3: Infrastructure Components, Data Center & Risks

7.1 Cloud Infrastructure Components (Domain 3.1) 7.2 Secure Data Center Design (Domain 3.2) 7.3 Infrastructure & Platform Risks (Domain 3.3)

8 Domain 3: Security Controls & Business Continuity / Disaster Recovery

8.1 Security Controls Implementation (Domain 3.4) 8.2 Business Continuity & Disaster Recovery (Domain 3.5)

9 Domain 4: Application Security Awareness & Secure SDLC

9.1 Application Security Training & Awareness (Domain 4.1) 9.2 Secure SDLC Process (Domain 4.2) 9.3 Apply Secure SDLC (Domain 4.3)

10 Domain 4: Software Assurance, Architecture & IAM

10.1 Cloud Software Assurance & Validation (Domain 4.4) 10.2 Verified Secure Software (Domain 4.5) 10.3 Cloud Application Architecture (Domain 4.6) 10.4 Identity & Access Management Solutions (Domain 4.7)

11 Domain 5: Build, Operate & Operational Controls

11.1 Build Physical & Logical Infrastructure (Domain 5.1) 11.2 Operate & Maintain Infrastructure (Domain 5.2) 11.3 Operational Controls & Standards (Domain 5.3)

12 Domain 5: Forensics, Stakeholder Communication & Security Operations

12.1 Digital Forensics Support (Domain 5.4) 12.2 Communication with Relevant Parties (Domain 5.5) 12.3 Manage Security Operations (Domain 5.6)

13 Domain 6: Legal Requirements, Privacy & Audit

13.1 Legal Requirements & Cloud Risks (Domain 6.1) 13.2 Privacy Requirements (Domain 6.2) 13.3 Audit Processes for Cloud (Domain 6.3)

14 Domain 6: Enterprise Risk Management & Cloud Contracts

14.1 Cloud Implications for Enterprise Risk (Domain 6.4) 14.2 Outsourcing & Cloud Contract Design (Domain 6.5)

7.3 Infrastructure & Platform Risks (Domain 3.3)

Key Takeaways Explain This Topic AI

Risk assessment for cloud infrastructure includes identification of assets/threats/vulnerabilities and analysis of likelihood and impact under shared responsibility.

Cloud-specific vulnerabilities, threats, and attacks include misconfiguration, credential theft, hypervisor/container escape, insecure APIs, data exfiltration, and denial of service.

Risk treatment strategies are avoid, mitigate, transfer/share, and accept — plus residual risk monitoring; not every risk is patched away.

Platform risk spans CSP control planes, multi-tenancy isolation, supply chain, and customer configuration debt — inventory both provider and tenant surfaces.

CCSP scenarios reward structured assessment language over product brand names.

Last updated: July 2026

Infrastructure and Platform Risks

Domain 3.3 asks you to analyze risks associated with cloud infrastructure and platforms . The outline breaks this into:

Risk assessment (identification, analysis)
Cloud vulnerabilities, threats, and attacks
Risk treatment strategies

This is applied risk management on the components and data-center designs you just studied. Domain 6 expands enterprise risk and legal themes; here the focus is platform and infrastructure — hypervisors, networks, management planes, multi-tenancy, and facility dependencies.

Risk Vocabulary Refresh

Term Working definition
Asset Something of value (data, service, reputation, hardware, API availability)
Threat Potential cause of an unwanted incident
Vulnerability Weakness that a threat can exploit
Risk Effect of uncertainty on objectives — often Likelihood × Impact (qualitative or quantitative)
Control Measure that modifies risk
Residual risk Risk remaining after treatment
Risk appetite / tolerance How much risk the organization is willing to take

Cloud does not invent new risk math; it changes speed, shared tenancy, abstraction, and control ownership . A vulnerability in a customer security group can be exploited worldwide within minutes via the management plane — likelihood and impact models must reflect that.

Risk Assessment: Identification

Identification inventories what can go wrong and what matters.

Identify assets (infrastructure scope)

Asset class Examples
Data Databases, object stores, backups, logs, secrets
Workloads VMs, containers, functions, AI training jobs
Identities Human admins, service principals, workload identities
Control plane Cloud org structure, IaC pipelines, orchestration API
Connectivity VPN, private links, DNS, certificates
Dependencies CSP regions, IdP, CI/CD SaaS, DNS provider, package registries
Facility dependencies Power, HVAC, carriers (for private/colo)
Identify threats

Use structured sources: STRIDE-style categories, threat intel, historical incidents, insider scenarios, and environmental events. For infrastructure platforms, include both cyber and physical/environmental threats.

Identify vulnerabilities

Weaknesses may be technical (unpatched hypervisor agent, open management port), process (no dual control for DNS changes), people (phishing of cloud admins), or design (single region, shared keys).

Cloud-specific identification questions

What does the CSP guarantee vs what do we configure?

Where are multi-tenant isolation boundaries?

What happens if the management plane identity is stolen?

Which fourth parties (CSP subprocessors, marketplace images) expand the supply chain?

What data residency constraints limit treatment options (e.g., cannot move region freely)?

Document assumptions. Many “unknowns” about provider internals are accepted via assurance reports — that acceptance is itself a risk decision.

Risk Assessment: Analysis

Analysis estimates how serious each risk is so treatment can be prioritized.

Qualitative analysis (common on exams)

Likelihood Impact Priority sketch
High High Treat immediately
High Medium Prioritize mitigations
Medium High Strong controls / contingency
Low High Monitor; consider insurance/transfer; rare but severe
Low Low Accept or routine hygiene

Scales vary (1–5, traffic lights). Consistency matters more than pseudo-precision.

Quantitative flavors (awareness)

Annualized Loss Expectancy (ALE) style thinking appears in broader risk domains: Single Loss Expectancy × Annualized Rate of Occurrence. Cloud metering can improve detection of anomalous usage (cost as a risk signal) even when pure ALE numbers are rough.

Analysis factors unique to cloud platforms

Factor Effect on analysis
Elasticity Impact scales with auto-provisioned capacity and data volume
Abstraction Harder to inspect physical layers; increase reliance on CSP attestations
Shared fate Provider regional outage impacts many customers simultaneously
Configuration volatility Drift raises likelihood of misconfiguration over time
API concentration Single set of credentials may unlock many assets (impact amplifier)
Log completeness If management actions are not logged immutably, impact of incidents rises (detection lag)
Scenario analysis example

Risk: Public object storage misconfiguration exposes regulated data.

Threat actors: Internet scanners, opportunistic attackers.

Vulnerability: Bucket policy allows public GetObject ; block-public-access not enforced at org level.

Likelihood: High (automated scanning).

Impact: High (breach notification, fines, trust).

Inherent risk: Critical.

Existing controls: Encryption at rest (does not stop authorized-anonymous reads of ciphertext when policy allows).

Conclusion: Encryption alone is insufficient treatment; need preventive policy guardrails and detective config monitoring.

This style of reasoning — not memorizing vendor product names — is what CCSP grades.

Cloud Vulnerabilities

A vulnerability is a weakness. Cloud estates combine classical IT weaknesses with cloud-native ones.

Vulnerability class Examples
Identity & access Over-privileged roles, long-lived access keys, missing MFA, weak federation
Misconfiguration Open security groups, public storage, permissive IAM wildcards, disabled logging
Insecure defaults Services left on demo settings; default VPCs with broad routes
Unpatched components Guest OS, container images, agents, customer-managed middleware
Isolation gaps Privileged containers, shared hostPath, weak tenant network controls
Cryptographic weakness Deprecated TLS, poor key storage, dual-purpose keys
API design flaws Broken object-level authorization, SSRF to metadata services
Supply chain Poisoned images, malicious dependencies, compromised build pipeline
Visibility gaps No flow logs, no management-plane audit trail, shadow IT accounts
Physical/environmental Single power path, undiverse fiber, weak visitor control (private/colo)
BMS / OT overlap Facility systems reachable from IT networks

Important distinction: Multi-tenancy is not itself a vulnerability — failure of isolation mechanisms is. Resource pooling is expected; residual side-channel risk may be accepted or mitigated with dedicated hosts for extreme cases.

Vulnerability management in cloud must cover infrastructure as code templates and org policies , not only CVE scans of VMs. A secure image deployed by a template that opens 0.0.0.0/0 to SSH reintroduces critical exposure every apply.

Cloud Threats and Attacks

Threats are the actors or forces that may exploit vulnerabilities. Attacks are concrete actions.

Threat categories for infrastructure/platforms

Threat category Cloud infrastructure examples
External adversaries Credential stuffing against consoles, ransomware via exposed RDP, crypto-mining bots
Insiders (customer) Malicious admin, careless privileged user, third-party contractor

Insiders (CSP) Privileged provider personnel (mitigated by CSP controls, customer encryption, confidential computing)

Competing tenants Escape attempts, noisy neighbor resource exhaustion
Supply chain Compromised provider dependency or customer CI/CD
Environmental Flood, fire, power grid failure, fiber cut
Legal / seizure Lawful access requests in a jurisdiction (risk/compliance overlap)
Representative attacks

Attack Description Primary targets
Account takeover Phish MFA-fatigue, steal API keys, session hijack Management plane
Misconfiguration exploit Discover public storage/DBs/admin ports Storage, compute, network
Privilege escalation Abuse IAM policy flaws, metadata SSRF to steal roles Compute + IAM
Lateral movement Pivot across flat VPC/peering Network partitioning failures

Data exfiltration Copy snapshots cross-account; DNS tunneling; egress to attacker storage Storage, network egress

Destructive attack Mass delete, encryption ransomware on volumes/backups Storage, backups
DDoS Saturate public endpoints or APIs Network edge, app
Cryptojacking Steal compute for mining Compute, Kubernetes
Hypervisor/container escape Break isolation boundary Virtualization
Poisoned image/pipeline Backdoor in base image or IaC module Supply chain, orchestration
Control-plane API abuse Scripted create/destroy at scale Management plane
DNS hijacking Alter records to intercept traffic Communications
Attack chain example (exam-style)

Developer access key committed to public repo ( vulnerability ).

Attacker finds key ( threat actor capability ).

Attacker lists storage, snapshots DB volume, shares snapshot outbound ( attack ).

Impact: confidentiality breach; possible integrity if they modify resources.

Treatment that would have reduced risk: secret scanning, short-lived credentials, deny snapshot share org-wide, mandatory MFA, detection on anomalous CreateSnapshot / ModifySnapshotAttribute .

Map each step to component (3.1) and design gap (3.2) when answering scenario items.

Risk Treatment Strategies

Once risks are analyzed, organizations treat them. CCSP-aligned treatment options match classic information security risk management:

Strategy Meaning Cloud infrastructure examples

Avoid Do not engage in the risky activity Do not store regulated data in unsupported regions; do not enable public anonymous access features at all

Mitigate (modify/reduce) Apply controls to reduce likelihood and/or impact MFA, encryption, segmentation, WAF, immutable backups, patching, org policy guardrails

Transfer Shift financial/contractual impact to another party Cyber insurance; contractually defined CSP liabilities (limited); managed security services

Share Distribute risk among parties Shared responsibility models; consortium/community cloud governance; multi-party controls

Accept Knowingly retain risk within appetite Accept residual CSP insider risk after encryption + legal review; accept rare regional outage risk with documented BC plan

Some frameworks list share under transfer; the CCSP outline family (see also Domain 6 risk treatment) expects you to recognize avoid, mitigate, transfer/share, and accept as the toolkit.

Choosing a strategy

Situation Lean toward
Activity not required for business Avoid
High likelihood, controllable weakness Mitigate
Rare high financial impact, control cost prohibitive alone Transfer (insurance) + mitigate
Shared platform by design Share responsibility + contracts + assure
Residual risk after reasonable controls, within appetite Accept with monitoring

Treatment is not “set and forget.” Residual risk must be monitored — new vulnerabilities, configuration drift, and threat landscape changes can push accepted risk outside appetite.

Treatment vs control confusion

Treatment strategy = risk decision (avoid/mitigate/transfer/accept).

Control = specific measure implementing mitigation (e.g., “enforce MFA on console users”).

Exam stems may ask which strategy was chosen (“the firm decided not to process card data in that SaaS”) = avoid , not “install WAF.”

Layered treatment example

Risk: Regional provider outage.

Mitigate: multi-AZ for localized faults; multi-region active/passive for regional.

Transfer: insurance for business interruption.

Accept: residual simultaneous multi-region failure as extremely unlikely.

Avoid: do not put the only copy of irreplaceable data in a single AZ with no backups.

Shared responsibility as treatment context

You cannot mitigate a risk the contract places solely on the CSP using customer console clicks alone — and you cannot transfer accountability for customer data classification to the CSP by wishing. Effective treatment assigns actions to the party that can implement them and verifies with SLA, SOC reports, configuration evidence, and exercises.

End-to-End Risk Workflow for Domain 3

Scope infrastructure components (3.1) and facility/design choices (3.2).

Identify assets, threats, vulnerabilities, existing controls.

Analyze likelihood and impact; rank risks.

Treat using avoid / mitigate / transfer-share / accept.

Implement controls (Domain 3.4 themes: physical/environmental, system/storage/communication protection, IAM, audit).

Plan BC/DR for risks you mitigate with resiliency rather than pure prevention (Domain 3.5).

Monitor and review — continuous cloud posture management, pen tests where authorized, tabletop exercises.

Prioritization heuristic for CCSP practice

Priority signal Why
Management plane exposure Highest leverage for attackers
Public data access misconfig High likelihood + high impact
Missing immutable backups Ransomware impact amplifier
Flat network + over-privileged identity Lateral movement
Single AZ / single path facility Correlated availability failure
Unvetted images/pipelines Supply chain scale
Metrics that support risk management
Time to revoke compromised credentials
Percentage of resources failing policy-as-code checks
MFA coverage on privileged users
Backup restore success rate
Mean time to detect anomalous API patterns
Patch lag on customer-managed OS/images

Metrics without decisions are vanity; pair them with treatment owners and deadlines.

Common Traps

Treating encryption at rest as complete mitigation for public-read policies.

Accepting risk informally (“we’ll fix later”) without recording residual risk and owner.

Assuming CSP compliance certifications remove customer misconfiguration risk.

Focusing only on CVE scores while ignoring IAM and network exposure.

Calling multi-cloud a full avoid strategy for all provider risk (it can mitigate concentration but increases complexity risk).

Ignoring environmental threats in “cyber-only” cloud assessments for hybrid estates.

Closing Synthesis for Domain 3.1–3.3

3.1 tells you what the infrastructure is.

3.2 tells you how to design facilities and logical isolation for secure, resilient operation.

3.3 tells you how to reason about what can fail and what to do about it .

Master the three together: a CCSP item may describe a container escape fear (virtualization component), ask whether dedicated hosts are justified (design/treatment), and expect you to label residual risk acceptance after mitigations — all in one stem.