DevSecOps Engineer interview questions

I would build one control plane for identity, policy, provenance, secrets, and evidence, then expose it through native integrations for each delivery stack.

• GitHub Actions, GitLab CI, and Buildkite would call versioned platform workflows that issue workload identities, build once, sign the digest, attach an SBOM, and request promotion.
• A separate verification path at registry promotion and Kubernetes admission would check cosign signatures, provenance, and policy, so a compromised CI job could not approve its own output.
• I would roll out to two representative organizations first, then reach 90% of production services by month six and 98% signed, attested deployments by month nine.
• I would accept slower support for rare build systems in exchange for one trust model, while publishing a manual onboarding path with the same controls.

I would model identities, artifacts, and control decisions as the protected assets, then rank abuse paths by reach rather than produce a generic threat catalog.

• I would diagram trust boundaries among untrusted pull requests, runner hosts, CI control planes, registries, signing services, policy stores, and production deployers.
• The first design review would cover token theft, workflow modification, cache poisoning, artifact substitution, policy bypass, and cross-tenant runner persistence with named preventive controls.
• Public-fork jobs would receive no cloud identity or writable shared cache, while trusted release jobs would run on fresh isolated workers with repository and ref claims enforced in OIDC.
• By week three I would require owners and tests for every critical abuse case, and by week 10 I would demonstrate that all high-risk paths either fail closed or have a documented bounded exception.

I would create a reconciled inventory from deployment facts, source ownership, and CI activity rather than treat the Git provider list as the denominator.

• A daily collector would join registry digests and cluster workloads to repositories, workflow files, owning teams, data classification, internet exposure, and last production deployment.
• Repositories with no deployment for 90 days would remain visible but sit outside the production coverage denominator, while orphaned running workloads would block the owning platform account.
• Teams would correct ownership through a reviewed catalog file, but discovered runtime and registry facts would stay authoritative for what is actually deployed.
• Acceptance would be 99% of production workloads mapped to a repository and owner, under 24-hour inventory lag, and zero unknown tier-one services by day 90.

I would centralize policy and trust metadata but keep builds, secrets, and deployment execution inside isolated tenant data planes.

• The control plane would publish signed workflow versions, policy bundles, trust roots, and promotion decisions without receiving source archives or reusable cloud credentials.
• Each organization would have separate runner pools, Vault namespaces, registry paths, and cloud roles, with repository and environment claims preventing lateral access.
• Promotion would pass immutable digests and attestations across boundaries, not rebuild artifacts or copy bearer tokens between systems.
• I would test 99.9% decision availability, zero cross-tenant access in quarterly isolation tests, and a 30-minute maximum recovery point for policy metadata.

I would make the secure path the fastest supported path and reserve mandatory gates for controls the platform can deliver reliably.

• The paved workflow would include OIDC, pinned builders, cache isolation, SBOM generation, signing, and promotion behind one versioned include with migration tooling for common pipelines.
• I would recruit one high-volume and one regulated team as design partners, then use their queue time, failure rate, and bypass requests to fix friction before wider enforcement.
• Adoption would be measured by production digests built and promoted through the platform, not by repositories containing a template file.
• The quarter-two gate would require at least 85% adoption, under three added median minutes, under 1% platform-caused failures, and an approved plan for the remaining services.

I would fund the shared identity and artifact trust path first because every later control depends on knowing who built what and what is being deployed.

• Months one and two would deliver repository inventory, ephemeral OIDC identities, isolated release runners, immutable digests, and a pilot registry promotion service.
• Months three and four would add cosign provenance, SBOMs, and Conftest checks for the 40 highest-risk services before admission enforcement starts.
• Months five and six would add Vault dynamic credentials and signed admission policies, targeting 90% of production deployments and 100% of tier-one services.
• I would defer broad CNAPP consolidation until these control points produce reliable ownership data, preserving roughly $250,000 for migration and runner capacity.

I would expose four narrow services for identity exchange, artifact attestation, policy decisions, and promotion, and hold every deployment-blocking interface to the platform's 99.9% monthly SLO.

• Stable versioned APIs would return machine-readable reason codes, while GitHub, GitLab, and Buildkite adapters translate native claims and job metadata.
• Product teams would own build logic, while the platform owns identity mapping, attestation schemas, trust roots, and production promotion authorization.
• Asynchronous evidence export would stay off the deployment hot path, so an audit sink failure cannot stop releases.
• By week 16 I would require at least 99.9% monthly API success, p95 policy decisions below 300 milliseconds, and standard repository onboarding in under one hour.

I would make one service catalog authoritative for failure routing and define exactly where platform on-call hands an incident to product on-call.

• The catalog would map repository, service, environment, and control to a primary owner, secondary owner, paging target, and business criticality, with runtime deployment facts overriding stale labels.
• Platform on-call would own identity broker, verifier, policy distribution, and signing availability, while product on-call owns code, dependency, configuration, and service remediation.
• An unacknowledged event would page the primary at five minutes, the secondary at 10, and the platform duty manager at 15, with one incident commander for cross-boundary failures.
• By day 90 I would reduce ownership-SLO misses from 38% to below 5%, route 98% of failures without manual triage, and leave zero tier-0 services without a tested escalation path.

I would standardize on ephemeral workers and common isolation classes while leaving scheduling adapters native to each CI provider.

• Untrusted, normal, privileged-build, and release jobs would use separate accounts, networks, images, instance profiles, and concurrency quotas rather than labels on one shared pool.
• Workers would boot from signed immutable images, accept one job, export logs, wipe ephemeral disks, and terminate, with no inbound administration path.
• Autoscaling would use queue depth and startup latency, keeping p95 queue time under two minutes and warm capacity only for the release class.
• The four-month exit gate would be zero persistent runners, 99% ephemeral-job coverage, and under a 15% compute-cost increase after spot-instance savings.

I would treat fork code as hostile and give it a physically separate runner path with no route to release identities, caches, or control services.

• Fork jobs would run rootless in disposable microVMs with read-only source, allowlisted egress, no writable shared cache, and no CI secrets.
• For a simple GitHub-to-AWS role, IAM can reliably constrain only audience and subject; an environment subject replaces the ref subject, so direct trust cannot authorize repository, ref, workflow, and environment together.
• Trusted deployments would use a protected GitHub environment for ref and approval controls, a centrally owned reusable workflow, and an identity broker that validates repository, ref, job_workflow_ref, and environment before assuming AWS.
• Rootless BuildKit would use isolated cache namespaces, and 50 automated escape and credential-access tests would gate the six-week rollout.

I would make a central workload-identity registry the source of truth for all three CI providers and clouds.

• Each entry would map trusted issuer, audience, and subject patterns to one repository, one environment, and one least-privilege target identity in each required AWS account, Azure subscription, or GCP project.
• A generator would produce native AWS IAM trust policies, Azure federated identity credentials, and GCP Workload Identity Federation provider bindings from that registry; security review and policy tests would gate every registry change.
• CI jobs would use direct federation wherever native claim conditions express the complete rule, with a broker reserved for additional verified context and every resulting session capped at 15 minutes.
• Development, staging, and production identities would remain separate; central audit and revocation would disable mappings across clouds, while acceptance tests across all 350 repositories prove approved paths succeed and cross-repository, cross-environment, wrong-audience, and revoked paths fail.

I would make a signed central promotion manifest the only production authorization and bind it to the exact artifact digest, configuration digest, provenance decision, and target environment.

• Each CI adapter would submit immutable artifact and config digests plus native provenance, while a separate verifier evaluates builder identity, source, materials, and policy version.
• The promotion service would record the verifier decision, environment approver identity, authorization time, expiry, and predecessor manifest in an append-only store before signing the manifest.
• Deployment and admission would accept only the artifact and configuration pair named for that environment, so a CI system cannot rebuild bytes or reuse staging authorization in production.
• I would migrate tier-0, then representative services from each CI, and rollback only to the last valid manifest and its original digests, never to a rebuilt equivalent.

I would remove undeclared network and toolchain inputs from release builds while retaining only caches whose trust is established when each entry is created.

• Dependencies, base images, compilers, and build actions would be pinned by digest and mirrored into an internal repository through reviewed update jobs.
• Release workers would deny internet egress and fail on an undeclared file, environment value, clock dependency, or remote endpoint.
• Cache keys would bind source, lockfile, builder image, and flags, and trusted creation would sign cache metadata containing the producer and content digest.
• Any trust or metadata mismatch would discard the entry and trigger a clean rebuild; the pipeline would never bless or sign the suspect entry after detection.

I would authorize deployments from protected environment policy and verified artifact facts, reserving human approval for high-risk changes rather than every release.

• The deployer would require a protected ref, successful policy decision, approved artifact digest, and an OIDC subject bound to the repository and target environment.
• Routine low-risk promotions would be automatic, while tier-one schema changes, policy exceptions, and first-time services would require two authorized reviewers.
• Build identities could submit candidates but could not promote them, and platform administrators could change policy but could not impersonate product deployers.
• The eight-week target would keep 95% of normal releases approval-free, log 100% of authorization inputs, and deny all 20 tested self-approval paths.

I would combine per-class autoscaling, a small release reserve, and interruptible general capacity instead of sizing a permanent fleet for the peak.

• Release workers would keep enough warm capacity for the p95 load and use on-demand instances, while test pools scale mainly on spot capacity with checkpoint-safe retry.
• Queue fairness would cap noisy organizations and reserve concurrency for 40 tier-one services, preventing one monorepo from consuming the fleet.
• Worker images would be pre-pulled and regional pools would target a 90-second p95 startup, because autoscaling cannot fix a 10-minute boot path.
• I would accept up to 2% retried test jobs to stay under $1.4 million, while requiring p95 release queue time below three minutes during a four-week load test.

I would standardize signed control contracts and evidence schemas, not invent a lowest-common-denominator pipeline language.

• Each provider would get a thin native adapter that obtains identity, invokes the same builder, emits the same in-toto statement, and calls the same promotion API.
• Versioned reference workflows would pin adapter digests, while product teams keep provider-native test and orchestration features outside the trusted release stages.
• Conformance tests would run identical sample repositories through all three systems and compare identity claims, artifact digests, attestations, and denial behavior.
• Quarter-end acceptance would be 80% of releases on 12 or fewer maintained templates, zero semantic drift in 25 control tests, and no mandatory provider migration.

I would use keyless workload signing for connected CI releases and verify exact issuer and subject claims, while keeping managed-key signing only for workloads that cannot use that flow.

• Release jobs would create ephemeral signing keys, obtain short-lived Fulcio certificates from CI OIDC identity, and record entries in Rekor without storing a reusable signing private key.
• Verification policy would bind signatures to protected repositories, workflows, refs, and expected issuers rather than merely checking that any valid certificate exists.
• Trust-root updates and cosign policy versions would roll through staging before production, with a documented managed-key fallback for disconnected builds.
• At week 16 I would require 98% signed production digests, 100% tier-one coverage, and denial of unsigned, wrong-repository, and wrong-issuer samples in admission tests.

I would federate the three native trust domains through one verifier that issues a signed decision about original provenance rather than pretending every builder has one identity format.

• An approved-builder registry would record each issuer, root, builder identity pattern, owner, allowed repositories, predicate version, expiry, and revocation status.
• Provider adapters would verify the native envelope first, then map source, materials, invocation, builder, and output digest into normalized in-toto expectations without rewriting the original statement.
• The verifier would bind its decision to the original attestation digest and policy version, and revocation would immediately reject new decisions from a compromised builder while preserving historical evidence.
• Admission would progress from observe to block by builder cohort, ending with every production digest requiring a valid decision from the approved registry and a tested rollback to the prior verifier policy.

I would publish a versioned TUF-style trust bundle that can carry multiple roots during migration and lets verifiers update them without trusting the artifact producer.

• The bundle would contain Fulcio, Rekor, private CA, and KMS public trust material plus issuer constraints, validity windows, revocation status, and environment scope.
• Root changes would require threshold approval from security and platform owners, be signed offline, and overlap old and new verification paths for at least 60 days.
• Archived artifacts would retain signatures, certificate chains, timestamps, and transparency proofs needed for verification after online services or identities change.
• By month six every verifier would consume the bundle within 24 hours, 100 historical samples would verify offline, and removal of one compromised root would not disable unrelated units.

I would keep one attestation and verification contract but allow different approved signing backends for connected and disconnected trust zones.

• Connected CI would use OIDC keyless signing with Fulcio and Rekor, while disconnected builders would use non-exportable HSM or private KMS keys with tightly scoped signing identities.
• The offline zone would receive signed trust-root and policy snapshots through a controlled transfer, then return artifacts, SBOMs, provenance, and signatures through the same reviewed boundary.
• Verifiers would require the signer class allowed for that source and environment, so an offline key could not sign a connected service or bypass transparency requirements.
• Month-four acceptance would be 100% tier-one coverage, trust snapshots under seven days old, and offline verification of 50 artifacts without network access.