What DevSecOps Interviewers Actually Ask in 2026

Shifting left means catching security issues earlier in the development process rather than at a pre-production gate. The idea is that finding an injection vulnerability in a PR review costs a few developer-hours to fix. Finding it post-deployment costs a CVE, an incident, and potentially a breach disclosure.

Where teams get it wrong: they install SAST tools, watch the false-positive rate climb past 40%, and then developers start ignoring every warning. Shift-left only works if the signal is high enough quality that engineers trust it. That means tuning your rules, suppressing known false positives, and starting with a narrow ruleset that you expand over time.

A sensible pipeline order:

Pre-commit hooks: TruffleHog or git-secrets to block committed credentials before they reach remote. Fast, cheap, high-value.

PR-level SAST: CodeQL or Semgrep on pull requests. Block merge on HIGH severity only, not MEDIUM, not LOW.

Build-time: dependency scanning (npm audit, Snyk, OSV-Scanner), SBOM generation.

Staging: DAST via OWASP ZAP or Nuclei against a running environment, not source code.

# GitHub Actions - minimal high-signal pipeline
name: Security
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Secrets scan
        run: trufflehog git file://. --since-commit HEAD~1
      - name: SAST (CodeQL)
        uses: github/codeql-action/analyze@v3
      - name: Dependency audit
        run: npm audit --audit-level=high

The key metric: what percentage of security findings your pipeline surfaces actually get fixed? If it’s below 60%, your gates are too noisy.

These three scan different surfaces at different times. Confusing when to run them is one of the most common pipeline mistakes.

I’d run SAST on every PR, DAST on every merge to main that touches auth or API surface, and IAST only if you have a mature test suite where the overhead is worth it. Trying to run all three on every PR will break your feedback loop.

The common failure mode is environment variables. Teams move away from hardcoded secrets in source code to hardcoded secrets in docker-compose files or Kubernetes manifests, both of which end up in Git. Same problem, different layer.

The right approach involves three things:

1. A dedicated secret store: HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager. Not environment variables. Not Kubernetes Secrets without encryption at rest (they’re base64, not encrypted by default).

2. Short-lived credentials where possible. Instead of a long-lived database password, use dynamic secrets that Vault generates per-request and expire in hours.

3. Rotation automation. A secret that never rotates is a breach waiting for a timeline.

# External Secrets Operator - pulls from Vault into K8s
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: db-secret
  data:
  - secretKey: password
    remoteRef:
      key: database/prod
      property: password

Audit secret access. Most teams configure the store but never look at who retrieved what.

Security gates fail in predictable ways. They’re too slow (adds 20 minutes to every PR), they fire on too many false positives, or they have no clear remediation path. All three outcomes produce the same behavior: developers learn to skip them or suppress them.

Design principles that work:

Run security checks in parallel with functional tests, not after them. There’s no reason secrets scanning needs to wait for your Jest suite to finish.

Fail on severity thresholds, not on every finding. CRITICAL always fails. HIGH fails unless there’s a documented exception. MEDIUM and LOW are informational.

Provide remediation context in the PR comment, not just “FAILED”. Link to the specific vulnerability, why it matters, and how to fix it.

Have a break-glass path for emergency deploys with increased logging and a required post-incident review. If there’s no official way to skip a gate, engineers will find an unofficial one.

Three things matter most. Everything else is downstream of getting these right.

Non-root user. Most container images run as root by default. If an attacker escapes the container, root access changes the blast radius completely. Create a dedicated user in your Dockerfile and use it.

Minimal base image. Alpine-based images have roughly 8 MB of packages to scan versus 200+ MB in a full Debian image. Fewer packages means fewer CVEs. Distroless images go further – they don’t even include a shell, which eliminates an entire class of lateral movement attacks.

Multi-stage builds. Build tooling – compilers, package managers, dev dependencies – should never be in your production image. Multi-stage builds let you compile in one stage and copy only the binary into the final stage.

FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o app

FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/app /app
USER nonroot:nonroot
EXPOSE 8080
ENTRYPOINT ["/app"]

Also: sign your images with Cosign, scan with Trivy in CI, and use an admission controller that rejects unsigned images from reaching production.

RBAC (Role-Based Access Control) controls who can take what action on which resources in Kubernetes. Subjects (users, service accounts, groups) get bound to roles via RoleBindings or ClusterRoleBindings. The principle of least privilege applies – every service account should have exactly the permissions it needs, nothing more.

The harder question is the inheritance scenario. A cluster that’s been running for 18 months without RBAC auditing is almost certainly over-permissioned. Here’s how I approach it:

Run kubectl-who-can to see who can do what. Pay particular attention to get secrets, exec, and create pods permissions – these are the most commonly abused.

Look for wildcard verbs and resources. verbs: ["*"] or resources: ["*"] should be rare and documented.

Check for service accounts with default mounts. By default, Kubernetes mounts a service account token into every pod. In Kubernetes 1.24+, these are non-expiring unless you set automountServiceAccountToken: false on pods that don’t need API access.

# Minimal service account - only what the app actually needs
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-reader
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]
  resourceNames: ["app-config"]  # specific resource, not wildcard

Pod Security Policies (PSP) were removed in Kubernetes 1.25 after years of being notoriously difficult to configure correctly. They required explicit binding to service accounts, and the defaults were confusing enough that many teams just granted cluster-admin to their CI runners to make deployments work. Not great.

Pod Security Standards (PSS) replaced them with three levels: Privileged (no restrictions), Baseline (blocks obvious privilege escalations), and Restricted (current hardening best practices – non-root users, no privilege escalation, read-only root filesystem where possible).

You enforce them via namespace labels, which is much simpler than PSP. You can also set audit and warn modes independently from enforcement, which lets you see what would break before you enforce.

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

If you’re on a mixed cluster with older workloads, start with warn before enforce. The first time I enforced restricted on an inherited namespace, 11 deployments broke.

By default, Kubernetes allows all pod-to-pod traffic within a cluster. Any pod can reach any other pod on any port. In a cluster with 47 microservices, that means a compromised payment processing pod can talk directly to your user data service, your internal admin API, or your database pods.

Network Policies are the primary tool for segmenting this. You define ingress and egress rules at the pod label level. The correct default is deny-all ingress per namespace, then explicitly allow the traffic that needs to flow.

# Default deny all ingress in a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
# Then explicitly allow what needs to flow
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

For service-to-service mTLS (mutual TLS), a service mesh like Istio or Linkerd does this at a layer Network Policies can’t reach. They’re complementary, not competing.

Runtime security monitors what a container is actually doing while it runs, not just what it was configured to do. Static analysis and image scanning tell you what vulnerabilities exist at deploy time. Runtime monitoring tells you when something unexpected happens – a process spawns a shell, a container opens a new outbound connection, or a file in a read-only path gets modified.

Falco is the most widely used open-source tool for this. It hooks into Linux kernel syscalls and matches them against rules. The default ruleset is broad; you’ll want to tune it for your workloads or you’ll drown in alerts.

# Falco rule - detect shell spawned in a container
- rule: Terminal shell in container
  desc: A shell was spawned in a container
  condition: >
    spawned_process and container
    and shell_procs
    and not proc.pname in (shell_procs)
  output: >
    Shell spawned in container (user=%user.name
    container=%container.name image=%container.image.repository
    cmd=%proc.cmdline)
  priority: WARNING

The output needs to go somewhere actionable – a SIEM, PagerDuty, or an automated response that quarantines the pod. Alerts that go to Slack and get ignored are not a security control.

IaC security scanning catches misconfigurations before they’re provisioned – open S3 buckets, permissive security groups, unencrypted storage, IAM roles with wildcard permissions. Fixing a Terraform misconfiguration in a PR review takes minutes. Fixing it post-breach takes months.

Three tools worth knowing:

Checkov: Policy-as-code scanner for Terraform, CloudFormation, Kubernetes manifests, Dockerfile. Good default ruleset, integrates cleanly with CI.

Trivy: Primarily an image scanner but also scans Terraform and Kubernetes manifests. If you’re already using Trivy for containers, the IaC coverage is free.

Terrascan: Strong multi-cloud coverage and compliance mapping (CIS, HIPAA, PCI DSS).

# GitHub Actions - IaC security gate
- name: Checkov scan
  uses: bridgecrewio/checkov-action@v12
  with:
    directory: terraform/
    framework: terraform
    check: CKV_AWS_*
    soft_fail: false
    output_format: sarif
    output_file_path: results.sarif

IAM misconfigurations are the leading cause of cloud breaches, according to multiple years of cloud security reports. The failures aren’t usually exotic – they’re predictable. Wildcard permissions on Lambda execution roles, no MFA on root accounts, long-lived access keys that never rotate.

The principles that matter:

Least privilege, consistently. Don’t grant s3:* when you need s3:GetObject on a specific bucket. This requires more effort upfront and saves significant pain later.

Prefer roles over access keys. EC2 instances, Lambda functions, and ECS tasks should authenticate via instance/task roles, not long-lived key pairs sitting in environment variables.

Enforce MFA for all human access, especially console and programmatic access for privileged operations.

Audit unused permissions regularly. AWS IAM Access Analyzer and similar tools will show you permissions that haven’t been used in 90 days. Remove them.

Zero-trust means “never trust, always verify” – no implicit trust based on network location. A request from inside the VPC gets the same scrutiny as a request from the internet. This model came out of Google’s BeyondCorp work and has become standard language in enterprise security.

Operationally, it means several concrete things. Identity-based access rather than IP-based access. mTLS between services rather than relying on network segmentation alone. Short-lived credentials rather than persistent tokens. Logging and monitoring on every access, not just perimeter traffic.

For a DevSecOps engineer, implementing zero-trust in a Kubernetes environment usually means: deploying Istio or Linkerd for service mesh mTLS, strict RBAC with no wildcards, per-pod network policies, and an OPA Gatekeeper setup that enforces security contexts.

The gap between “we’ve adopted zero-trust” and actually having it is large. I’d rather see a team with strict Network Policies and proper RBAC than one that’s “doing zero-trust” with a checkbox exercise.

The challenge with microservices incidents is that a single attack may span 9 services and 3 cloud accounts simultaneously. The traditional “isolate the server” response doesn’t translate directly to containers that spin up and down every few minutes.

The response framework I’d describe in an interview:

Detection: Falco firing on a runtime anomaly, SIEM alert correlating failed auth across multiple services, or an anomaly in egress traffic. You need this automated – someone watching dashboards 24/7 isn’t realistic.

Containment: Apply a NetworkPolicy that blocks all traffic to/from the affected pod. Don’t delete it yet – you want forensics. In Kubernetes, labeling the pod triggers a Gatekeeper-managed isolation policy.

Forensics: Capture the container’s filesystem, running processes, and network state. Tools like Sysdig’s capture or a simple kubectl exec to dump memory state before the pod is replaced.

Recovery: Deploy a clean image from a known-good signed version, verify the security context, rotate any credentials the compromised pod had access to.

Practice this. Run a tabletop exercise quarterly. The teams that respond well to incidents are the ones who’ve rehearsed it.

The NIST SSDF (SP 800-218) is a framework for reducing vulnerabilities in software by integrating security throughout the development lifecycle. It was formalized in February 2022 and has since been referenced by the White House Executive Order on Improving the Nation’s Cybersecurity. If you’re working at any company doing government contracts or in a regulated sector, you’ll encounter this.

The SSDF breaks down into four practice groups: Prepare the Organization (governance, tooling, training), Protect the Software (source code security, access control), Produce Well-Secured Software (secure design, security testing), and Respond to Vulnerabilities (disclosure policies, patch processes).

As a DevSecOps engineer, you’re implementing the middle two groups. Your SAST tooling maps to “Produce Well-Secured Software.” Your secrets management practices map to “Protect the Software.” The framework is useful as a vocabulary for talking to compliance teams and leadership who don’t speak pipeline.

Threat modeling is the process of systematically identifying what could go wrong with a system before building it. STRIDE is the most common framework: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.

Where it goes wrong in DevSecOps: threat modeling gets treated as a one-time activity during design review, then forgotten when the system evolves. A better approach is threat models as living documents, stored in version control, updated when architecture changes, and linked to the security tests that validate the mitigations.

Practical implementation:

Run a threat model session at the start of any feature touching auth, payments, or external integrations. 90 minutes with a whiteboard and 4 people catches most things.

Encode the findings as code. A threat with “parameterized queries” as its mitigation should map to a SAST rule that enforces parameterized queries.

Automate the repetitive parts. Tools like OWASP Threat Dragon or IriusRisk can generate baseline models from system diagrams.

The teams I’ve seen do this well treat every severity-HIGH finding in their SAST as evidence that the threat model missed something. That feedback loop matters.

Supply chain security became urgent after SolarWinds (2020) and the Log4Shell vulnerability (2021). Attackers realized that compromising one upstream dependency or build tool is more efficient than attacking individual targets. OWASP now lists Dependency Chain Abuse as one of the top 10 CI/CD security risks.

The practical controls:

Software Bill of Materials (SBOM): A machine-readable list of every dependency in your artifact and its version. Generated at build time, signed, and stored alongside the artifact. Tools: Syft, Trivy, CycloneDX.

Image signing: Cosign from the Sigstore project signs your container images with a key tied to your CI identity. An admission controller in Kubernetes then rejects unsigned images.

Dependency pinning: Pin dependencies to exact versions and verify checksums. Floating versions like ^4.2.0 can silently pull in a compromised release.

Private package mirrors: Proxy external registries through a private mirror (Artifactory, Nexus) that scans packages before making them available internally.

SOC 2 compliance and fast delivery aren’t inherently in conflict. The conflict usually comes from implementing compliance as a manual documentation exercise on top of an existing engineering process, rather than building it into the process from the start.

The highest-impact controls to automate:

Access control evidence: Your RBAC configuration in Git is audit evidence. Your CI/CD approval requirements are audit evidence. Stop generating PDF reports manually – your version control history is the record.

Change management: Every production deployment via your pipeline with a required PR approval satisfies change management controls. Export deployment logs to your compliance platform automatically.

Vulnerability management: Your Trivy scan results, tracked over time, are vulnerability management evidence. Connect your scanner output to Drata, Vanta, or Secureframe to automate the evidence collection.

Monitoring and logging: CloudTrail, VPC Flow Logs, and application logging to a centralized SIEM – these are both operational needs and audit evidence for the monitoring controls.

I’d rather see automated evidence collection that runs continuously than a manual audit sprint every 6 months. Both pass audits. One builds a culture of compliance.

Most DevSecOps programs track inputs (number of scans run, percentage of pipelines with security checks) rather than outcomes (rate of vulnerabilities reaching production, mean time to patch after a CVE). Inputs tell you whether the machinery is running. Outcomes tell you whether it’s working.

Metrics that actually matter:

Vulnerability escape rate: What percentage of HIGH/CRITICAL vulnerabilities detected post-deployment should have been caught in the pipeline? If this is above 15%, your gates need tuning.

Mean time to patch (MTTP): After a CVE appears in your dependency tree, how long before it’s patched and deployed? Under 7 days for CRITICAL is a reasonable target. Under 30 days for HIGH.

False positive rate on SAST: If above 35%, developers are ignoring findings. That’s not a security program – it’s security theater.

Secrets detection success rate: What percentage of accidentally committed credentials did your pre-commit hooks catch before they reached remote? If you’re finding secrets in Git history, the answer is too low.

This scenario is one I’d practice before any senior DevSecOps interview. It tests whether you can think operationally, not just theoretically.

First: assess impact. Check the CVE score and whether it’s exploitable in your environment. A CVSS 9.8 with network-exploitable attack vector and no auth required is different from a 9.8 that requires local access. Read the actual CVE, not just the score.

Second: identify the blast radius. Which images use the vulnerable base? Are any externally reachable? Do any process untrusted input? This determines priority, not the CVE score alone.

Third: patch and validate in a non-production environment. Update the base image tag, rebuild, run your full test suite plus a targeted security test for the specific vulnerability.

Fourth: deploy in priority order. Externally facing, untrusted-input services first. Internal, low-exposure services in the next wave.

Fifth: retrospective. Why did 23 services all share the same base image version? Is there a Renovate or Dependabot configuration that should have flagged the update earlier? Patch management is the output; the system that prevents it accumulating is the goal.

Policy as code means encoding security and compliance rules as versioned, testable code that gets automatically enforced, rather than documented in a PDF that someone may or may not read before deployment.

OPA Gatekeeper is a Kubernetes admission controller that evaluates policies written in Rego (OPA’s policy language) against any API server request. If a deployment spec violates a policy, Gatekeeper rejects it before it’s persisted.

# Gatekeeper ConstraintTemplate - block privileged containers
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8snoprivileged
spec:
  crd:
    spec:
      names:
        kind: K8sNoPrivileged
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8snoprivileged
        violation[{"msg": msg}] {
          c := input.review.object.spec.containers[_]
          c.securityContext.privileged
          msg := sprintf("Container %v is privileged", [c.name])
        }

The benefit over documentation or runbooks: this is enforced at every deployment, by every team, automatically. Nobody can accidentally deploy a privileged container because a Gatekeeper constraint stops them.

Multi-cloud introduces consistency problems. AWS, Azure, and GCP each have different IAM models, different native security tools, and different compliance reporting formats. The risk is that your security posture ends up being the weakest of the three, because each cloud gets configured slightly differently.

What actually helps:

Infrastructure as Code everywhere. If you’re configuring cloud resources through console or CLI, you can’t review them like code, test them, or consistently enforce policy.

A Cloud Security Posture Management (CSPM) tool that spans all clouds – Prisma Cloud, Wiz, or Orca. These give you a unified view of misconfigurations and compliance violations across providers.

Centralized logging. Route CloudTrail, Azure Activity Logs, and GCP Cloud Audit Logs to a single SIEM. Incidents that span clouds are nearly impossible to investigate without this.

Kubernetes as a consistency layer. If you run workloads on Kubernetes across clouds (EKS, AKS, GKE), your K8s security model can be largely cloud-agnostic – same network policies, same RBAC, same admission controllers across all three.