DevSecOps Engineer interview questions

In a common operating model, a DevSecOps engineer maintains shared security controls in the delivery path, but exact ownership depends on the organization.

• The role often integrates and enforces agreed controls for CI/CD workflows, runner access, secrets use, dependency checks, and artifact integrity.
• Product developers remain responsible for code fixes, while AppSec or another security team may own scanner rules and risk decisions.
• A junior usually maintains a bounded workflow or scanner integration under review rather than setting company-wide policy.

DevOps focuses on reliable delivery, while DevSecOps adds explicit ownership of security controls within that delivery path.

• A DevOps task might make a GitLab CI deployment faster and repeatable.
• A DevSecOps task limits the job token, scans the artifact, and verifies approval before that deployment.
• The two roles overlap in pipeline mechanics, but security risk reduction is a required outcome for DevSecOps.

DevSecOps often focuses on shared delivery controls, while application security focuses more directly on risks in product design and code.

• AppSec may own threat models, code guidance, scanner platforms, or the rules those scanners apply.
• DevSecOps may integrate scanner results into GitHub Actions or GitLab CI, keep the checks reliable, and enforce controls agreed with AppSec and delivery teams.
• Product developers fix the affected code, and each organization should document where tool, policy, and remediation ownership sits.

DevSecOps centers on the software delivery path, while cloud security engineering centers on protecting cloud accounts, services, and configurations.

• A cloud security engineer may define network boundaries or organization-wide cloud access controls.
• A DevSecOps engineer restricts pipeline credentials and verifies the container before a cloud deployment.
• DevSecOps needs enough cloud knowledge to integrate safely, but routine cloud IAM administration is not the whole role.

A secure SDLC places appropriate security checks and evidence throughout planning, building, testing, and release.

• Source changes pass review and automated checks before they can reach a protected branch.
• Builds scan dependencies and secrets, then preserve results alongside the exact artifact.
• Release controls verify approvals and artifact identity instead of trusting that an earlier stage probably passed.

Shift-left means giving developers useful security feedback earlier, not moving every security responsibility onto them.

• A pull-request SCA check can flag a vulnerable dependency before it enters the default branch.
• Early checks should be fast and actionable, while slower DAST can still run against a deployed test environment.
• Runtime controls and release verification remain necessary because source-time checks cannot prove production safety.

A guardrail changes the delivery path automatically, while a report only informs someone that a risk exists.

• A GitHub Actions rule that rejects an unpinned third-party action prevents a risky change from merging.
• OpenSSF Scorecard can identify risky repository practices, but its output becomes a guardrail only when a clear rule consumes it.
• Good guardrails explain the failure and the fix so teams do not bypass them out of confusion.

A junior DevSecOps engineer should safely operate and improve a bounded control with clear escalation paths.

• Typical work includes updating a Trivy job, reviewing scan output, or reducing permissions in one CI template.
• Changes should be tested on a sample repository and reviewed before becoming a required gate.
• Ambiguous suppressions, broken releases, and requests for broader credentials should be escalated rather than guessed through.

A trust boundary is a point where code or data moves between components with different levels of control.

• A pull request from a fork is less trusted than code already reviewed on a protected branch.
• A runner receiving a deployment token crosses from build logic into privileged infrastructure access.
• Each crossing should have explicit authentication, minimal permissions, and validation of the input or artifact.

GitLab CI has explicit stages, while GitHub Actions has jobs ordered through needs and no stage primitive.

• GitLab jobs are assigned to stages, later stages normally wait for earlier ones, and jobs in one stage can run in parallel.
• In GitHub Actions, jobs without dependencies can run in parallel, while needs declares which successful jobs a later job depends on.
• In either system, separate scan, build, and deploy jobs make credentials, outputs, and failure conditions easier to review.

Separate jobs reduce how much untrusted code and sensitive data share the same execution context.

• A pull-request test job should not inherit the production deployment secret.
• A signing job can accept a digest rather than rebuild or execute repository code again.
• Job-level permissions make it clear which step may write packages, request OIDC tokens, or deploy.

CI artifacts cross job and time boundaries, so their producer, contents, and retention must be controlled.

• A later job must not trust an artifact uploaded by an untrusted workflow without checking its source and integrity.
• Logs, test reports, and archives can accidentally contain tokens or private source files.
• Short retention, restricted download access, and a digest tied to the build reduce exposure and substitution risk.

Hosted runners are usually ephemeral and provider-managed, while self-hosted runners give more control but retain more risk.

• A fresh GitHub-hosted runner limits persistence between jobs and reduces cleanup work.
• A self-hosted runner may expose internal networks, cached credentials, or files left by a previous job.
• Untrusted pull requests should not run on a privileged self-hosted runner unless strong isolation is in place.

Fork pull requests contain contributor-controlled code that may try to read secrets or alter the workflow.

• Standard pull-request jobs should run with read-only permissions and no deployment credentials.
• A trigger that uses trusted base-branch context must not execute the fork's code with elevated access.
• Privileged packaging or deployment should wait for review and run from a protected branch or environment.

Set the GITHUB_TOKEN to read-only by default and grant each job only the permissions it needs.

• A test job usually needs repository contents read access but no package or deployment write access.
• A publishing job may receive packages write access only after tests pass on a trusted branch.
• Request id-token write only in the job that actually performs an OIDC exchange.

A GitLab CI job token is a temporary credential whose project access should be restricted to the current job's purpose.

• Prefer the job token over a personal access token when the target service supports it.
• Limit which projects may use or accept the token instead of assuming all internal repositories are trusted.
• Do not save the token in artifacts, caches, command output, or files that survive the job.

Protected branches make changes pass defined review and status checks before entering trusted release history.

• Direct pushes can be blocked so one compromised developer credential cannot silently skip review.
• Required CI checks can enforce tests and scans on the exact commit being merged.
• Restricting force pushes preserves the reviewed commit history used by later build and provenance steps.

Protected environments control when a trusted commit may receive deployment access to a sensitive target.

• GitHub Actions environments can require reviewers before releasing environment secrets to a job.
• GitLab protected environments can restrict which branches, tags, or users may deploy.
• The deployment job should reference the reviewed artifact instead of rebuilding different content after approval.

Static application security testing analyzes source code or compiled representations without running the application.

• It can trace suspicious data flow, unsafe API use, or language-specific coding patterns.
• It fits pull-request or build jobs because it does not require a deployed target.
• A SAST result is a lead to review, not proof that an issue is exploitable in the deployed system.

SAST should give early feedback on changed code and run a complete check before trusted code is released.

• A fast pull-request scan keeps feedback close to the developer's change.
• A default-branch scan can cover the full repository with the production build configuration.
• SAST may miss runtime configuration, deployed authentication behavior, and paths it cannot model accurately.