DevOps Security Interview Questions for 2026

Answer: Every identity, human or machine, gets the minimum permissions needed for its current job, and nothing more. In practice that means roles instead of shared accounts, scoped actions on specific resources instead of wildcards, and expiry on everything. The consequence interviewers want: when a credential leaks, the blast radius is the scope of that identity, so least privilege is leak insurance. It is the first concept almost every set of DevOps security interview questions builds on.

Answer: A secret is any credential that grants access: passwords, API keys, tokens, private keys, connection strings. Git is forever: removing a key from the latest commit leaves it in history, in forks, and in every clone, so treat a pushed secret as compromised the moment it lands. Secrets belong in a vault or secret manager that the pipeline reads at runtime, with scanning on commits to catch slips early.

Answer: Authentication proves who you are, authorization decides what you may do. A valid login that still cannot touch the payments database is authentication passing and authorization refusing. The operational point: they fail differently, so debugging starts by identifying which half rejected the request, from the auth logs or the policy decision, before touching anything else.

Answer: Layering multiple independent controls so one failure does not become a breach: MFA in front of strong passwords, network rules behind authentication, scanning behind code review. Each layer assumes the previous one eventually fails. Interviewers like the consequence more than the definition: depth is why a single missed patch or phished password should be survivable, and why it is suspicious when one control is all that stands between the internet and production.

Answer: The cloud provider secures the underlying infrastructure, the physical datacenters, network, and hypervisor, while you secure what you put on it: IAM configuration, data classification, encryption choices, patching of guest systems and application dependencies. The classic failure is assuming the provider covers your side, which is exactly how misconfigured storage buckets become breaches. Public breaches are overwhelmingly customer-side, which is the sentence interviewers wait to hear.

Answer: Hashing is one-way: it produces a fingerprint you cannot reverse, used for verifying integrity and storing passwords. Encryption is two-way with a key: reversible by design for anyone holding the key. Encoding like base64 is not security at all, just representation, and any answer that calls base64 encryption is an automatic fail. That three-way distinction opens many DevOps security interview questions because it sorts experienced candidates fast.

Answer: A salt is random data mixed into each password before hashing, so identical passwords produce different hashes. Without one, attackers use precomputed rainbow tables, and identical hashes reveal identical passwords across the whole database. Modern password hashing, bcrypt or argon2, salts automatically and is deliberately slow, which is why storing passwords with fast general-purpose hashes like plain SHA-256 is a finding, not a style choice.

Answer: TLS gives you encryption in transit, server identity verification through its certificate, and integrity so traffic cannot be modified unnoticed. It does not protect a compromised endpoint, does not care who your application authenticates at the application layer, and does nothing for data at rest. The padlock means the pipe is secure, never that either end is, and that distinction closes many basic DevOps security interview questions about HTTPS before they start.

Answer: A signed document binding a public key to an identity, a domain name or service account, plus validity dates and the issuing certificate authority. The signature chain is the point: your browser trusts the root CA, the root signed the intermediate, the intermediate signed the server certificate, so trust transfers down the chain. Certificates expire by design, which is why expiry monitoring and automated renewal are basic operational hygiene.

Answer: A certificate the sender signed itself, so nothing external vouches for the identity it claims. It is acceptable inside a closed system where you control trust: an internal CA whose root you distribute, a service mesh issuing workload certificates, a lab. It is never acceptable for public endpoints, because users get either a warning they learn to click through or an insecure habit. The follow-up is usually about how trust gets distributed, so mention the root CA.

Answer: A certificate issued for *.example.com, valid for every single subdomain at that level. The convenience is real; so is the concentration of risk: one private key that works for every subdomain, so wherever that key lives, its compromise hands over api.example.com and admin.example.com together. Reasonable practice is scoping wildcards to one environment or team and knowing exactly which hosts hold copies of the key.

Answer: Keys are long, randomly generated, never typed, and never transmitted, while passwords are guessable, phishable, and reusable across systems. With keys, the client proves possession of the private key and the server checks the matching public key, so the secret itself never crosses the wire. Disable password authentication on servers entirely and the brute-force noise in your logs stops mattering. Key passphrases still matter, because a stolen unencrypted private key is a stolen login.

Answer: Direct root login removes accountability and gives attackers a known username to target, so hardening disables it and requires an unprivileged account plus sudo or role elevation. You gain two things: an audit trail that names the human, and a second gate, because stealing one key no longer yields root. Nearly every CIS-based server baseline includes this control, which is why it appears so often in DevOps security interview questions about hardening.

Answer: A single hardened entry point for administrative access to a private network: everything else denies inbound SSH, and you reach internal machines only through the bastion. Its value is concentration of monitoring and control: one place to enforce MFA, log sessions, and patch. The tradeoff is that it becomes the crown jewel, so it gets the strictest configuration in the fleet. Cloud identity-aware proxies are the managed evolution of the same idea, a comparison DevOps security interview questions often ask you to draw.

Answer: A rule-based filter that permits or blocks traffic between network zones, at the host with nftables or iptables, or at the network edge. The correct default policy is deny inbound by default and allow by explicit rule, because allow-by-default means every forgotten port is open forever. Interviewers usually add one twist: rule order matters, first match wins on most firewalls, so a broad early allow silently disables your later restrictions.

Answer: A stateful virtual firewall attached to an instance or interface: inbound rules and outbound rules evaluated as a group, and return traffic allowed automatically once a session starts. The operationally important behaviors: changes apply immediately with no reboot, and best practice is referencing other security groups as sources instead of raw CIDR ranges, so access follows the workload rather than an IP that gets reused. Open security groups to the world on sensitive ports are the most common cloud audit finding.

Answer: A port where something is listening and, worse, a port reachable from networks that should not reach it. On the host, ss -tulnp lists listeners with their owning processes; from outside, nmap -p- target probes what is actually reachable, which is the view attackers have. The difference between those two views is your exposure, and closing it is routine. Unowned listeners are how forgotten debug interfaces end up in breach reports, which is why exposure questions open so many DevOps security interview questions in screening calls.

Answer: Telnet, FTP, and plain HTTP transmit credentials and data in clear text, so anyone on the path, a rogue access point, a compromised router, a packet capture, reads everything. The replacements are drop-in: SSH for Telnet, SFTP for FTP, HTTPS for HTTP, all preserving the workflow while encrypting the pipe. Interviewers use this to check whether you notice protocol choices as security decisions, and plaintext survivors lingering in cron jobs are a staple war story behind DevOps security interview questions.

Answer: HTTP Strict Transport Security, a response header instructing browsers to refuse plain HTTP for that domain and to remember the instruction for the max-age period. It closes the downgrade window where an attacker forces the first request over HTTP to strip TLS. The operational caveat: enabling it with a long max-age is a commitment, because a domain that later needs plain HTTP looks broken to every browser that cached the policy. Preload lists are the strongest form and the hardest to leave.

Answer: A CVE is a public identifier for one specific vulnerability, so teams can track, prioritize, and communicate about the same flaw without ambiguity. Read the affected versions list first, because most scanner noise is version-range over-matching, then the fixed-in version, which tells you the remediation, then the description for exploitation conditions. In DevOps security interview questions, quoting a CVE you actually handled, with the affected component and how you remediated it, turns this definition into a credibility moment.

Answer: A 0 to 10 severity rating built from vectors like attack vector, complexity, privileges required, and impact on confidentiality, integrity, and availability. It measures theoretical severity, not your risk: a 9.8 in an unused library on an isolated host may matter less than a 7.5 on your internet-facing gateway. The professional answer uses CVSS for ordering within a stack of findings, then adjusts for exploitability and exposure, which is exactly the judgment the question is fishing for.

Answer: Patching applies security and bug fixes within a version line, low risk, frequently automatable, and expected on a defined SLA. Upgrading moves to a new major version with new behavior, deprecations, and migration work. Confusing them in an answer suggests you have never managed either under an audit. A sensible posture: patches ride an automated cadence, upgrades are planned projects, and emergency patching for actively exploited CVEs has its own fast lane.

Answer: The span between initial compromise and detection, often measured in weeks or months, which is the window an attacker has to move laterally and stage persistence. Its lesson drives the monitoring half of this page: detect fast by logging the right events, and shrink the window by reducing what a single compromised credential can do. When interviewers bring up dwell time, the answer they want connects detection and blast radius, not statistics.

Answer: Multi-factor authentication requires a second proof beyond the password: a TOTP code, a hardware key, or a push approval. It defeats the password-only attacks that dominate real breaches, credential stuffing, phishing of passwords, reused credentials from other breaches. It does not stop session theft, where the attacker takes the authenticated cookie, and push-bombing shows factor quality matters: hardware keys resist phishing better than approval taps. Expect a follow-up asking which factors you would require for admin access.

Answer: Attackers replay username and password pairs stolen from other breaches against your login, betting on password reuse. Defense is layered: MFA, breached-password screening at signup and login, rate limiting per account and per source, and bot detection on authentication endpoints. The uncomfortable fact interviewers want you to own: stuffing works even when your security is perfect, because the compromise happened somewhere else, so your design has to assume breached passwords arrive at your door. Breach-data reuse is the premise behind many DevOps security interview questions about login defense.

Answer: Social engineering that tricks a user into entering credentials on a fake page or running a malicious attachment. Technical defenses reduce the blast radius: MFA, preferably phishing-resistant hardware keys, mail authentication with SPF, DKIM, and DMARC, and click-time link checking. The ops-specific angle: phished operator credentials are worse than phished user credentials, so admin access gets scoped roles and just-in-time elevation, and that pairing is a recurring theme in DevOps security interview questions about humans as the attack surface.

Answer: Role-based access control assigns permissions to roles and membership to people, so access is managed by job function instead of per user. Its security value is reviewability: an auditor reads eight role definitions instead of eight hundred individual grants, and drift becomes visible. Its failure mode is roles that accrete permissions over years until someone is, effectively, an admin. The fix, periodic access reviews and splitting god-roles, is the natural follow-up DevOps security interview questions ask here.

Answer: A static credential a client presents to an API, an access key ID with its secret, a personal access token, an API token. Long-lived keys are a liability because they never expire on their own: a leaked copy works until a human notices and revokes it, and humans notice slowly. Prefer short-lived session credentials assumed through roles, and where static keys are unavoidable, rotate them on a schedule, scope them narrowly, and alert on their use from unexpected sources.

Answer: The starting filesystem your image builds on, and every package in it is attack surface: more libraries means more CVEs to scan, patch, and explain, and more tools an attacker can use after compromising the container. Minimal bases like alpine, distroless, or scratch shrink the count dramatically; a shell-less runtime image cannot run an interactive attacker session at all. Smaller images also rebuild and repatch faster, which is the operational point DevOps security interview questions usually push toward.

Answer: Tools like Trivy or Grype inventory every package and library in an image, match that inventory against vulnerability databases, and report findings with severity and fixed versions. Run it in CI so a red build blocks a vulnerable image from the registry, and re-scan images in registries on a schedule, because CVEs are published against images that were clean last week. The honest caveat for interviews: scanners over-report, so triage by reachability and exposure rather than fixing every line of a report.

Answer: A community-maintained hardening baseline for a specific technology, from Ubuntu to Kubernetes to individual cloud services, listing configuration recommendations with rationale and scoring levels. It matters operationally because it turns “secure the server” into a checklist you can automate, verify with tools like OpenSCAP, and audit against. Naming the benchmark for your platform and saying you enforce it as code, not by hand, is the detail that lifts this answer above memorization.

Answer: A record of who did what, to which resource, when, and from where. Usefulness has four properties: completeness, the action you need was actually logged; integrity, it cannot be edited or deleted by the people it watches; centralization, it survives the compromise of any single host; and searchability, you can answer “who touched this bucket last Tuesday” in minutes. Without those properties you do not have auditing, you have logs, and that distinction is a favorite probe in DevOps security interview questions about monitoring.

Answer: Three copies of the data, on two different media or platforms, with one copy offsite. The modern extension is 3-2-1-1-0: one copy immutable or offline, and zero errors verified by actual restore tests. The immutable copy is the ransomware answer, because encryption that propagates to online backups cannot touch an object store tier with deletion protection. Saying the rule and the why behind each number is the expected shape of the answer, and ransomware variants of it now anchor a whole family of DevOps security interview questions.

Answer: Labeling data by sensitivity, public, internal, confidential, restricted, so controls can scale with the label instead of treating every byte alike. It drives encryption requirements, access scope, retention, and logging depth, and it is what lets you answer “where does our customer PII live” during an incident instead of after it. Skip classification and every control is either uniform overkill or uniformly absent; that tradeoff framing is what DevOps security interview questions here are really grading.

Answer: A vulnerability is a weakness, an unpatched library or an over-broad policy. A threat is an actor or event that could exploit it, ransomware crews, a rogue insider, a disk failure. Risk is the combination, likelihood times impact, and it is what you actually manage: you can rarely remove every vulnerability, so you prioritize the ones with credible threats and expensive impact. That triad opens many DevOps security interview questions because prioritization is the daily job.

Answer: Dividing a network into zones so a compromise in one cannot roam freely through the rest: separate subnets or namespaces for databases, applications, and administration, with explicit rules for the traffic allowed between them. The mechanism varies, firewall zones, cloud security groups, Kubernetes NetworkPolicies, but the goal is constant: lateral movement dies at a boundary. Flat networks are why one phished laptop becomes a domain-wide incident, which is the consequence interviewers want stated plainly.

Answer: It watches log files for patterns like repeated authentication failures and updates firewall rules to ban the offending source for a configured time. It is cheap, effective noise reduction for internet-exposed SSH, and its pattern-action design generalizes to other services. Worth adding for credit: banning addresses is symptom relief; the real fix is key-only authentication, MFA on any web login, and management ports behind VPN or identity-aware access so the noise never reaches you.

Answer: Moving security checks earlier in delivery, from a pre-release gate into the pull request: secret scanning on every push, dependency review on every dependency bump, infrastructure policy checks in the plan stage. The economics drive it: the author still has full context at commit time, so a fix costs minutes, while the same flaw found in production costs an incident and a war room. Almost all modern DevOps security interview questions about CI assume you think this way, so frame the answer in costs and context, not tools.

Answer: The client and server agree on parameters, the server presents its certificate chain, the client validates that chain against its trust store and checks the hostname, then they perform an ephemeral key exchange, ECDHE in modern TLS 1.3, to derive session keys that never cross the wire. Ephemeral keys give forward secrecy: a later compromise of the server’s private key cannot decrypt past sessions. Diagnosing a failed handshake starts with openssl s_client -connect host:443 -servername host, which shows exactly which validation step refused, a trick that pays for itself across many DevOps security interview questions about TLS.

Answer: The server sends its leaf certificate plus intermediates; the client checks each signature against the issuer’s public key, verifies validity windows and hostname, checks revocation state, and continues until it reaches a root already in its trust store. A missing intermediate is the classic operational failure: the leaf is fine, but the client cannot build the path, so every client that lacks a cached copy fails. openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem reproduces the walk locally.

Answer: Two mechanisms: CRLs, signed lists of revoked serials that clients download, and OCSP, per-certificate status queries. Both fail soft in most clients, on network error browsers typically accept the certificate, because hard-fail revocation checking would break the web. Short-lived certificates, automated by ACME with 90-day or shorter lifetimes, sidestep the problem: validity windows shrink the value of a stolen key. Saying that tradeoff explicitly is what interviewers want from DevOps security interview questions on PKI.

Answer: An ACME client like certbot generates a key pair, proves control of the domain to the CA by answering a challenge, an HTTP token on port 80 or a DNS TXT record, then downloads the signed certificate. The same client renews before expiry and reloads the web server, so certbot renew on a timer plus a deploy hook replaces the manual ceremony entirely. The operational caveat: DNS-challenge issuance covers wildcard names but requires API credentials to your DNS provider, and those credentials become secrets the vault must manage.

Answer: Mutual TLS: both sides present certificates and validate each other, so the connection authenticates the client as well as the server. It is the backbone of service-to-service identity in service meshes, where a sidecar issues and rotates workload certificates automatically and revokes them by stopping renewal. Earn it where identity per caller matters: east-west traffic between services, admin APIs, database connections. Its cost is certificate lifecycle management, which is exactly why platforms automate it rather than asking every application to do it.

Answer: Instead of pinning each public key into each server’s authorized_keys, an internal CA signs user keys into short-lived certificates carrying principals and options, and servers trust only the CA’s public key. Access becomes time-boxed and centrally revocable: stop issuing certificates and every outstanding one dies within its validity, hours at most. The operational win over keys-on-servers is onboarding and offboarding at scale, which is why this mechanism increasingly replaces authorized_keys in serious fleets and shows up in DevOps security interview questions about access at scale.

Answer: A vault is a service that stores secrets encrypted under keys held by a KMS or HSM, unlocks itself on boot through unseal quorum or auto-unseal, authenticates every reader through methods like tokens, cloud identity, or certificates, and enforces policies mapping identities to paths and capabilities. Every read is an auditable event, and features like dynamic secrets and leases come from that enforcement layer. The interview point: a vault is not encrypted storage, it is an access broker whose value is authentication, authorization, and audit on every secret read.

Answer: Dynamic secrets are generated on demand: the vault creates a database user with scoped grants, hands it over, and destroys it when the lease expires, minutes or hours later. Nothing long-lived exists to leak, and each checkout is attributable to one workload. Static secrets still exist, vendor API keys you cannot generate on demand, but the design goal is minimizing them. Expect the follow-up about cost: dynamic credentials churn connections, so applications need pools that tolerate re-authentication.

Answer: You rotate by overlap, never by cutover: create the new credential, deploy consumers that can use either, wait for the old credential to drain from every long-lived process and cached session, then revoke the old one and watch for errors. Databases need dual-user rotation, cloud keys need a quiet monitoring window after revocation, and anything that caches credentials in memory needs a restart or a re-read signal. The failure mode this sequencing avoids is the midnight page: revoke first, discover the reader you forgot, and production cannot authenticate.

Answer: The CI system signs a short-lived JWT identifying the repository, workflow, and ref; the cloud provider trusts that issuer through an OIDC role trust policy and returns temporary credentials for one job. No key is ever stored, so there is nothing to leak from settings or logs, and trust can be scoped to specific repos and branches, which is the mechanism modern DevOps security interview questions expect you to name for pipeline auth. It is the modern default for pipeline authentication and one of the clearest signals of maturity in DevOps security interview questions about CI/CD: a candidate who mentions OIDC unprompted has operated modern pipelines.

Answer: A policy is a list of statements, each with an effect, allow or deny, actions, resources, and optional conditions. Conditions are the least-privilege workhorse: restrict by source IP, require MFA, bind access to resource tags like owner or environment, or enforce TLS-only transport. The craft interviewers probe is scoping resources instead of using wildcards, because Resource: "*" turns a useful grant into a breach multiplier, and wildcard hunting is a whole genre of DevOps security interview questions. Reading policies aloud, statement by statement, is a skill; write them with the same discipline.

Answer: A principal calls the token service with a role ARN; the service evaluates the role’s trust policy against the caller, and on success returns temporary credentials with an expiry, typically under an hour, plus a session identifier that appears in audit logs. Safety comes from three properties: credentials expire without human action, each assumption is a logged event linking activity to identity, and trust is explicit, so an unknown principal cannot adopt the role at all. Long-lived keys have none of those properties, which is the sentence this question exists to produce.

Answer: Both are ceilings, not grants. A permission boundary caps the maximum permissions an identity can ever hold even as its own policies change, useful when teams manage their own roles. SCPs sit above entire accounts in an organization and deny what no principal inside may do, regardless of local policy: regions you never use, account-wide wildcard actions, leaving the organization. The mental model: ordinary policies grant, these frameworks cap, and effective designs use both so mistakes inside a team cannot become organization-wide exposures.

Answer: Workload identity binds a cloud IAM identity to a specific workload, a service account in Kubernetes or an instance profile on a VM, so the application gets temporary credentials from its environment with no secret stored anywhere. In Kubernetes this is an annotation linking the service account to an IAM role, with a token projected into the pod that the cloud exchanges for session credentials. It removes the largest single class of leaked-credential incidents, and saying that plainly is a strong answer to many DevOps security interview questions about secrets in clusters.

Answer: Attribute-based access control makes decisions from attributes of the requester, the resource, and the environment, commonly by matching tags: a principal tagged team=payments can manage resources tagged team=payments in env=staging. It wins where resources churn constantly, hundreds of services and environments, because policy is written once and new resources inherit access through tags automatically. RBAC wins where roles are stable and reviewability matters most. Most mature setups use both: roles for humans, tag-based rules for machines.

Answer: Standing admin rights are replaced by elevation on demand: an operator requests a role, an approval flow or policy grants it for a bounded window, every action inside the window is logged, and it expires automatically. The mechanism is usually role assumption with short sessions plus an approval layer. The security math is simple: standing access means every stolen laptop is an admin at any hour, while JIT shrinks both the window and the population holding power at any instant. Audit findings about dormant admin accounts are JIT’s entire reason to exist, which is why DevOps security interview questions about privileged access keep landing here.

Answer: Namespaces isolate views: pid, network, mount, user, IPC, UTS; cgroups cap resources. What containers share is the host kernel, one kernel, no hypervisor boundary, so a kernel vulnerability is potentially a container escape, and a privileged container with a host mount is effectively root on the host. That is why hardening leans on user namespaces, rootless runtimes, and seccomp filters rather than on namespaces alone. Interviewers use this question to route candidates: knowing the boundary is what separates container operators from engineers, and it anchors the container half of DevOps security interview questions.

Answer: Default dockerd or containerd configurations already drop most of Linux’s ~40 capabilities, keep a default seccomp profile blocking dangerous syscalls, and can apply AppArmor or SELinux profiles. Hardening goes further: --cap-drop=ALL then add back only what the app proves it needs, --read-only root filesystem with explicit writable volumes, --security-opt no-new-privileges to block setuid escalation inside the container. In Kubernetes the same knobs live in a securityContext, and a Pod Security profile enforces them fleet-wide.

Answer: Root inside the container is root against the kernel for anything namespaces do not isolate, so a container escape from a root process lands with UID 0 on the host, while a non-root escape lands as a low-privilege user the kernel still polices. A read-only root filesystem removes the attacker’s ability to write binaries, modify the application, or establish persistence through the image layer; writes go to declared volumes only. The cost is small, applications need their temp and cache paths mounted writable, and the payoff is removing entire attack classes, a tradeoff DevOps security interview questions love to hear you walk through.

Answer: Every instruction creates a layer, and layers persist in the image even when a later instruction deletes the file: RUN echo $TOKEN > /creds && rm /creds still ships the token in the lower layer, recoverable with two docker history and export commands. Build args are worse, they embed values in metadata visible to anyone with the image. The fixes: mount secrets at build time via BuildKit secret mounts, inject credentials at runtime from a vault or orchestrator, and keep a secrets scanner in CI as the backstop. Layer mechanics like this are a reliable differentiator in DevOps security interview questions about images.

Answer: Distroless images ship only your application and its runtime dependencies: no package manager, no shell, no coreutils. You lose debuggability by exec, no sh to shell into, though ephemeral debug sidecars based on the same image restore it, and some applications need build-time adjustments to run without a libc they assumed. The security return is large: a dramatically smaller CVE list, no interactive foothold for an attacker, and faster, smaller supply chain to verify. The tradeoff conversation is exactly what interviewers want to hear on this topic.

Answer: At publish, CI signs the image digest with a key bound to an identity, cosign with Sigstore keyless signing tied to the pipeline’s OIDC identity is the common pattern. At deploy, an admission controller verifies the signature and refuses anything unsigned or signed by an unexpected identity. This closes the last unauthenticated hop: even an attacker who pushes a malicious tag to your registry cannot get it scheduled. Digest-pinning plus signature verification together give you provenance, and that word, provenance, is what DevOps security interview questions on supply chain are really listening for.

Answer: A software bill of materials is a machine-readable inventory of every component in an artifact, in SPDX or CycloneDX format, generated at build time by tools like syft or trivy image –format cyclonedx. Its value arrives later: when the next big CVE lands, you query SBOMs to answer “where do we run log4j” across the fleet in minutes instead of days, and buyers increasingly demand them contractually. Generate per image, store beside the artifact, and actually run the query drills; an SBOM nobody can search is shelfware, and proving you run the drills is the edge in DevOps security interview questions on this topic.

Answer: Software composition analysis parses lockfiles and package metadata, resolves the full transitive dependency tree, and matches versions against advisory databases like OSV, mapping each finding to fixed versions. Over-reporting happens because version ranges are broad, because transitive vulnerabilities may sit in code paths your application never executes, and because scanners cannot see your runtime. Mature teams add reachability filtering and exploit intelligence, then track the residual findings to a burn-down SLA. Explaining false-positive economics well is a hallmark of strong DevOps security interview questions answers at this tier.

Answer: SAST reads your source for insecure patterns, injection sinks, hardcoded credentials, and runs in the pull request where fixes are cheap. DAST attacks the running application from outside, probing requests and responses like a scanner-borne attacker would, catching what static analysis cannot see, misconfigurations and runtime behavior. SCA covers your dependencies, which in modern applications are most of the code. They overlap deliberately: each one’s blind spot is another’s strength, and pipeline design places all three where their input exists.

Answer: Scanners like gitleaks or trufflehog apply regex patterns for known credential formats, entropy analysis for high-randomness strings, and provider-specific validators that test whether a found token is still live. Run on pre-receive or in CI so a blocked push happens while the author still has the terminal open, and run periodic history scans across the organization because legacy leaks predate your tooling. Allowlists need governance: an allowlist entry is a documented decision to ship something that looks exactly like a leak.

Answer: Admission webhooks sit between authentication and persistence: every object write passes through them, and they can validate or mutate, reject or fix. The high-value policies: refuse privileged pods and hostPath mounts outside an allowlist, require non-root and dropped capabilities, require resource limits so one workload cannot starve the node, require images from the internal registry with valid signatures, and label workloads for ownership so accountability exists at incident time. Tools like Kyverno and OPA Gatekeeper express these as code, so policies get review, tests, and versioning like everything else, which is the maturity signal DevOps security interview questions about clusters hunt for.

Answer: In Kubernetes, pods without any selecting NetworkPolicy accept traffic from anywhere in the cluster, default allow, which makes east-west movement free for anyone who lands on any pod. The fix is a default-deny ingress and egress policy per namespace, then explicit allows for each real dependency: frontend may reach backend on its port, backend may reach its database, DNS egress allowed explicitly because everything breaks without it. Roll out per namespace, watch for breakage, and treat unexplained connectivity as a bug, because it usually is one.

Answer: Egress filtering restricts outbound traffic: workloads may reach documented dependencies and nothing else. It is forgotten because ingress feels like the perimeter and egress feels like someone else’s problem, yet most real intrusions depend on outbound channels, exfiltration, command and control, downloading tooling. Lock egress through a proxy or NAT gateway with domain and port allowlists, log denied flows, and alert on them, because denied egress from production is one of the highest-signal detections you can own. Data exfiltration over an unfiltered egress path is how quiet compromises become reportable breaches, and that framing is exactly what scenario-flavored DevOps security interview questions reward.

Answer: A network firewall filters on addresses, ports, and protocols; a WAF understands HTTP, inspecting requests for injection patterns, known exploit signatures, bot behavior, and rate abuse at layer 7. It sits in front of web applications, cloud-managed or self-hosted like ModSecurity, and its realistic value is buying time: virtual patching a known application CVE while the real fix ships. It is not a substitute for secure code, and saying so, with the managed-rules-plus-tuning caveat, is what separates experience from buzzword bingo in DevOps security interview questions about web defense.

Answer: Concretely: no network location is trusted by default, so every request is authenticated, authorized, and encrypted regardless of where it originates, and access is granted per application rather than per network segment. The mechanisms are identity-aware proxies in front of internal apps, mTLS between services, device posture checks, and short-lived credentials everywhere. The honest framing for DevOps security interview questions: zero trust is an architecture direction, not a product you buy, and the first real milestone is deleting the flat corporate network’s implicit trust, not the slide about it.

Answer: Tools like OpenSCAP, kube-bench, or cloud security posture managers map each CIS recommendation to concrete checks: file permissions on sensitive paths, SSH options, password policies, kernel parameters, API server flags in Kubernetes, public exposure of cloud storage. Output maps to the benchmark’s scored sections, so you get a pass rate and a worklist. The operational pattern that matters: encode checks as code, run them on a schedule and in CI for images and configs, and treat drift alerts as findings. Manual quarterly audits decay; automated ones compound.

Answer: FIM watches designated files and directories for changes and reports who changed what, when, implemented by tools like AIDE via baseline hash databases compared on a schedule, or by kernel-level watchers like auditd file watches for real-time events. Scope it to what matters: system binaries, critical configs, the SSH authorized_keys tree, web roots. Its security role is detecting tampering, a replaced binary, an added key, a modified cron entry, all classic persistence moves that scenario DevOps security interview questions build their stories around. Alert noise kills FIM deployments, so baselines must update through the same controlled pipeline as the files themselves.

Answer: Auditd is the kernel’s syscall-level audit framework: rules define which syscalls, users, files, or executables produce events, written to a log that SIEM platforms consume. High-value rules: execution of setuid binaries and privileged commands, writes to identity files like passwd and authorized_keys, use of the immutable attribute, logins and sudo, and time changes. The caveat interviewers like: syscall auditing is verbose, so scope rules narrowly or you will log gigabytes and detect nothing. Pair it with centralized shipping, because local audit logs are the first thing an attacker silences, a point that recurs in DevOps security interview questions about forensics.

Answer: Ship logs off-host in near real time to centralized storage the workloads cannot write to, so clearing local logs leaves the central copy intact. Add retention controls: object lock in compliance mode, append-only storage, or write-once log platforms, plus integrity verification through hashing or chained signatures. Restrict deletion rights to a separate break-glass identity, and alert on logging pipeline failures, because an attacker who can stop your shipping can hide in the gap, which is the exact scenario DevOps security interview questions about evidence chain probe. The design question interviewers attach to this: who can turn off your evidence, and how would you know if they did.

Answer: SAML is XML-based, mature, and dominant in enterprise web SSO; OIDC is JSON over OAuth 2.0, lighter, mobile- and API-friendly, and dominant in cloud-native stacks. Both delegate authentication to an identity provider so applications stop storing passwords, which centralizes MFA, offboarding, and session policy in one place. The ops-relevant details: certificate and key rotation on the IdP breaks logins when expired, and clock skew or metadata drift produces the classic “SSO worked yesterday” incident. Knowing which side owns which failure is the working depth DevOps security interview questions test here, because SSO outages page ops, not the IdP vendor.

Answer: The OWASP Top 10 is a periodically refreshed list of the most critical web application security risk categories: injection, broken access control, cryptographic failures, misconfiguration, vulnerable components, and so on. Ops owns several directly: security misconfiguration, default credentials, verbose errors, directory listings, overly permissive CORS; vulnerable and outdated components, which is your patching pipeline; and identification and authentication failures, where your MFA and session policy live. Injection belongs to developers, but its detection, WAF signals, and log evidence belong to you. Citing two or three categories with the control you run for each is the answer shape that lands.

Answer: When a proxy and the backend disagree about where a request ends, one honoring Content-Length, the other Transfer-Encoding, an attacker can smuggle a second request inside the first, poisoning queues and hijacking other users’ responses. The same class of bug covers header spoofing: proxies that forward client-supplied X-Forwarded-For or Host headers unchecked let callers forge identity signals your application trusts. Fixes are unglamorous and specific: normalize or reject ambiguous headers at the edge, pin which hop headers the proxy owns, and keep versions current, because this is a known CVE family. It is a favorite deep cut in DevOps security interview questions because it proves you read advisories.

Answer: Rate limiting caps requests per identity, per IP, or per endpoint window, implemented at the edge, a gateway or proxy with token bucket or sliding window counters. Design it in tiers: a generous global ceiling, tighter per-key limits, and strict caps on authentication and password-reset endpoints where abuse is an attack in itself. Return 429 with a Retry-After header so well-behaved clients back off, and log which limit fired, because sustained 429s are either an integration bug or an attack, and your logs should tell you which.

Answer: Immutable infrastructure treats running servers and containers as disposable: changes produce new artifacts that replace old ones, and nothing is patched in place. Security gets three properties from that: no configuration drift for attackers to exploit and auditors to find, no long-lived snowball servers accumulating years of manual changes, and clean rollback, because the previous artifact still exists. Persistent state moves to managed data services with their own hardening. The caveat interviewers expect: immutability raises rebuild cadence requirements, so patching now means rebuilding often, which your pipeline must do quickly and routinely.

Answer: Minute zero: assume compromise, because bots scan public pushes within seconds. Revoke or rotate the credential first, before investigating anything, since revocation stops the bleeding and costs nothing. Then assess scope: which systems that credential touched, and audit its use from the provider’s logs, looking for access from unfamiliar sources after the push time. Force-push removal and history scrubbing are hygiene, not remediation, since clones and forks already exist. Close with the systemic fix: the leak should have been caught by a pre-commit or CI secrets scanner, and the credential should have been short-lived, so this becomes a control gap ticket, not just a cleanup. That revoke-first ordering is the single most tested sequence in scenario DevOps security interview questions.

Answer: First contain: block the destination at the egress firewall and isolate or terminate the runner, snapshots first if the platform allows, because a runner holds secrets in memory and on disk. Then determine entry: recent workflow runs, dependency versions in those builds, unfamiliar pull requests, or a compromised cache or action. Rotate everything the runner could read: cloud credentials, registry tokens, deploy keys, environment secrets, assuming exfiltration rather than hoping. Rebuild the runner from a clean image, not a repair. The lasting fix is blast-radius design: ephemeral runners, OIDC instead of stored cloud keys, and egress allowlists, because a runner that cannot phone out cannot ship your secrets out. This progression, contain, assess entry, rotate, rebuild, redesign, is the standard answer arc for compromised-runner DevOps security interview questions.

Answer: Close the door first: disable public access at the bucket and, better, at the account level with block-public-access, so one misconfiguration cannot recur. Then the question that decides severity: was it accessed? Pull CloudTrail data events for the bucket, look for unauthenticated GETs, unusual volumes, and unfamiliar source IPs and user agents, because a public bucket nobody found is a near miss, while a harvested one is a breach with notification obligations. Fix the mechanism that allowed it: default encryption, explicit deny policies for public principals, and IaC guardrails that fail a plan containing public ACLs. Be honest about the legal dimension: confirmed access to personal data means your privacy officer gets involved, not just your on-call rotation, and that consequence is precisely what exposed-bucket DevOps security interview questions are checking you understand.

Answer: Triage before acting: is the affected component present, reachable, and exploitable in your context? Check the fleet with your inventory or SBOMs, then reduce exposure while you wait for the fix, which is the actual answer being tested: disable the vulnerable feature if it has a switch, restrict network reachability to the component, add virtual patching at the WAF or proxy for known exploit patterns, and raise monitoring on the affected paths. Track vendor advisories on a cadence, and pre-write the rollback criteria for any workaround you applied. Interviewers are checking whether you understand that patch management includes the gap between disclosure and patch, which is where exploitation actually happens. “We wait for the patch” is the failing answer.

Answer: First establish what that identity actually did: query audit logs for the principal’s history, because the finding is a loaded weapon and you need to know whether it fired. Scope the replacement before removing anything, build the least-privilege policy from the logged actions plus the stated job, and overlap briefly so the service does not break on cutover. Then widen the search: one wildcard policy usually means the tooling or template that created it produced others, so scan the whole account and add an IAM policy linter to CI so wildcards fail review at plan time. Mentioning access analyzer tooling and the break-glass exception, documented and monitored, shows you have done this in production rather than only in DevOps security interview questions.

Answer: Contain first: isolate the host at the network layer, disable the compromised account, and block known command-and-control destinations, because encryption is usually the payload’s final act, not its first. Assess scope across shares and hosts, and check for lateral movement using authentication logs before assuming one machine. Declare an incident and involve leadership and legal early, since ransom demands and disclosure are decisions above ops. Do not touch the encrypted host beyond volatile evidence capture. Recovery comes from the immutable or offline copy, and only after the entry point is found and closed, because restoring into the same foothold burns the clean backup. The timeline, isolate, assess, escalate, eradicate, restore, verify, then report and rehearse, is precisely what ransomware-flavored DevOps security interview questions are scoring.

Answer: Treat it as leaked, because chat export limits, integrations, and retention make “we deleted the message” insufficient. Rotate the credential first, using the overlap pattern so applications re-authenticate without downtime, then audit connections to the database from unexpected sources around the exposure window. Sweep for the same secret elsewhere: it probably exists in dotfiles, ticket text, and old deployments if it was pasteable, and a secrets scanner run over likely locations tells you the truth. Finish with the human and the system: no blame for the reporter, blame for the process, which means vault-issued dynamic credentials so there is no long-lived password to paste. Slack incidents are the most common social-engineering adjacent scenario in DevOps security interview questions, and the order matters more than the tooling.

Answer: Start with the assumption hierarchy: session theft, credential compromise, then false positive from VPN or travel. Check the audit trail: same session token or different ones, MFA satisfied or bypassed, source IP reputation, and whether the second login used a new API client. Contain to match evidence: invalidate all sessions and rotate credentials immediately either way, since the cost is trivial, then review actions taken in the window for changes the user should not have made: new access keys, new MFA devices, policy edits, those are attacker persistence. Close the loop with controls: phishing-resistant MFA for admins and conditional access on impossible-travel signals. The discipline this tests is evidence before conclusion, which is the core habit scenario DevOps security interview questions exist to grade.

Answer: Assume compromise, likely cryptomining or a reverse shell. Capture what you can before killing it: network connections, process tree, and an image digest, since the running container is your evidence. Contain by terminating the workload and blocking the domain at egress, then trace the source: which image, which digest, was it built by your pipeline or pulled by tag, because a retagged upstream image is a classic supply chain path. Rotate the workload’s credentials and check neighbors on the node, since one compromised pod usually means one over-permissive network. Prevention gets specific: digest-pinned, signed images verified at admission, default-deny NetworkPolicies, and egress allowlists that would have made the mining pool unreachable in the first place. Container compromises this concrete are staples of runtime-focused DevOps security interview questions.

Answer: Freeze and contain: block the version in your proxy or lockfile immediately and stop scheduled builds that pull floating ranges, then enumerate exposure by checking which builds ran with the malicious version and what secrets those builds could read. Rotate every credential in those builds’ scope, cloud keys, registry tokens, deploy keys, and review for damage on the providers’ sides: new artifacts, new releases, new cloud resources. Report the package to the registry and your security team, since takedown and advisory work is time-critical for everyone. The durable fixes are pinning to digests or hashes, dependency review on new versions with an age threshold, and OIDC-scoped pipeline credentials so even a stolen build sees minutes of access, not years.

Answer: Diagnose the renewal failure first with the ACME client’s verbose output: expired DNS API credentials, a moved challenge path, rate limits, or a port 80 block are the usual four. If the fix is quick, renew and deploy, reload the service, and verify the chain with openssl s_client. If it is not quick by early evening, deploy the fallback: issue from a secondary CA or a staging certificate, or accept a short window of browser warnings with a status page notice, decided with your on-call lead, not alone. Then fix the class of problem, not the instance: alerting on expiry at 30 and 14 days, a renewal dry-run in monitoring, and a runbook that does not require reading this answer at 22:40. Cert expiry is the most rehearsed failure in DevOps security interview questions for a reason: everyone has one.

Answer: The server is serving an incomplete or stale chain: clients that lack a cached copy of the now-expired intermediate cannot build a valid path, so validation fails even though your leaf certificate is fine. Confirm with openssl s_client -connect host:443 -servername host and read the chain it presents, then deploy the corrected bundle, leaf plus current intermediates, and validate with an external checker, not just locally. Expect uneven breakage during the transition: older clients, embedded devices, and pinned-trust mobile apps fail while browsers recover, so keep the status page honest. The systemic fix is chain validation in your deploy pipeline as a synthetic check, because TLS issues are invisible to ordinary uptime probes until a human pastes a screenshot into your channel.

Answer: Verify the path first: from inside the pod, confirm connectivity and identify the route, then check the layer that should have stopped it. Usually one of four: no NetworkPolicy selecting the pod, so default-allow applies, a policy with an over-broad pod selector, shared security groups between workloads, or credentials from a shared secret granting the database access regardless of network. Fix at the right layer, default-deny policy plus an explicit allow for the legitimate caller, and rotate the database credentials if the secret was shared, because network and identity controls fail independently and you need both tight. The interview point: in segmented environments, “should not reach” must be enforced twice, by policy and by credentials, so a single slip is not a breach.

Answer: Restore service with scope, not with nostalgia: read the failing call from the application’s error or the audit log’s deny entry, and grant exactly the missing action on exactly the resources it needs, not the old wildcard. Verify from the audit trail what the identity had actually used historically, because that list is the correct baseline for the new policy, and anything not on it was dead privilege you just successfully removed. Then fix the process that caused the outage: cleanups belong in staging first, with deny-log mode where the platform supports it, observing what would break before enforcement. Framing the incident as success with a rough rollout is exactly the maturity scenario DevOps security interview questions reward: least privilege caused it, and least privilege also fixed it.

Answer: Preserve before you clean: capture logs, the modified files, and running processes, because wiping the server deletes your only evidence. Contain by taking the compromised asset offline or cutting it out at the proxy, then find the entry, CMS plugin, exposed admin panel, stolen credentials, or vulnerable dependency, using the logs around the first defacement timestamp. Rebuild from known-good artifacts rather than cleaning in place, rotate everything the host could reach, and only then restore, with the entry point closed and monitoring raised. Notification duties may apply if user data was reachable, which is why legal joins early. Interviewers are testing whether you treat defacement as the visible symptom of an intrusion whose real damage may be quieter, which is the correct frame for this whole class of DevOps security interview questions.

Answer: Confirm exposure first: is this the internet at large, which is constant background noise, or targeted attempts against real usernames, which is a signal? Check that password authentication is disabled and keys-only is enforced, because with keys, brute force is a log volume problem, not a compromise vector. Apply rate limiting and banning at the firewall or fail2ban to cut the noise, verify no account locked out, and confirm MFA on any account with shell access. The structural answer: move management access behind a bastion or identity-aware proxy and remove the endpoint from the public internet entirely, at which point the wave becomes someone else’s problem. Knowing when noise is just noise is the judgment this entry in DevOps security interview questions is really testing.

Answer: The key is compromised, no exceptions, so rotate the certificate: issue a replacement, deploy it across every host using the old one, and revoke the old cert where your CA supports it. Audit use of the old key after exposure, server logs for handshakes from unexpected clients can reveal impersonation, and check whether the same build process leaked other keys to other images, because one build-arg mistake is rarely alone. Fix the build: the key was baked in by a COPY or build arg, so secrets now inject at runtime from a vault or orchestrator mount, and a registry-wide secrets scan runs tonight, not next quarter. The detail that impresses in DevOps security interview questions here is scope discipline: one leaked key means auditing every image built by the same pipeline.

Answer: Log clearing during a suspicious window is an intrusion indicator, not a housekeeping event, so treat the host as compromised: isolate it, snapshot memory and disk before anything else rotates away, and preserve the logging pipeline’s server-side copies, which is exactly why centralized, write-once logging exists. Reconstruct the gap from elsewhere: central log forwarders, network flow records, authentication servers, and downstream systems the host touched all retain evidence the host itself lost. Hunt the standard clearing commands in what remains, and correlate with account activity around the timestamp. The lesson to state plainly: evidence collection is a design decision made in calm weather, because you cannot add tamper resistance during the storm, and that design framing is what elevates answers to this tier of DevOps security interview questions.

Answer: Characterize before mitigating: which endpoint, which protocol, volumetric or application-layer, spoofed or real sources, from flow logs and edge metrics, because the answer decides the lever. For volumetric floods the fix is upstream, provider scrubbing or anycast absorption, since your origin cannot win a bandwidth fight. For application-layer abuse, rate limiting per identity and IP, WAF rules targeting the request pattern, and serving cached or static responses for the attacked path. Protect the neighbors with isolations so one flooded service does not exhaust shared capacity, and keep the origin hidden behind the edge so attackers cannot bypass your mitigations. Declaring which knob belongs to which layer, edge, WAF, application, is the competence signal in this entry of DevOps security interview questions.

Answer: Nobody fixes 10,000 findings, so the work is triage: deduplicate first, because fleets repeat the same base image thousands of times and one fix kills a thousand findings. Prioritize by exposure and exploitability: internet-facing services with reachable paths and active exploits first, internal unreachable libraries last, using severity, CISA-style exploited-vulnerability lists, and reachability data rather than raw CVSS alone. Set explicit SLAs per tier, and where a finding is a false positive or unfixable, document the risk acceptance with an owner and a review date, because an accepted risk is a decision while a silent one is a liability. Presenting that framework calmly is the entire point of this question; the number is a scarecrow, and experienced answers to DevOps security interview questions never chase it.

Answer: This question is pass or fail on preparation, not on the day. The evidence chain: data access logs from the storage layer with read events, identity mappings at the time of access, since roles and memberships change, and the audit store’s integrity guarantees showing the logs were not altered. Reconstruct the access list, annotate service accounts versus humans, and be honest about gaps, systems that log to files with 30-day rotation produce a partial answer, and saying so credibly beats inventing completeness. Then close the gap that the question just exposed: longer retention on sensitive data access logs, centralized immutable storage, and periodic dry-run queries so the next audit is a scheduled report instead of an archaeology project. Auditors and DevOps security interview questions ask this for the same reason: they both want to know if the evidence exists before they ask.

Answer: Treat the key as compromised and rotate immediately, since vendor breach timelines are always measured in days and yours should not wait for their forensics. Review your own side of the integration: what the key could do, audit its recent use for anomalies, and check whether the vendor breach exposes data you sent them, which pulls legal and privacy into scope. Ask the vendor specific questions, what was accessed, when, whether credentials were targeted, and document answers, because your incident record will need them. Then reduce dependency risk: scope the key narrower, prefer per-workload credentials with short lifetimes, and add their service to your third-party review cadence. Third-party key incidents are increasingly standard fare in DevOps security interview questions because modern systems are mostly other people’s systems.

Answer: Diagnose in layers: is the backup readable and complete, does restore fail on dependencies, DNS, secret managers, or networking that the docs forgot, or on application-level validation after the data lands? The most common real answer is the second: the data restores fine and the system around it has drifted, undocumented credentials, a renamed VPC, an unmanaged schema. Fix the immediate gap, get one critical system restoring end to end, and document the runbook that worked, because the next test must not rediscover it. Then change the cadence: restore tests run monthly on automation, against the real dependencies, with restore time measured against a stated RTO, because untested backups are hopes. “A backup you have never restored” is the sentence this entry in DevOps security interview questions exists to hear.

Answer: Remove the access now and audit backward: what did that account touch since the departure date, look for logins, key creation, and changes in systems that matter, because a dormant but active account is a very different finding from a dormant and idle one. Check the full estate for the same gap: SSO deactivation that missed break-glass accounts, SSH keys outside the IdP, personal access tokens, and cloud keys created outside the joiner-mover-leaver process. Then fix the mechanism: offboarding is one automated workflow triggered by HR state, with periodic access reviews as the safety net, because a checklist maintained by memory fails exactly when turnover spikes. This scenario closes the loop on identity, which is why it ends so many DevOps security interview questions about access management.

Answer: Two questions, both matter. How: admission allowed it, meaning no policy enforcement, a namespace outside policy scope, or an exception created for a legacy workload and reused, so audit the admission configuration and the deployment history to find who set it and why. What now: remove the privilege, rebuild the pod, and check the node for residue, since a privileged pod with host root can install persistence beyond the cluster’s view: read the host’s auth logs, look for unexpected processes and cron entries, and consider the node compromised until proven otherwise. Prevent recurrence with Pod Security admission or a policy engine enforcing baseline levels cluster-wide, plus a documented exception process with expiry dates. Cluster escape paths like this are the deepest water in scenario DevOps security interview questions, and calm structure matters more than trivia here.

Answer: Show a system, not a screenshot: inventory that knows what exists, agent-based or derived from the same source that deploys, a patch policy with defined SLAs per severity, and compliance reporting that compares inventory against current patch levels, with exceptions documented, owned, and expiring. The strongest demonstrations pair that with pipeline evidence: images rebuilt on a schedule from updated bases, so patching happens by rebuild, and a CI check that fails builds on images older than a threshold. Be straight about the long tail: unpatchable legacy systems get compensating controls, network isolation and restricted access, and the auditor cares as much about how you handle those as about the healthy 95 percent. Compliance fluency like this is now table stakes in DevOps security interview questions, because regulated environments are where most infrastructure jobs live.