Courseiva
mediumMultiple Select

CCSP Practice Question: A cloud security team is implementing a DevSecOps…

A cloud security team is implementing a DevSecOps pipeline. Which TWO of the following are examples of shift-left security practices? (Select two.)

⚠ Common exam trap

CCSP often tests whether candidates can distinguish 'shift-left' (pre-deployment, code/IaC analysis) from 'shift-right' (runtime, production monitoring) — DAST and RASP are the classic distractors.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Scanning Infrastructure as Code with Checkov before deployment

Shift-left security means moving security activities earlier in the software development lifecycle, before code reaches production. Option B is correct because scanning Infrastructure as Code with Checkov before deployment catches misconfigurations in Terraform, CloudFormation, or Kubernetes manifests at the earliest possible stage, preventing insecure infrastructure from ever being provisioned. Option D is correct because running SAST during code commit analyzes source code for vulnerabilities like injection flaws or insecure patterns as developers write it, giving immediate feedback before the code is merged or built. Option A is not shift-left because penetration testing after deployment is a late-stage, post-release activity. Option C is not shift-left because DAST tests a running application, which occurs after the code is deployed to a test or staging environment. Option E is not shift-left because RASP operates at runtime in production, protecting the application only after it is live.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Conducting penetration testing after deployment

    Why it's wrong here

    Penetration testing after deployment validates a live environment, placing it at the right of the lifecycle rather than the left. It is tempting because it is a security activity within DevSecOps, but shift-left requires controls embedded at coding and build stages, such as SAST or software composition analysis.

  • ✓

    Scanning Infrastructure as Code with Checkov before deployment

    Why this is correct

    Scanning Infrastructure as Code with Checkov before deployment catches misconfigurations at the source, satisfying the shift-left requirement to detect flaws before resources reach production. Checkov statically analyses Terraform, CloudFormation and Kubernetes manifests, so defects are remediated in version control rather than after provisioning, when fixes cost more and expose live environments.

  • ✗

    Performing Dynamic Application Security Testing (DAST) on a running application

    Why it's wrong here

    DAST executes against a running application, so it occurs after code is deployed rather than earlier in the lifecycle. It is tempting because automated testing is central to DevSecOps, but DAST belongs to later pipeline stages, whereas shift-left means SAST, dependency scanning or secrets detection at commit.

  • ✓

    Running Static Application Security Testing (SAST) during code commit

    Why this is correct

    SAST scans source code at commit time, before artefacts are built or deployed, so vulnerabilities surface while remediation is cheapest. This satisfies the shift-left constraint by moving detection into the earliest pipeline stage, unlike DAST or runtime controls that require a running application.

  • ✗

    Implementing Runtime Application Self-Protection (RASP) in production

    Why it's wrong here

    RASP instruments a running production application to block attacks at execution time, which is runtime protection, not shift-left. It is tempting because it is a genuine DevSecOps security control, but shift-left means detecting flaws earlier, during coding or build, via SAST or dependency scanning.

Visual reference

Client DHCP Server 1 Discover (broadcast) 2 Offer (IP: 192.168.1.10) 3 Request (I accept) 4 Acknowledge (lease confirmed) DORA — the four-step DHCP lease process

About these practice questions

This CCSP question is part of Courseiva's 934-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official ISC2 exam blueprint

This CCSP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CCSP exam.