Top 30 Cicd Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   Which statement accurately describes the risk to an unpatched, publicly accessible self-managed GitLab instance?

   • aIt can only be exploited after full vulnerability details are published in 30 days
   • bIt is vulnerable to an unauthenticated DoS attack against the Grape API JSON parsing middleware
   • cIt is only vulnerable if running GitLab Enterprise Edition, since Community Edition was not patched
   • dIt requires no immediate action because GitLab.com and Dedicated are already patched
   Show the answer

   Answer: b · It is vulnerable to an unauthenticated DoS attack against the Grape API JSON parsing middleware

   The card states CVE-2026-7250 allows unauthenticated attackers to crash the Grape API JSON parsing middleware and explicitly warns that this DoS vector is exposed to the open internet. Option D is a tempting distractor because GitLab.com and Dedicated being patched does not protect self-managed instances, which must upgrade immediately.

   Read the full bite: GitLab patches 13 CVEs including SAML account takeover flaw

2. Question 2 of 30

   What key characteristic separates Infrastructure as Code from traditional imperative server scripting?

   • aIaC executes configuration steps sequentially each time a deployment runs
   • bIaC files are written in JSON or YAML rather than Bash or PowerShell
   • cIaC requires manual approval through ticketing systems before any changes apply
   • dIaC defines the desired end state and achieves idempotence through automated reconciliation
   Show the answer

   Answer: d · IaC defines the desired end state and achieves idempotence through automated reconciliation

   True IaC is defined by its declarative, idempotent model that lets the platform reconcile to a desired state, not by the file format used. While IaC definitions are often written in JSON or YAML, simply using those formats without declarative idempotence is still just scripting.

   Read the full bite: What is Infrastructure as Code (IaC), and how does it support CI/CD?

3. Question 3 of 30

   What is the primary reason to avoid rebasing a branch that other developers have already pulled?

   • aIt will make the project history less linear and harder to follow.
   • bIt prevents the final merge into the main branch from being a simple fast-forward.
   • cIt rewrites history, forcing teammates into complex manual repository fixes due to conflicting histories.
   • dIt will create numerous merge conflicts that are difficult to resolve.
   Show the answer

   Answer: c · It rewrites history, forcing teammates into complex manual repository fixes due to conflicting histories.

   The card explicitly states that rebasing a shared branch rewrites its history, causing conflicts with teammates' local histories and forcing them into complex manual fixes. This is the 'absolute rule' for when not to use it. Distractor B is incorrect because rebase aims to create a more linear history.

   Read the full bite: Git Rebase: Rewriting History for a Cleaner Timeline

4. Question 4 of 30

   Which property of annotated tags makes them the correct choice for production release markers?

   • aThey automatically advance to the latest commit when the branch is merged forward.
   • bThey are simple refs that do not consume extra storage in the Git database.
   • cThey point directly to a commit without needing an intermediate object.
   • dThey include tagger identity, timestamps, and optional GPG signatures for verification.
   Show the answer

   Answer: d · They include tagger identity, timestamps, and optional GPG signatures for verification.

   Annotated tags are full objects containing tagger identity, timestamps, and optional GPG signatures, providing the audit trail required for production releases. Option B incorrectly assigns the properties of lightweight tags to annotated tags; lightweight tags are merely simple refs that lack metadata and auditability.

   Read the full bite: Git Tags: Immutable Milestones for Release History

5. Question 5 of 30

   When is git cherry-pick the most appropriate Git command to use?

   • aTo reorder and consolidate multiple commits on a local branch before pushing them.
   • bTo permanently remove a commit from a branch's history after it has been pushed.
   • cTo combine all new features from a completed feature branch into the main development line.
   • dTo apply a specific bug fix from a development branch to a stable release branch without including other changes.
   Show the answer

   Answer: d · To apply a specific bug fix from a development branch to a stable release branch without including other changes.

   The card states that cherry-pick is for "backporting a bug fix without merging an entire feature branch" and for applying "a single bug fix... without all the other new, unstable features." Option C describes a standard git merge operation, not cherry-pick.

   Read the full bite: Git Cherry-Pick: Copy a Commit to Another Branch

6. Question 6 of 30

   When first adding SAST to an existing CI pipeline, which rollout strategy best prevents alert fatigue while still shifting security left?

   • aRun SAST only on the main branch during nightly builds to keep merge request pipelines fast, reviewing findings before the next release
   • bStart in audit-only mode, tune rulesets to suppress false positives, and introduce merge-blocking gates for high and critical findings only after a calibration period
   • cBlock all merge requests on any SAST warning from day one, then gradually relax rules as developers request exceptions
   • dRequire the security team to manually triage every SAST finding in merge requests before developers can merge code
   Show the answer

   Answer: b · Start in audit-only mode, tune rulesets to suppress false positives, and introduce merge-blocking gates for high and critical findings only after a calibration period

   Starting in audit-only mode lets the team measure true positive rates and tune out noise before enforcing anything, which builds trust and avoids the alert fatigue that comes from blocking merges prematurely. Option C is a common trap because zero-tolerance blocking on day one creates toil and incentivizes developers to bypass the gate entirely.

   Read the full bite: How would you integrate SAST into CI without alert fatigue?

7. Question 7 of 30

   In a hybrid Docker tagging strategy, what distinguishes the role of a Git SHA tag from a SemVer tag at production deployment time?

   • aThe Git SHA tag is safe to use as a rolling production target, while SemVer tags must be pinned to prevent drift.
   • bThe Git SHA tag is applied only after promotion gates pass, whereas SemVer tags are generated automatically on every CI build.
   • cThe Git SHA tag serves as a mutable alias for changelog consumers, while SemVer acts as the immutable canonical reference.
   • dThe Git SHA tag provides an immutable source-to-artifact mapping used in deployment manifests, while SemVer offers human-readable labels for promoted releases.
   Show the answer

   Answer: d · The Git SHA tag provides an immutable source-to-artifact mapping used in deployment manifests, while SemVer offers human-readable labels for promoted releases.

   Git SHA tags are immutable pointers created on every build to provide exact source-to-artifact traceability in manifests, while SemVer tags are human-readable aliases added only to promoted releases. Distractor C reverses this workflow: SHA tags are generated automatically per build, and SemVer is reserved for promoted images.

   Read the full bite: How do you version Docker images: Git SHA or SemVer?

8. Question 8 of 30

   What makes a vulnerability scan an actual deploy gate rather than just a report?

   • aEmailing the results to the security team
   • bScanning the image after it reaches production
   • cConfiguring the scan step to exit non-zero on findings above a severity threshold so the pipeline fails
   • dRunning the scanner with verbose logging enabled
   Show the answer

   Answer: c · Configuring the scan step to exit non-zero on findings above a severity threshold so the pipeline fails

   A gate must block promotion; a non-zero exit fails the pipeline and stops the build. Reports or emails (A, C) are advisory, and post-deploy scanning (B) is too late to gate.

   Read the full bite: Vulnerability scanning as a deploy gate

9. Question 9 of 30

   When an arm64 node pulls a multi-arch image by tag, what does the registry ultimately return?

   • aThe matching architecture-specific manifest so only relevant layers are fetched
   • bA single manifest whose layers contain binaries for every architecture
   • cThe manifest list containing descriptors for all supported platforms
   • dAll per-architecture layer blobs bundled in one combined download
   Show the answer

   Answer: a · The matching architecture-specific manifest so only relevant layers are fetched

   The card states that after platform content negotiation via headers, the registry returns the matching manifest from the index, not the entire index or a monolithic bundle. While the tag resolves to a manifest list, the node only fetches the manifest and layers for its own architecture.

   Read the full bite: How do you manage multi-arch container images under a single tag?

10. Question 10 of 30

    When starting a new project with typical build, test, and deploy stages, why should Declarative Pipeline be the default choice?

    • aIt standardizes structure and readability while still permitting Groovy inside a script block.
    • bIt is required to use built-in steps like sh and docker.build.
    • cIt offers unrestricted Groovy flow control for complex logic at the top level.
    • dIt removes all code-size limits that restrict pipeline growth.
    Show the answer

    Answer: a · It standardizes structure and readability while still permitting Groovy inside a script block.

    Declarative is the recommended default because its enforced structure improves team readability and onboarding, and it still allows Groovy inside a script block. Option C actually describes Scripted Pipeline, which sacrifices those guardrails and is unnecessary for typical CI/CD workflows.

    Read the full bite: Declarative vs scripted pipeline syntax: when to choose each?

11. Question 11 of 30

    When converting a linear Jenkinsfile into a concurrent Declarative Pipeline, which practice best distributes workload without breaking dependencies?

    • aMap which stages are independent, wrap them in a parallel block with stage-level agents, and keep the Jenkinsfile under version control.
    • bWrap every post-build stage in a matrix block so each task runs concurrently across multiple browser versions.
    • cExtract each independent stage into its own standalone Jenkins job and use the build step to trigger them in parallel.
    • dPlace all test and scan stages into a parallel block and rely on the top-level agent to provision enough executors.
    Show the answer

    Answer: a · Map which stages are independent, wrap them in a parallel block with stage-level agents, and keep the Jenkinsfile under version control.

    Grouping only independent stages in a Declarative parallel block with stage-level agents spreads work across nodes while preserving required ordering for stages like compile or package. Relying on a top-level agent alone is wrong because parallel branches can still contend on a single executor without explicit per-stage agent allocation.

    Read the full bite: How would you use PaC to introduce pipeline parallelism?

12. Question 12 of 30

    What is the primary goal of conducting software performance testing?

    • aTo identify and fix logical errors or bugs within the application's code.
    • bTo ensure the software is secure against external threats and unauthorized data access.
    • cTo confirm that all features and functionalities of the software operate as intended.
    • dTo evaluate the system's stability, responsiveness, and resource utilization under anticipated and extreme user loads.
    Show the answer

    Answer: d · To evaluate the system's stability, responsiveness, and resource utilization under anticipated and extreme user loads.

    Performance testing specifically aims to understand how a system behaves under various loads, measuring its stability, responsiveness, and resource usage to find breaking points. Options A, B, and C describe functional testing, security testing, and general bug fixing, respectively, which are distinct from performance evaluation under load.

    Read the full bite: Software Performance Testing: How a System Behaves Under Stress

13. Question 13 of 30

    What is the primary security advantage of a secrets management system that dynamically injects short-lived credentials?

    • aIt centralizes all sensitive configuration, simplifying auditing and access control.
    • bIt drastically limits the duration and scope of a credential's validity, reducing compromise impact.
    • cIt ensures that secrets are always encrypted when stored and transmitted by the vault.
    • dIt removes the requirement for applications to authenticate themselves to any external service.
    Show the answer

    Answer: b · It drastically limits the duration and scope of a credential's validity, reducing compromise impact.

    The card emphasizes that secrets should be temporary and replaceable, and that a key expires, minimizing the window of opportunity for an attacker. Dynamically injecting short-lived, scoped credentials directly achieves this by limiting how long and where a secret can be used, thus reducing the potential damage if it's compromised. While centralization (A) and encryption (C) are important aspects of a secure secrets management system, they are not the primary security advantage derived specifically from the dynamic injection of *short-lived* credentials.

    Read the full bite: Secrets Management: Beyond Environment Variables

14. Question 14 of 30

    Which practice best describes how Infrastructure as Code prevents configuration drift across CI/CD environments?

    • aTeams maintain detailed runbooks that document every manual change made to production servers
    • bDeployment speed is increased by automating infrastructure changes without defining desired state
    • cOperators run standardized shell scripts to configure each server identically
    • dEnvironments are defined by versioned declarative files that specify the desired state and can be recreated on demand
    Show the answer

    Answer: d · Environments are defined by versioned declarative files that specify the desired state and can be recreated on demand

    Declarative, versioned definitions ensure every environment matches the desired state and can be reproduced identically, which stops drift. Standardized shell scripts are imperative and still risk configuration drift because they depend on the server's starting state and do not enforce a unified model.

    Read the full bite: What is IaC and its CI/CD benefits over manual provisioning?

15. Question 15 of 30

    A developer runs terraform plan in a CLI-driven HCP Terraform workspace. What occurs during this step?

    • aThe workspace locks state and provisions the proposed resources immediately after policy checks pass
    • bA remote speculative plan previews changes, validates against policies, and leaves infrastructure unchanged
    • cAll workspace variables and sensitive values are downloaded to the developer's local machine for execution
    • dThe configuration is automatically committed to version control before the remote run begins
    Show the answer

    Answer: b · A remote speculative plan previews changes, validates against policies, and leaves infrastructure unchanged

    terraform plan initiates a remote speculative run that shows proposed changes and checks policies without altering infrastructure. Distractor A is wrong because provisioning and state locking happen during terraform apply, not during the speculative plan phase.

    Read the full bite: Describe the Terraform workflow from code to live

16. Question 16 of 30

    An engineering team wants to spin up isolated test environments for every feature branch automatically. Which design best prevents cost leakage and cross-contamination while keeping environments truly ephemeral?

    • aUse dynamic branch-based naming with automatic stop jobs and TTL policies to destroy resources after merge
    • bCreate a persistent environment for each branch on first push and keep it running until the next release
    • cShare a single database and storage backend across all branch environments to reduce provisioning overhead
    • dHave developers clean up their own environments via a documented runbook triggered after pull request merge
    Show the answer

    Answer: a · Use dynamic branch-based naming with automatic stop jobs and TTL policies to destroy resources after merge

    Dynamic naming paired with automatic stop jobs or TTL policies guarantees isolated resources are destroyed when branches merge, preventing cost leakage. Persistent environments, manual runbooks, and shared backends are common anti-patterns that cause resource sprawl or cross-contamination.

    Read the full bite: Design a CI/CD pipeline for ephemeral feature branch environments

17. Question 17 of 30

    A security team uses an SBOM to identify all instances of a newly discovered vulnerable library. What critical piece of information does the SBOM not directly provide regarding this vulnerability?

    • aThe specific version numbers of the vulnerable library in use.
    • bA complete list of all transitive dependencies associated with the vulnerable library.
    • cWhether the vulnerable library is actually called or configured in a way that makes the application exploitable.
    • dThe supplier or source of the vulnerable component.
    Show the answer

    Answer: c · Whether the vulnerable library is actually called or configured in a way that makes the application exploitable.

    The card states that an SBOM "tells you what components you have, but not if they are configured or used in a vulnerable way." This means it doesn't confirm if a vulnerable component is actually exploitable in the product's specific context. This additional context is typically provided by a VEX document, not the SBOM itself. The other options describe information that an SBOM is designed to provide.

    Read the full bite: Software Bill of Materials (SBOM): An Ingredient List for Your Code

18. Question 18 of 30

    A team following Twelve-Factor Factor III stores configuration in environment variables. What operational benefit does this provide for CI/CD and scalability?

    • aOne build artifact can be promoted across environments and new instances start with the correct context immediately.
    • bThe application can bundle all settings inside the deployed artifact to remain self-contained.
    • cEach environment can use its own Git branch to manage configuration independently.
    • dOnly secrets are kept outside source code while non-secret settings remain hard-coded.
    Show the answer

    Answer: a · One build artifact can be promoted across environments and new instances start with the correct context immediately.

    Storing config in environment variables keeps the codebase identical across stages, enabling a single artifact to be promoted through CI/CD and allowing new instances to read the correct settings at startup for horizontal scaling. The distractor about keeping only secrets in env vars is wrong because Factor III applies to all deployment-specific configuration, not just sensitive data.

    Read the full bite: What is Twelve-Factor's config recommendation for CI/CD and scalability?

19. Question 19 of 30

    Which approach best implements defense-in-depth for delivering database credentials to a Kubernetes application through CI/CD?

    • aPlace the password in a ConfigMap, expose it as an environment variable, and rely on Kubernetes default secret encryption
    • bStore credentials in a private Git repo, sync them with cluster-admin privileges, and mount them as a volume
    • cFetch from an external secret manager via an operator, mount as a read-only volume, enforce least-privilege RBAC, and encrypt etcd at rest
    • dBuild the password into the container image and inject it via an environment variable at runtime
    Show the answer

    Answer: c · Fetch from an external secret manager via an operator, mount as a read-only volume, enforce least-privilege RBAC, and encrypt etcd at rest

    This combines external secret management, volume mount isolation, least-privilege RBAC, and etcd encryption as the card recommends. Option A is tempting because it uses native Kubernetes objects, but ConfigMaps lack confidentiality design and default etcd encryption is not enabled without an EncryptionConfiguration.

    Read the full bite: Describe secure secret injection into Kubernetes containers during CI/CD

20. Question 20 of 30

    In a GitOps workflow, how do you supply a database password to a Helm chart without exposing it in release metadata or requiring the app to reload file-based secrets?

    • aUse the Vault Secrets Operator to sync the password into a Kubernetes Secret that the chart mounts by name
    • bInject the password directly into pods via a Vault agent sidecar writing to a shared volume
    • cEncrypt the password with SOPS in a values file and decrypt it during CI before running helm install
    • dCreate the Kubernetes Secret manually with kubectl and reference its name in the Helm values file
    Show the answer

    Answer: a · Use the Vault Secrets Operator to sync the password into a Kubernetes Secret that the chart mounts by name

    Vault Secrets Operator keeps the credential out of Helm values entirely, preventing exposure in release metadata, while native Secret mounts avoid file-reload logic. SOPS-encrypted values are decrypted before Helm consumes them, so the plaintext password still ends up stored in Helm release metadata.

    Read the full bite: How do you securely manage and inject Helm secrets in CI/CD?

21. Question 21 of 30

    In a production Dockerfile, what is the primary purpose of splitting the build into multiple stages?

    • aTo keep build dependencies and compilers out of the final deployed image
    • bTo run build and runtime processes in parallel within one container
    • cTo increase the total number of layers available for build caching
    • dTo ensure build tools like GCC remain available in the final image for debugging
    Show the answer

    Answer: a · To keep build dependencies and compilers out of the final deployed image

    Multi-stage builds isolate compilation in a builder stage and copy only runtime artifacts to the final image, eliminating compilers and dev tools that increase size and attack surface. Option D describes a common anti-pattern: keeping build tools in production for debugging, which defeats the security and size benefits of multi-stage builds.

    Read the full bite: Walk me through a production-ready Dockerfile for a web app

22. Question 22 of 30

    Why should a CI/CD pipeline update the Deployment spec with a unique image tag rather than repushing the same :latest tag?

    • aKubernetes automatically detects when the underlying :latest image changes and redeploys pods
    • bUpdating the spec with a unique tag triggers a controlled rollout and ensures reproducible rollbacks
    • cUnique tags prevent the container runtime from caching images and causing stale layer issues
    • dSetting imagePullPolicy to Always with :latest guarantees all nodes run identical images
    Show the answer

    Answer: b · Updating the spec with a unique tag triggers a controlled rollout and ensures reproducible rollbacks

    Updating the spec with an immutable tag changes the pod template, driving a controlled rolling update and enabling deterministic rollbacks. The tempting idea that imagePullPolicy: Always fixes :latest is wrong because the tag is mutable, so nodes pulling at different times can still end up running different images.

    Read the full bite: How ensure Kubernetes pulls correct new image and why avoid :latest?

23. Question 23 of 30

    In a zero-downtime rolling update, what is the primary purpose of configuring a preStop sleep hook?

    • aIt delays SIGTERM briefly so endpoint removal can propagate before draining starts
    • bIt guarantees Kubernetes creates a replacement pod before terminating the old one
    • cIt acts as a readiness check to verify the application is initialized before serving traffic
    • dIt extends the grace period between SIGTERM and SIGKILL to finish active requests
    Show the answer

    Answer: a · It delays SIGTERM briefly so endpoint removal can propagate before draining starts

    The preStop hook sleeps before SIGTERM to allow the Service endpoints controller and load balancers to stop sending new traffic to the pod before it begins draining. Distractor A describes terminationGracePeriodSeconds, which governs the SIGTERM-to-SIGKILL window, not the endpoint propagation delay.

    Read the full bite: Design a zero-downtime Kubernetes Deployment strategy for a stateless microservice

24. Question 24 of 30

    Which feature primarily contributes to Ansible's simplified setup and agentless operation on target machines?

    • aIts ability to leverage standard SSH for communication without needing extra software on targets
    • bThe automatic discovery of target node configurations, eliminating manual inventory setup
    • cIts use of a custom, high-performance communication daemon
    • dThe requirement for a minimal Ansible agent to be pre-installed on all managed nodes
    Show the answer

    Answer: a · Its ability to leverage standard SSH for communication without needing extra software on targets

    The card highlights that Ansible is 'agentless' and 'connects to your machines (usually over SSH)' without requiring 'any special software (agents) to be installed on the target nodes.' This direct use of existing SSH infrastructure is key to its simplified setup. Option D is a direct contradiction of Ansible's agentless nature.

    Read the full bite: Ansible: Automating Infrastructure with Playbooks

25. Question 25 of 30

    What is the immediate consequence if a critical, show-stopping bug is identified during Release Candidate (RC) testing?

    • aThe release is temporarily halted, and the RC is put on hold until all non-critical issues are also resolved.
    • bThe development team reverts to the previous beta version to address the issue and restart the entire testing cycle.
    • cThe bug is fixed, and a new Release Candidate (e.g., RC2) is created, which then undergoes renewed validation.
    • dThe identified bug is fixed, and the existing RC is then released to the public with a patch.
    Show the answer

    Answer: c · The bug is fixed, and a new Release Candidate (e.g., RC2) is created, which then undergoes renewed validation.

    The card explicitly states that if a critical bug is found, it is fixed, and a new RC (e.g., RC2) is issued, restarting the final validation process. This ensures the 'promise' of the RC as a stable, shippable version is upheld. Option D is incorrect because a new RC is issued, not the old one patched and released.

    Read the full bite: Release Candidate: The Final Dress Rehearsal

26. Question 26 of 30

    What is the fundamental characteristic of a software system operating under Continuous Delivery (CD)?

    • aThe software artifact is consistently maintained in a state ready for reliable deployment to production at any time.
    • bAll software development is structured into very short, iterative cycles to maximize code output.
    • cNew code changes are automatically pushed to production environments immediately after passing tests.
    • dThe entire release process, from code commit to production, is fully automated without any human intervention.
    Show the answer

    Answer: a · The software artifact is consistently maintained in a state ready for reliable deployment to production at any time.

    Continuous Delivery ensures the software is always in a deployable state, making releases a routine business decision that can happen at any moment. Option C describes Continuous Deployment, which is a common misconception explicitly mentioned in the card as different from Continuous Delivery.

    Read the full bite: Continuous Delivery: Ship Reliably, Anytime

27. Question 27 of 30

    Where should SAST be placed in CI/CD to maximize shift-left value, and why?

    • aIt should run after deployment so it can analyze the running application using live traffic data
    • bIt should run only in nightly pipelines to avoid slowing down developer workflows with per-commit noise
    • cIt should run as a manual gate before production so security teams can triage every finding
    • dIt should run in the test stage on every commit because flaws are cheapest to fix while the code context is fresh
    Show the answer

    Answer: d · It should run in the test stage on every commit because flaws are cheapest to fix while the code context is fresh

    Running SAST in the test stage on every commit provides immediate feedback when the code context is fresh, making vulnerabilities cheapest to fix before they reach production. Option A is tempting because beginners often confuse static source-code analysis with dynamic runtime testing, but SAST does not require a deployed application.

    Read the full bite: What is SAST and which CI/CD stage integrates it best?

28. Question 28 of 30

    What specific aspect of the software delivery process does "Lead Time for Changes" primarily measure?

    • aThe time elapsed between a code commit and that specific code running successfully in production.
    • bThe total time from a customer's initial request for a feature until it is live in production.
    • cThe time spent by a team actively coding and testing a feature before it is ready for deployment.
    • dThe duration from when a developer starts working on a task until it is released to users.
    Show the answer

    Answer: a · The time elapsed between a code commit and that specific code running successfully in production.

    Lead Time for Changes specifically measures the duration from a code commit to its deployment in production. Option B describes the broader 'Lead Time' from idea to delivery, which the card explicitly differentiates from this metric.

    Read the full bite: Lead Time for Changes: From Commit to Production

29. Question 29 of 30

    A team catches a SQL injection flaw pre-merge using SAST, but a runtime data-handling vulnerability slips into production. What does this best illustrate?

    • aThe SQL injection should have been caught by DAST in a staging environment.
    • bDAST is unnecessary if SAST scans all code paths before deployment.
    • cSAST requires a deployed application to accurately identify vulnerabilities.
    • dSAST cannot detect issues that only manifest when the application is running.
    Show the answer

    Answer: d · SAST cannot detect issues that only manifest when the application is running.

    SAST examines source code without execution, so it misses runtime-only flaws like the data-handling vulnerability described. Option B is wrong because the article states that relying on just one type of testing leaves applications vulnerable, meaning the tools are complementary, not redundant.

    Read the full bite: Compare SAST and DAST. Why use both, and their limits?

30. Question 30 of 30

    Which strategy best prevents vulnerable Terraform from reaching production while maintaining developer velocity?

    • aRun static analysis only after deployment to staging to avoid slowing down pull request validation times
    • bRely solely on cloud provider native tools to scan infrastructure after each Terraform deployment completes
    • cEmbed Checkov or tfsec in pull request pipelines to fail on critical findings and offer local IDE plugins for fast feedback
    • dSchedule manual security reviews of Terraform plans during monthly audits instead of automated checks
    Show the answer

    Answer: c · Embed Checkov or tfsec in pull request pipelines to fail on critical findings and offer local IDE plugins for fast feedback

    This reflects shift-left security by blocking vulnerable code at the PR stage and giving developers immediate local feedback, which the card describes as essential. Option B is tempting because cloud native tools are legitimate, but relying solely on post-deploy detection allows misconfigurations to be provisioned before they are caught.

    Read the full bite: How would you integrate automated security scanning for Terraform in CI/CD?