FlashGenius Logo FlashGenius
ISC2 CCSP® · Domain 4 · 16% of Exam · August 2026 Outline

CCSP Domain 4: Cloud Application Security

Secure SDLC • Threat Modeling • OWASP • LLM Top-10 (NEW) • API Security • IAM • DevSecOps
100–150 Questions (CAT)
~16 Questions This Domain
700/1000 Passing Score
3-Hour Exam
Pearson VUE

Domain 4: Cloud Application Security & DevSecOps

16% of the August 2026 CCSP exam — approximately 16 scored questions (CAT format)

Applications are where attackers strike. Understanding the secure development lifecycle and modern cloud application security is non-negotiable for CCSP candidates. Domain 4 spans everything from threat modeling and OWASP vulnerability lists to DevSecOps pipelines, IAM federation, and container orchestration. The August 2026 outline adds the OWASP LLM Top-10 and API Security Top-10 explicitly — making AI and API security knowledge testable for the first time.

🆕 What's New in the August 2026 Outline

  • Domain 4 weight decreased from 17% to 16% — one fewer approximate scored question
  • OWASP Top 10 for Large Language Model (LLM) Applications explicitly added to Domain 4.1 — tests AI/cloud application security awareness
  • OWASP API Security Top 10 added alongside existing OWASP Web Top-10 in Domain 4.1
  • Continued emphasis on container security (Docker/Kubernetes), serverless, and supply-chain security
  • New AI/ML subsection 1.6 in Domain 1; new AI/ML data protection 2.9 in Domain 2
  • CAT format since October 2025: adaptive 100–150 questions, 3-hour exam, 700/1000 passing score
Exam At a Glance
DetailInfo
CertificationCCSP — Certified Cloud Security Professional (ISC2)
New Outline EffectiveAugust 1, 2026
Exam FormatComputerized Adaptive Testing (CAT) — since October 2025
Questions100–150 (~25 unscored pretest items)
Duration3 hours
Passing Score700 out of 1000
Testing ProviderPearson VUE
Domains6 domains
CCSP Domain Weights (August 2026)
DomainTopicWeight~Questions
1Cloud Concepts, Architecture & Design17%~17
2Cloud Data Security20%~20
3Cloud Platform & Infrastructure Security17%~17
★ 4Cloud Application Security <this page>16%~16
5Cloud Security Operations17%~17
6Legal, Risk & Compliance13%~13

Note: Domain 4 weight decreased from 17% → 16% in the August 2026 outline. Total = 100%.

Why Domain 4 Matters

Threat Landscape

The majority of successful breaches target application-layer weaknesses — injection flaws, broken authentication, and misconfigured APIs. The CCSP exam tests whether candidates can identify and mitigate these in cloud-native architectures.

AI & LLM Security (NEW 2026)

With LLM applications proliferating across cloud platforms, ISC2 explicitly added the OWASP LLM Top-10 to Domain 4. Candidates must understand prompt injection, training data poisoning, and excessive agency risks.

DevSecOps Shift-Left

Security testing is now embedded in CI/CD pipelines. CCSP candidates must know SAST, DAST, IAST, and SCA and when each applies in the development lifecycle — a core exam theme.

IAM & Zero-Trust Architecture

Federated identity, SSO, CASB, and MFA are foundational to cloud security. Domain 4.7 tests practical knowledge of how these controls are designed and enforced in multi-cloud environments.

Domain 4 Core Concepts

Deep-dive across all 7 subdomains of Domain 4 (August 2026 outline)

4.1 Advocate Training & Awareness for Application Security

Cloud Development Basics & Common Pitfalls

  • Cloud-native risks differ from on-premises: shared infrastructure, multi-tenancy, API-first architectures
  • Common pitfalls: insecure defaults, over-privileged service accounts, hardcoded secrets in code
  • Missing input validation, unauthenticated APIs, excessive data exposure
  • Developers must understand shared responsibility — CSP secures the platform; customer secures the application

OWASP Top-10 Web Application Security Risks

  • #1 Broken Access Control
  • #2 Cryptographic Failures
  • #3 Injection (SQL, XSS, etc.)
  • #4 Insecure Design
  • #5 Security Misconfiguration
  • #6 Vulnerable & Outdated Components
  • #7 Identification & Authentication Failures
  • #8 Software & Data Integrity Failures
  • #9 Security Logging & Monitoring Failures
  • #10 Server-Side Request Forgery (SSRF)

OWASP API Security Top-10 2026

  • API1 Broken Object Level Authorization (BOLA/IDOR)
  • API2 Broken Authentication
  • API3 Broken Object Property Level Auth
  • API4 Unrestricted Resource Consumption
  • API5 Broken Function Level Authorization
  • API6 Unrestricted Access to Sensitive Business Flows
  • API7 Server-Side Request Forgery (SSRF)
  • API8 Security Misconfiguration
  • API9 Improper Inventory Management
  • API10 Unsafe Consumption of APIs

🆕 OWASP Top-10 for LLM Applications (NEW in August 2026 Outline)

  • LLM01 Prompt Injection
  • LLM02 Insecure Output Handling
  • LLM03 Training Data Poisoning
  • LLM04 Model Denial of Service
  • LLM05 Supply Chain Vulnerabilities
  • LLM06 Sensitive Information Disclosure
  • LLM07 Insecure Plugin Design
  • LLM08 Excessive Agency
  • LLM09 Overreliance
  • LLM10 Model Theft

LLM01 Prompt Injection is the highest-priority risk: attackers manipulate LLM inputs to override system instructions or exfiltrate data. LLM08 Excessive Agency occurs when an LLM can take actions beyond what is necessary, amplifying any compromise.

SANS Top-25 Most Dangerous Software Errors

  • Published by SANS/CWE — covers most dangerous CWEs (Common Weakness Enumerations)
  • Examples: buffer overflow (CWE-119), SQL injection (CWE-89), XSS (CWE-79), path traversal (CWE-22)
  • Used to prioritize secure coding practices and code review checklists
  • Complements OWASP Web Top-10; SANS focuses on root-cause CWEs, OWASP on risk categories
4.2 Describe the Secure SDLC Process

SDLC Phases & Methodologies

  • Business requirements: security requirements gathered alongside functional requirements — "security by design"
  • Waterfall SDLC: linear phases — Requirements → Design → Implementation → Testing → Deployment → Maintenance
  • Agile: iterative sprints; security controls integrated per sprint, not at the end
  • DevSecOps: security automated in CI/CD pipeline; shift-left means detecting issues early (design/code phase) when they are cheapest to fix
  • Rule of 10: fixing a defect in production costs ~10× more than fixing it in design — drives shift-left adoption
MethodologyCadenceSecurity Integration
WaterfallSequential, single releaseSecurity testing at end (penetration test gate)
AgileIterative sprints (2–4 weeks)Security requirements in each sprint; threat model per feature
DevSecOpsContinuous deliverySAST/DAST/SCA automated in CI/CD; security as code
4.3 Apply the Secure SDLC

Threat Modeling Methodologies

  • STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — identifies threat categories per component
  • DREAD: Damage, Reproducibility, Exploitability, Affected Users, Discoverability — numeric risk scoring model; higher score = higher priority
  • ATASM: Architecture, Threats, Attack Surfaces, Mitigations — focuses on reducing attack surface
  • PASTA: Process for Attack Simulation and Threat Analysis — 7-stage risk-centric model aligned to business objectives
  • PASTA 7 stages: Define objectives → Define technical scope → Decompose application → Analyze threats → Identify vulnerabilities → Enumerate attack scenarios → Risk/impact analysis

Cloud-Specific Risks & Secure Coding

  • Cloud-specific SDLC risks: shared technology issues, CSP insider threats, lack of visibility/control, legal and jurisdiction issues
  • Input validation: whitelist permitted input; reject anything that doesn't conform
  • Parameterized queries: prevent SQL injection by separating SQL code from user data
  • Output encoding: prevent XSS by encoding data before rendering in HTML
  • OWASP ASVS (Application Security Verification Standard): defines security requirements for web applications at three levels (L1–L3)
  • SAFECode: industry best-practice secure coding guidelines
  • Software Configuration Management (CM): version control (Git), change tracking, rollback capability; prevents unauthorized code changes
4.4 Apply Cloud Software Assurance & Validation

Security Testing Methodologies

MethodKnowledgeWhen UsedFinds
BlackboxNo internal knowledgeExternal pen test, user acceptanceExternally visible vulnerabilities
WhiteboxFull source code accessInternal code review, auditLogic flaws, hidden back doors
SASTSource code (static)CI/CD pipeline — before buildCode-level flaws without running app
DASTRunning app (dynamic)CI/CD pipeline — staging/testRuntime issues, auth failures, injection
IASTAgent inside running appQA environmentHybrid of SAST + DAST; real-time
SCADependency manifestCI/CD — on every buildVulnerable open-source components (CVEs)
  • Abuse case testing: deliberate attempts to misuse application functionality — opposite of use case testing; identifies trust boundary violations
  • Quality Assurance (QA): acceptance criteria gates, regression testing; security must be a QA criterion, not an afterthought
4.5 Use Verified Secure Software

Securing APIs

  • Authentication mechanisms: OAuth 2.0 (delegated auth), API keys, JWT (JSON Web Tokens)
  • Rate limiting: prevents abuse and API4 (Unrestricted Resource Consumption)
  • Input and schema validation: enforce expected data types and formats at the API gateway layer
  • API Gateway: centralized management of API auth enforcement, rate limiting, logging, and traffic routing
  • Avoid exposing internal implementation details in API responses (prevents information disclosure)

Supply-Chain & Third-Party Software Management

  • SBOM (Software Bill of Materials): inventory of all software components; enables rapid response to CVE disclosures
  • Code signing: cryptographic verification that code has not been tampered with in transit or at rest
  • Vendor assessment: evaluate third-party security posture before integrating their libraries or services
  • Patch management: monitor CVE databases; end-of-life tracking for dependencies
  • OWASP Dependency-Check: open-source SCA tool that identifies known vulnerable libraries
  • Integrity verification: hash checking (SHA-256) ensures downloaded packages match vendor-published checksums
4.6 Comprehend & Apply Cloud Application Architecture

Supplemental Security Components

ComponentPurposeKey Capability
WAFWeb Application FirewallFilters HTTP/HTTPS traffic; blocks OWASP Top-10 attacks at Layer 7
DAMDatabase Activity MonitoringMonitors SQL queries; detects unauthorized access and SQL injection
XML FirewallXML/SOAP Message ValidationValidates XML schema; protects SOAP web services from malformed messages
API GatewayCentralized API ManagementAuth enforcement, rate limiting, logging, transformation, routing
Load BalancerTraffic DistributionDDoS mitigation, SSL termination, health checks, horizontal scaling
  • Sandboxing: isolated execution environment for untrusted or potentially malicious code
  • Application-layer cryptography: TLS for data in transit, certificate management, cipher suite hardening

Containers, Microservices & Serverless

  • Docker: containerization platform; images must be scanned for vulnerabilities; use minimal base images
  • Kubernetes: container orchestration; namespaces provide logical isolation; network policies control pod-to-pod traffic
  • Container security practices: immutable containers, run as non-root, read-only filesystems, limit capabilities
  • Microservices: loosely coupled services; each exposes APIs; zero-trust between services (mTLS)
  • Serverless: function-based execution; attack surface is the trigger/event input; still vulnerable to injection and over-permission
  • Supply chain attacks target container image registries — always verify image signatures (Notary, cosign)
4.7 Design Appropriate IAM Solutions

Identity & Access Management

ConceptDescriptionProtocol/Tool
Federated IdentityTrust relationship between IdP and service provider; users authenticate once to the IdPSAML 2.0, OIDC
Identity Provider (IdP)Central authority that authenticates users and issues tokens/assertionsOkta, Azure AD, Auth0
SSOSingle Sign-On: one authentication grants access to multiple applicationsSAML 2.0, OIDC/OAuth 2.0
MFAMulti-Factor Authentication: something you know + have + areTOTP, FIDO2/WebAuthn
CASBCloud Access Security Broker: enforces security policies between users and CSPsMicrosoft Defender for Cloud Apps, Netskope
  • CASB functions: shadow IT discovery, DLP enforcement, malware detection, compliance monitoring — sits inline or API-connected between users and cloud apps
  • Secrets management: HashiCorp Vault, AWS Secrets Manager — centralized, rotation-enabled, least-privilege access to credentials
  • SAML 2.0: XML-based assertions for enterprise SSO (IdP-initiated or SP-initiated flows)
  • OIDC (OpenID Connect): identity layer on top of OAuth 2.0; issues ID tokens (JWT); used in modern web/mobile apps
  • Key management: HSMs for key protection, automated rotation, envelope encryption patterns

Memory Hooks

Six mnemonics to lock in Domain 4 concepts before exam day

1. STRIDE Threat Model — "Students Taking Rides In Dark Elevators"

Spoofing — impersonating another user or system
Tampering — modifying data or code without authorization
Repudiation — denying an action occurred (no audit trail)
Information Disclosure — unauthorized data exposure
Denial of Service — making a resource unavailable
Elevation of Privilege — gaining unauthorized higher-level access

"Students Taking Rides In Dark Elevators"

2. SAST vs. DAST vs. IAST — "Read, Run, Ride-Along"

SAST (Static) — reads the source code without running it; catches issues early in CI/CD
DAST (Dynamic) — runs the application and attacks it like an outsider; finds runtime issues
IAST (Interactive) — rides along inside the running app via instrumentation agents; hybrid approach

SCA (Software Composition Analysis) scans dependency manifests for known CVEs — use it on every build.

"Read the code (SAST) → Run the app (DAST) → Ride inside it (IAST)"

3. OWASP LLM Top Threats (NEW 2026) — "PIE on the LLM Menu with DoS Sauce"

The highest-priority LLM risks: Prompt Injection (LLM01), Insecure Output Handling (LLM02), training data Errors/Poisoning (LLM03), and Model DoS (LLM04).

LLM01 Prompt Injection is the #1 risk: attacker injects instructions into the prompt to override system behavior. LLM08 Excessive Agency means the model is given too much autonomy — it can take damaging actions if compromised.

"PIE on the LLM menu with DoS sauce" — Prompt Injection, Insecure Output, Data Poisoning, DoS

4. CASB = "The TSA of Cloud"

A CASB (Cloud Access Security Broker) sits between users and cloud applications — just like TSA sits between travelers and the aircraft. It inspects traffic, enforces policy, discovers shadow IT (unauthorized apps employees use), and prevents data leakage.

CASB deployment modes: API-based (out-of-band, discovers shadow IT post-facto) and inline/proxy (real-time enforcement, can block).

"CASB is the TSA of cloud — it checks every bag before boarding"

5. WAF vs. API Gateway — "WAF Guards the Wall, Gateway Guards the Door"

WAF (Web Application Firewall) is a Layer 7 firewall that inspects HTTP/HTTPS traffic and blocks common attacks (OWASP Top-10). It's the wall around the application.

API Gateway manages API routing, authentication enforcement, rate limiting, and logging. It's the intelligent door that decides who gets in and what they're allowed to request.

"WAF guards the wall (blocks bad HTTP), Gateway guards the door (routes and authenticates)"

6. PASTA = "7-Stage Process" — "PASTA Takes 7 Bites"

PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric threat modeling framework in 7 stages:

1. Define business objectives → 2. Define technical scope → 3. Decompose application → 4. Analyze threats → 5. Identify vulnerabilities → 6. Enumerate attack scenarios → 7. Risk & impact analysis

Unlike STRIDE (which categorizes threats per component), PASTA links threats back to business risk impact — making it more executive-friendly.

"PASTA takes 7 bites — always ends with Risk & Impact"

Knowledge Check

10 vignette-style scenario questions — Domain 4: Cloud Application Security

Question 1 of 10
Question 1 of 10
A developer's LLM-powered customer service application accepts user-supplied chat prompts. During testing, a security researcher finds they can insert instructions that override the system prompt and cause the model to reveal confidential internal documentation. Which OWASP LLM Top-10 risk does this represent?
A LLM03 — Training Data Poisoning
B LLM08 — Excessive Agency
C LLM01 — Prompt Injection
D LLM06 — Sensitive Information Disclosure
Question 2 of 10
A security engineer configures the CI/CD pipeline so that every code commit triggers an automated tool that analyzes the application's source code for vulnerabilities before the build artifact is produced — without executing the code. Which type of security testing is being used?
A DAST — Dynamic Application Security Testing
B SAST — Static Application Security Testing
C IAST — Interactive Application Security Testing
D SCA — Software Composition Analysis
Question 3 of 10
An organization deploys a tool that analyzes DNS and proxy logs to identify cloud file-sharing and collaboration services that employees are using without IT approval. The security team uses this to enforce data loss prevention policies against unauthorized apps. Which security function is described?
A API Gateway rate limiting
B WAF inline traffic inspection
C Federated Identity Provider enforcement
D CASB shadow IT discovery and DLP enforcement
Question 4 of 10
A company configures SSO so that employees authenticate once to their corporate Identity Provider and are automatically granted access to multiple SaaS cloud applications without re-entering credentials. The SSO assertion is transmitted as a signed XML document between the IdP and each service provider. Which federation protocol is in use?
A OAuth 2.0
B SAML 2.0
C OpenID Connect (OIDC)
D Kerberos
Question 5 of 10
A penetration tester sends a specially crafted SOAP message with an excessively large XML payload to a cloud-hosted web service, causing the service to crash and become unavailable. Which supplemental security component would BEST have prevented this attack by validating message structure before processing?
A Web Application Firewall (WAF)
B Database Activity Monitor (DAM)
C XML Firewall
D Load Balancer
Question 6 of 10
A security team discovers that an open-source logging library used across 14 microservices has a critical unauthenticated remote code execution CVE. The team needs to quickly identify all services consuming this specific version of the library. Which supply-chain security control enables this rapid identification?
A SAST scanning of all repositories
B Abuse case testing results
C SBOM (Software Bill of Materials) and SCA tooling
D API Gateway access logs
Question 7 of 10
During a threat modeling session, the security architect assigns numerical scores to each identified threat based on potential damage, how easily the attack can be reproduced, exploitability level, how many users are affected, and how discoverable the vulnerability is. Which threat modeling technique is being applied?
A STRIDE
B DREAD
C PASTA
D ATASM
Question 8 of 10
A cloud-hosted REST API returns full order records to any authenticated user who provides an order ID in the URL path (e.g., GET /api/orders/12345). The application does not verify that the requesting user actually owns order 12345. Which OWASP API Security risk does this represent?
A API2 — Broken Authentication
B API5 — Broken Function Level Authorization
C API1 — Broken Object Level Authorization (BOLA)
D API8 — Security Misconfiguration
Question 9 of 10
A DevSecOps engineer wants to ensure that microservices belonging to different business units running on the same Kubernetes cluster cannot communicate with each other unless explicitly permitted, and each team's pods are logically segmented. Which Kubernetes mechanisms BEST address this requirement?
A Docker image scanning and SBOM generation
B Kubernetes namespaces combined with Network Policies
C Role-Based Access Control (RBAC) applied at the API gateway
D WAF rules applied to ingress controllers
Question 10 of 10
A QA lead asks the security team to develop test cases specifically designed to deliberately misuse the application's password reset feature — for example, resetting another user's password without authorization, flooding reset emails, or bypassing the token expiration. What type of testing is this?
A Regression testing
B Abuse case testing
C Whitebox penetration testing
D DAST scanning
0/10

Quiz Complete!

Review the concepts above and try again.

Flashcards

Click any card to flip it — 8 key Domain 4 concepts

STRIDE Threat Model

Click to reveal

Spoofing • Tampering • Repudiation • Information Disclosure • Denial of Service • Elevation of Privilege

Mnemonic: "Students Taking Rides In Dark Elevators"

Used during design phase to identify threats per component/trust boundary.

SAST vs. DAST

Click to reveal

SAST: Static — analyzes source code without running it; finds issues before build; "shift-left."

DAST: Dynamic — tests the running application externally; finds runtime issues, auth failures, injection.

IAST: agents inside running app — hybrid of both; real-time instrumentation.

LLM01 — Prompt Injection NEW

Click to reveal

Attacker crafts input that overrides or manipulates the LLM's system prompt, causing it to ignore safety instructions, leak data, or take unauthorized actions.

Direct: user prompt overrides system prompt.
Indirect: malicious content in retrieved documents hijacks the model.

Mitigation: input sanitization, privilege separation, output validation.

CASB

Click to reveal

Cloud Access Security Broker

Sits between users and cloud services. Enforces security policy in real-time.

Key functions: Shadow IT discovery, DLP enforcement, malware detection, compliance monitoring, access control.

Modes: API-connected (discovery) or inline/proxy (enforcement).

SCA — Software Composition Analysis

Click to reveal

Scans dependency manifests to identify open-source components with known CVEs.

Tools: OWASP Dependency-Check, Snyk, Black Duck.

Output feeds the SBOM (Software Bill of Materials) — inventory of all software components enabling rapid CVE response.

Run on every CI/CD build — blocks vulnerable libraries from entering production.

BOLA — Broken Object Level Authorization

Click to reveal

API1 in OWASP API Security Top-10

Also called IDOR (Insecure Direct Object Reference).

API returns data for any object ID without verifying the requester owns or is authorized to access it.

Fix: enforce authorization checks server-side for every API endpoint — never trust client-supplied IDs alone.

WAF — Web Application Firewall

Click to reveal

Layer 7 (application-layer) firewall that inspects and filters HTTP/HTTPS traffic.

Blocks OWASP Top-10 attacks: SQL injection, XSS, SSRF, broken access control attempts.

Deployed inline (reverse proxy) or as a cloud-native service (AWS WAF, Azure WAF).

WAF ≠ API Gateway: WAF blocks bad traffic; API Gateway routes and authenticates API calls.

Federated Identity

Click to reveal

Trust relationship between an Identity Provider (IdP) and Service Providers (SPs).

SAML 2.0: XML-based assertions; enterprise SSO; IdP issues signed assertion to SP.
OIDC: identity layer on OAuth 2.0; JWT ID tokens; used in mobile/web apps.

Enables SSO across multiple cloud applications without re-authentication.

Study Advisor

Track your readiness across the 5 key Domain 4 topic areas

Domain 4 Readiness Tracker

1. SDLC Phases & Threat Modeling (4.2, 4.3)

Know all four threat modeling frameworks (STRIDE, DREAD, PASTA, ATASM) and when each applies. PASTA is risk-centric and business-aligned; STRIDE categorizes by threat type; DREAD gives numeric priority scores. Understand the difference between Waterfall, Agile, and DevSecOps security integration patterns.

  • STRIDE — categorizes threats per component in design phase
  • DREAD — numerically scores risk to prioritize remediation
  • PASTA — 7-stage, links threats to business impact (executive-friendly)
  • Shift-left: finding defects earlier is exponentially cheaper
  • OWASP ASVS defines verification requirements at 3 levels (L1 basic → L3 high assurance)

2. Security Testing: SAST, DAST, IAST, SCA (4.4)

The exam loves distinguishing these four testing methods. Master the "when in the pipeline" aspect: SAST and SCA run before build; DAST runs against a deployed test instance; IAST instruments a running app in QA. Abuse case testing is the deliberate-misuse counterpart to use case testing.

  • SAST: static, pre-build, no execution — finds code-level flaws
  • DAST: dynamic, post-deployment test env — finds runtime & auth flaws
  • IAST: instrumented agent inside running app — real-time hybrid
  • SCA: dependency CVE scanning — runs every build; powers SBOM
  • Abuse case testing: deliberate misuse scenarios; tests trust boundary violations

3. API Security & Supply Chain (4.5)

BOLA (Broken Object Level Authorization) is the #1 API risk — understand it deeply. Know OAuth 2.0 vs. SAML 2.0 vs. OIDC for API auth. SBOMs, code signing, and dependency scanning are the supply chain controls. Rate limiting prevents API4 (resource consumption) attacks.

  • BOLA: API returns data without ownership check — most common API flaw
  • OAuth 2.0: delegated authorization (not authentication by itself)
  • OIDC: adds identity (ID tokens via JWT) on top of OAuth 2.0
  • SBOM: inventory of all components; critical for rapid CVE response
  • Hash verification (SHA-256) confirms package integrity at download

4. Cloud App Architecture: WAF, CASB, Containers, K8s (4.6, 4.7)

Know the distinction between WAF (Layer 7 traffic filter) and API Gateway (routing + auth management). CASB modes: API-connected discovery vs. inline enforcement. For containers, understand Kubernetes namespaces + network policies for isolation, and image signing for supply chain. CASB is the primary control for shadow IT.

  • WAF: blocks OWASP Web Top-10 at Layer 7
  • DAM: monitors database queries; detects unauthorized access
  • XML Firewall: validates SOAP/XML messages (prevents XXE, message flooding)
  • K8s namespaces + NetworkPolicy: logical isolation between workloads
  • CASB inline mode: real-time DLP enforcement; API mode: shadow IT discovery

5. OWASP LLM Top-10 & API Top-10 (4.1 — NEW 2026) 2026

This is the newest testable content in the August 2026 outline. Focus on LLM01 (Prompt Injection — most critical), LLM03 (Training Data Poisoning), LLM08 (Excessive Agency), and LLM04 (Model DoS). For API security, BOLA (API1) is the top risk. Know these by number for the exam.

  • LLM01 Prompt Injection: input overrides system prompt — most critical LLM risk
  • LLM03 Training Data Poisoning: attacker corrupts training data to bias model output
  • LLM08 Excessive Agency: model given too much autonomy — amplifies any compromise
  • LLM04 Model DoS: overloading model with complex prompts to exhaust resources
  • API1 BOLA and API2 Broken Auth are the top two API security priorities

Official Resources

Authoritative links for CCSP Domain 4 exam preparation

Domain 4 Exam At a Glance

DetailInfo
Domain Weight16% (~16 scored questions)
Subdomain Count7 subdomains (4.1–4.7)
Key NEW Topics (2026)OWASP LLM Top-10, OWASP API Security Top-10
High-Frequency TopicsSTRIDE, SAST/DAST/IAST, CASB, BOLA, Federated Identity, DevSecOps
Passing Score700 / 1000
Exam FormatCAT — 100–150 questions, 3 hours, Pearson VUE
New Outline EffectiveAugust 1, 2026
Official URLisc2.org/certifications/ccsp

Start Your CCSP Journey

FlashGenius offers interactive study guides, scenario-based quiz questions, and memory-optimized flashcards for all 6 CCSP domains. Build a consistent daily practice and arrive at the exam confident.

Start Free at FlashGenius
FlashGenius

Ace the CCSP with smarter study tools

Interactive guides, scenario quizzes, and flashcards for all 6 CCSP domains

Start Free Official CCSP Page