DevSecOps Engineer interview questions

I would publish small versioned templates with stable contracts and enforce immutability separately for each reference type.

• Separate build, scan, sign, and deploy templates so each job receives only the permissions and secrets it needs.
• Define typed inputs, required outputs, artifact digests, and failure semantics so teams can integrate without copying YAML.
• Pin GitHub Actions to full 40-character commit SHAs and pin container images and downloaded tools by their native content digests.
• Publish SemVer tags for discovery, but have consumers use a full commit SHA and call a tag immutable only when repository controls separately prevent or detect retagging.

I would make untrusted code and protected release jobs separate trust zones with no credential path between them.

• Pull-request jobs get read-only source access, no repository secrets, no cloud role, and an isolated cache namespace.
• A protected branch job consumes the reviewed commit, obtains a short-lived identity, and writes only to a staging artifact repository.
• Signing and production promotion run after policy checks in a protected environment with explicit permissions and immutable inputs.
• Artifacts from the untrusted zone are treated as untrusted data and rebuilt in the release zone rather than promoted directly.

I would provide an authenticated remote rootless BuildKit service whose workers and trust state are isolated per job and team.

• Each build runs in a fresh rootless worker or equivalent user-namespace boundary with no host Docker socket, privileged container, or reusable workspace.
• A job-scoped OIDC or mTLS identity authorizes the repository and cache namespace, while untrusted pull requests cannot write cache entries later consumed by protected releases.
• Egress is allowlisted, secret and SSH mounts exist only for the build session, and logs, layers, and exported caches are checked to ensure secret material is not persisted.
• I would canary representative builds from all 8 teams and require isolation tests to pass with p95 build time no more than 15% above the current baseline before retiring Docker-in-Docker.

I would create separate runner pools by trust level and destroy the worker after one job.

• Untrusted pull requests never share a pool, subnet, cache, or service account with release jobs.
• Each worker gets a minimal network policy that permits only source, dependency mirror, logs, and its assigned artifact repository.
• The orchestrator injects a job-scoped identity after scheduling, while the base image contains no cloud keys or repository credentials.
• Pool labels are only scheduling metadata, so isolation is enforced by separate accounts, networks, identities, and autoscaling groups.

An ephemeral runner should be created from a verified image for one job and destroyed whether that job succeeds or fails.

• The controller obtains a short-lived registration token, then registers with --ephemeral or uses a JIT runner configuration so the worker accepts exactly one job; the registration token itself is not assumed to be single-use.
• A short-lived workload identity and job-specific network policy are attached only after the scheduler selects the worker.
• Logs and approved artifacts leave through controlled sinks, while workspaces, caches containing credentials, and local disks do not survive teardown.
• I alert on workers alive beyond the expected build duration plus a small grace period because failed destruction creates persistent attack surface.

I would split scanning by trust so forks receive a credentialless reduced control while protected code receives the authoritative licensed scan.

• External fork pull requests run an open or locally packaged reduced ruleset with read-only repository access, no vendor credential, no secrets, and no writable cache shared with trusted jobs.
• The CI control plane labels its sanitized result with commit, scanner version, rules version, and a fork-reduced trust class that cannot satisfy the protected-branch gate.
• After review, the protected branch runs the licensed scanner with a narrowly scoped credential and publishes a trusted result tied to the reviewed commit and release artifact.
• Promotion rebuilds in the trusted zone and requires that licensed result, while regression tests prove a fork cannot replace scan evidence, poison its cache, or promote its artifacts.

I would build once, identify the artifact by digest, and promote that exact digest through environments.

• The build job pushes to an immutable staging repository and emits the image digest, SBOM, provenance, and test evidence.
• Policy checks verify those objects refer to the same digest before a promotion record is created.
• Deployment jobs copy or reference the approved digest without accepting a mutable tag as the source of truth.
• Production admission verifies signature and provenance again, so approval of one digest cannot authorize a substituted image.

I would release a new major template version, automate migration checks, and set a time-bound retirement for the old version.

• A compatibility test scans every consumer for removed inputs, permission changes, and unsupported runner assumptions before rollout.
• Two services from different stacks adopt first, and their duration, failure rate, and denied permissions become canary signals.
• Teams receive a generated pull request with the version bump and exact remediation rather than a wiki-only announcement.
• The old version remains immutable during the migration window, then policy blocks new uses before existing consumers reach the final deadline.

I would use the repository dependency graph to run fast checks on affected components while keeping scheduled full-repository coverage.

• A change detector maps edited files to services, shared libraries, lockfiles, container definitions, and downstream dependents.
• Pull requests run relevant SAST, SCA, IaC, and secret scans in parallel with normalized findings and one final gate.
• A nightly job scans all services and base images to catch new advisories that appear without a code change.
• The orchestrator records scanner version, rule set, commit, component, and result so skipped work is visible rather than mistaken for a pass.

A differential gate should compare the proposed commit with an explicit trusted baseline and block newly introduced risk in the affected scope.

• For SAST it compares stable fingerprints, not line numbers alone, because refactoring moves the same finding.
• For SCA it includes newly added packages, version changes, and vulnerabilities newly affecting an existing dependency graph.
• For IaC it evaluates the planned resource delta as well as inherited module changes.
• A scheduled full gate still evaluates the whole estate because differential scans cannot detect every rule or advisory update.

I would make scanner-result reuse depend on the monorepo dependency graph and every input that can change a finding.

• Cache keys include source and lockfile hashes, shared-library revisions, resolved base-image digest, build configuration, scanner and rule versions, and advisory-data version.
• A changed shared lockfile, base image, library, or build template invalidates results for its full downstream service closure, while unknown graph impact triggers a full scan instead of a cache hit.
• Cache namespaces are content-addressed and separated by trust class, and a missing, stale, or failed result can never be converted into a pass.
• A scheduled full scan reconciles all 40 services against reused results, reports unexplained divergence, and disables the faulty cache path until its invalidation rule is corrected.

Reachability should raise or lower remediation priority, but it should not be the only reason a vulnerable dependency passes.

• A reachable vulnerable function in an internet-facing service is strong evidence for a blocking gate.
• An unreachable result can be uncertain with reflection, plugins, generated code, native bindings, or runtime-only paths.
• I combine reachability with package location, deployment exposure, exploit maturity, compensating controls, and dependency depth.
• The evidence and tool version are stored with the decision so a later call-graph or application change triggers re-evaluation.

No, I would gate on contextual risk rather than CVSS alone, while keeping a conservative rule for confirmed exploitation.

• CISA KEV inclusion or a reliable exploit for an exposed path can justify an immediate block even when the raw score is lower.
• EPSS, reachability, internet exposure, package usage, and available compensating controls refine priority.
• Scanner confidence and fix availability affect the action, but lack of a patch does not erase the risk or ownership.
• The decision matrix is versioned and produces a recorded reason so teams receive consistent outcomes across 40 services.

I would use changed-component analysis for ordinary pull requests and reserve full cross-service dataflow for risk-triggered and scheduled gates.

• A reviewed dependency graph maps edited files to services, generated code, shared libraries, entry points, and downstream callers so the pull-request scan covers affected components rather than only changed lines.
• Ordinary service changes run high-confidence interprocedural rules inside a fixed pull-request budget and publish any skipped scope as incomplete rather than clean.
• Changes to shared libraries or cross-service interfaces trigger the 28 GB full analysis as a required merge gate because their dataflow impact cannot be bounded to one component safely.
• A scheduled isolated 35-minute full scan reconciles every service, routes stable findings to owners, and supplies regression cases when the changed-component path misses a flow.

I would scan lockfiles before build and scan the final image by digest because those views answer different questions.

• Pull-request SCA checks direct and transitive dependencies from committed lockfiles and detects risky version changes early.
• The image scan finds operating-system packages, copied binaries, and build artifacts that are absent from the application lockfile.
• Nightly rescans of stored production digests catch newly published CVEs without rebuilding the image.
• Results are correlated by service, package, version, layer or manifest, and digest so duplicate findings have one owner and one status.

I would run authenticated DAST against an ephemeral environment after deployment and keep a signed evidence record tied to the release digest.

• A smoke profile runs on release candidates, while a broader crawler and active test set runs nightly to control latency and test risk.
• Test accounts, seeded data, allowed hosts, request rate, and destructive-test exclusions are explicit and reproducible.
• The result stores scanner and rule versions, target commit, image digest, timestamps, coverage, findings, and any incomplete checks.
• The release gate consumes a normalized verdict, but teams can open the original report to inspect request and response evidence.

I would use the strongest native workload identity available for each environment and avoid distributing a shared Vault token.

• CI authenticates with JWT or OIDC claims bound to repository, branch, audience, and workflow, then receives a short Vault token.
• Kubernetes workloads use Kubernetes auth with service-account identity bound to an exact namespace and service account.
• Legacy VMs use a machine identity such as cloud IAM auth; AppRole is a fallback only when RoleID and SecretID delivery can be separated.
• Every auth role has narrow policies, a short token TTL, usage telemetry, and no default path shared across all 40 services.

I would give each service a database role that issues narrowly privileged users with short, renewable leases.

• Vault role SQL grants only the schemas and operations that service needs, with separate roles for migrations and normal runtime access.
• The default TTL covers normal connection turnover, while max TTL forces replacement instead of indefinite renewal.
• Applications renew before expiry and rotate connection pools gracefully so new credentials enter service before old sessions close.
• Lease owner, database role, issue time, renewal, expiry, and revocation are monitored per service for audit and capacity planning.

Dynamic credentials need a tested revocation path that removes external access and handles active application sessions.

• Each Vault role has deterministic revocation SQL that disables or drops only the generated database user without touching other service identities.
• For immediate containment, a separately authorized path disables login and terminates that generated user's active database sessions instead of waiting for pooled connections to age out.
• Routine connection lifetime is bounded, and revocation failures enter a retry queue with alerts containing lease, role, service, and database identifiers.
• Periodic reconciliation compares active Vault leases, database users, and live sessions to find orphaned credentials or surviving access on either side.

I would use response wrapping to deliver sensitive bootstrap material through an intermediary without exposing the underlying secret.

• Vault returns a single-use wrapping token with a short TTL instead of the AppRole SecretID or initial credential itself.
• The target workload unwraps directly from Vault and verifies expected creation path and wrapping metadata before using the value.
• An expired or already-unwrapped token fails closed and produces an audit event, which reveals interception or delayed delivery.
• Wrapping protects delivery, but it does not replace workload authentication, narrow policy, or rotation after bootstrap.