- 5-8+ years experience. - Roles: DevSecOps Engineer, Platform Engineer. - 36 checklist questions, 22 real interview Q&A, 7 scenarios, 10 behavioral questions. - Companies: Razorpay, Zerodha, Swiggy, Freshworks, Flipkart.
You have rotated a leaked credential at 1 AM. You have argued a SAST rollout down from "block everything" to something a team would actually tolerate. You have probably been the person paged when a container started talking to an IP nobody recognized. That is the floor for this round, not the ceiling. Senior DevSecOps interviews stop asking "do you know this tool" and start asking "what would you actually build, in what order, with what tradeoffs, and how would you get a team of people who do not report to you to go along with it." The questions shift from tool knowledge to risk judgment under real constraints - budget, headcount, a board that wants a SOC 2 letter by Friday, an engineering org that thinks security is the thing that slows them down. Three things separate senior candidates from strong mid-level candidates who know the same vocabulary. They scope security investment to actual risk instead of maximum paranoia - a senior engineer can explain why a control is *not* worth building yet, not just why every control is good in theory. They own the human side of the problem as part of the technical answer - a vulnerability management program with no remediation SLA and no executive buy-in is not a real program, it is a spreadsheet. And they have real incident scars and can talk about them precisely - what broke, how they found out, what changed afterward - because nobody reaches senior in this field without something going wrong on their watch at least once. This module has four parts, numbered so you always know exactly where you are. **Tier 1 - Senior Fundamentals Checklist (no answers)** 36 questions across 6 categories: application security and threat modeling at scale, Kubernetes and cloud-native security architecture, identity and zero-trust, compliance and policy as code, incident response, and platform strategy and leadership. If several of these are unfamiliar, that is a signal to revisit the underlying module before Tier 2. **Tier 2 - Real Interview Questions (Q1 to Q22)** Ten deep system-design questions asked at senior DevSecOps and platform security screens at companies like Razorpay, Zerodha, and Swiggy, followed by twelve faster, equally real technical questions. Every answer includes the reasoning and the tradeoff a senior engineer is expected to state without being prompted. **Tier 3 - Scenario Round (Q23 to Q29)** 7 open-ended organizational scenarios with no single correct answer. The interviewer is watching how you reason with incomplete information, conflicting incentives, and people who do not report to you. **Behavioral Round (Q30 to Q39)** 10 behavioral questions covering influence without authority, leading through an incident, building security culture, and the specific gap between mid-level and senior in this field.
These are table stakes for a senior round. If you need to look several of these up, go back to the relevant module first. ### Application Security and Threat Modeling at Scale * How do you run threat modeling as a repeatable process across dozens of teams, not a one-off workshop? * What is the difference between STRIDE and attack trees, and when would you use each? * How do you prioritize a backlog of 200+ unresolved findings across SAST, DAST, and SCA? * What is the difference between a security champion program and embedding security engineers directly in teams? * How do you measure whether your AppSec program is actually reducing risk, not just generating findings? * What is IAST, and where does it sit between SAST and DAST in a mature pipeline? * How do you handle security testing for AI and LLM-integrated features specifically? ### Kubernetes and Cloud-Native Security Architecture * What is the difference between Pod Security Standards and a custom admission controller policy, and when do you need the latter? * How do you design multi-tenant isolation in a shared Kubernetes cluster? * What is the security tradeoff between a service mesh and plain NetworkPolicies? * How do you secure a GitOps deployment model end to end? * What is SLSA, and how does it apply to your build pipeline? * How do you detect and respond to a container escape in real time? ### Identity, Secrets, and Zero-Trust * What does zero-trust actually mean at the implementation level, beyond the marketing phrase? * How do you design dynamic, short-lived secrets for a 100+ service environment? * What is the difference between authentication and authorization at the service mesh layer? * How do you implement workload identity without long-lived static credentials? * What is the risk of a single shared service account across multiple environments? ### Compliance, Governance, and Policy as Code * How do you implement continuous compliance instead of point-in-time audit scrambling? * What is the difference between a compliance framework and a security control, and why does conflating them cause problems? * How do you automate evidence collection for SOC 2, ISO 27001, or PCI-DSS? * What is policy as code, and where does it break down in practice? * How do you handle a compliance requirement that conflicts with a real engineering constraint? ### Incident Response and Security Operations * What is the difference between an incident commander and a technical lead during a security incident? * How do you run a blameless postmortem for a security incident specifically, as opposed to a reliability incident? * What is your approach to threat hunting versus waiting for alerts? * How do you decide when to involve legal, PR, or executive leadership during an active incident? * What is the difference between containment and eradication in incident response? ### Platform Strategy and Leadership * How do you build a business case for a security investment that has no immediate visible ROI? * What does a security champions program look like in practice, and how do you keep it from becoming symbolic? * How do you influence a team's architecture decisions when you have no direct authority over them? * How do you decide between building an internal security tool and buying a vendor platform? * What metrics would you bring to a board or CTO conversation about security posture?
### Designing a Zero-Trust Security Architecture for Microservices ### The Question Your company is moving from a flat internal network with implicit trust to a zero-trust model across 60 microservices on Kubernetes. Walk me through the architecture. ### What the interviewer is testing Whether you understand zero-trust as a set of concrete, layered controls rather than a buzzword. The worst answer treats this as "just turn on mTLS." The interviewer wants to see you reason about identity, policy, and blast radius together. ### The answer Zero-trust replaces network location with verified identity as the basis for trust. A request from inside the VPC gets no special treatment over a request from outside - every call, human or service, has to prove who it is and be explicitly authorized for the specific action it is requesting. The architecture has three layers that have to work together, not in isolation. Human access: IdP -> Identity-aware proxy -> Service Service mesh: Service A -> mTLS cert -> AuthorizationPolicy -> Service B Data layer: Service -> scoped DB role -> specific tables/rows only For service-to-service traffic, a service mesh (Istio or Linkerd) issues short-lived mTLS certificates tied to each workload's identity, and an explicit allowlist policy decides who can call whom. ```yaml ## Istio AuthorizationPolicy - default deny, ## explicit allow for one specific caller apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: payments-access namespace: production spec: selector: matchLabels: app: payment-service rules: - from: - source: principals: - "cluster.local/ns/production/sa/order-service" to: - operation: methods: ["POST"] paths: ["/v1/payments/process"] ``` > 💡 Green Flag: the candidate explains the migration as staged - permissive mode first, watching for violations in logs, before switching to strict enforcement - rather than flipping a global switch on day one. > 🔴 Red Flag: "we'd just enable mTLS everywhere and call it zero-trust." That covers transport security, not authorization, and says nothing about human access or data-layer scoping. The migration itself is a 6 to 12 month project, not a sprint. Run the mesh in permissive mode first, logging policy violations without blocking traffic, so you can find every service still talking over plain HTTP before you break it. Only then switch to strict mode, namespace by namespace, starting with non-production. ### Designing a Software Supply Chain Security Program ### The Question Your engineering org has 80 services and no SBOM, no image signing, and no dependency provenance tracking. The board wants a supply chain security program after a competitor had a breach traced to a compromised dependency. Design the program. ### What the interviewer is testing Whether you can translate a vague executive mandate into a concrete, sequenced technical rollout, and whether you understand supply chain security as a chain of trust rather than a single tool. ### The answer Supply chain security is really four separate guarantees chained together: you know what is in your software (SBOM), you can trust where it came from (provenance and signing), you know quickly if a component becomes dangerous (continuous CVE monitoring), and you can prove all of this to an auditor or a board (evidence and reporting). ```bash ## Generate an SBOM for every built image syft registry.company.com/checkout:1.4.0 -o spdx-json > sbom.json ## Check the SBOM against known CVEs grype sbom:./sbom.json --fail-on high ## Sign the image so deployment can verify provenance cosign sign --key cosign.key registry.company.com/checkout:1.4.0 ``` Rollout order matters more than tool choice here. Start with SBOM generation in CI for every build - it is the cheapest step and gives you the inventory you need before anything else makes sense. Add CVE scanning against that SBOM next, since you already have the data. Image signing comes third, enforced first in warn-only mode through an admission controller, then switched to blocking once teams have adjusted. > 📌 Remember: a SLSA level 1-2 target (build provenance, basic signing) within the first two quarters is realistic for 80 services. SLSA level 3-4 (hermetic, fully verified builds) is a multi-year target for most orgs - say this explicitly if asked, because overselling the timeline is a common failure in this exact interview question. ### Building a Risk-Based Vulnerability Management Program at Scale ### The Question Your org has 5,000+ open vulnerability findings across SAST, DAST, SCA, and container scanning, no SLAs, and no prioritization beyond the scanner's own severity label. Design the program from here. ### What the interviewer is testing Whether you can build a system that survives contact with a real, overwhelming backlog instead of a theoretical clean-slate process. ### The answer Vendor severity alone is not enough to prioritize 5,000 findings - it does not know whether the affected service is internet-facing, what data it touches, or whether the vulnerable code path is even reachable. Build a composite risk score: base severity (CVSS), exploitability (is there a public exploit, is it network-reachable), and business context (internet-facing, handles payment or PII data, blast radius if exploited). | Risk Tier | Criteria | SLA | |:----------|:---------|:----| | Critical | Internet-facing + exploitable + high severity | 7 days | | High | Internal + exploitable, or internet-facing + medium | 30 days | | Medium / Low | Internal, low reachability | 90 days / backlog | With 5,000 existing findings, do not try to remediate the backlog and the SLA framework at the same time. First, triage the backlog once against the new framework - most findings will fall to medium or low once business context is applied, which is usually where the count drops from overwhelming to manageable. Then apply the SLA framework only to new findings going forward, and work the re-triaged backlog down as a separate, lower-pressure track. ```bash ## Example: pulling findings with a script that adds ## business context (internet-facing tag) before scoring trivy image --format json checkout:1.4.0 | \ jq '.Results[].Vulnerabilities[] | select(.Severity=="CRITICAL")' ``` > 🔴 Red Flag: proposing to fix all 5,000 findings before defining the ongoing SLA process. That guarantees the program stalls in backlog cleanup and never becomes a sustainable system. ### Designing a Secure CI/CD Platform for 200 Engineers ### The Question You are building the golden CI/CD pipeline template that 200 engineers across 15 teams will inherit. What security controls are non-negotiable in the template, and what do you leave to individual teams? ### What the interviewer is testing Platform thinking - can you separate what must be centrally enforced from what should remain a team-level choice, instead of either centralizing everything or leaving everything to individual teams. ### The answer Non-negotiable, centrally enforced in the template: secrets scanning, SBOM generation, container image scanning with a blocking threshold on critical findings, and signed images verified at deploy time. These protect the org regardless of any individual team's security maturity, and a single team opting out creates organization-wide risk. ```yaml ## Shared pipeline template - teams inherit this, ## cannot remove the security stages include: - project: 'platform/ci-templates' file: 'security-baseline.yml' stages: [secrets-scan, build, sca, image-scan, sign, deploy] ``` Left to team discretion: choice of SAST tool specifics if their language is unusual, DAST scan frequency for low-risk internal tools, and the exact severity threshold for non-blocking warnings, within bounds set by the platform team. > 💡 Green Flag: the candidate explicitly separates "platform-enforced baseline" from "team-level configuration" rather than describing one giant mandatory checklist - that distinction is what makes a template adoptable across 15 teams with different needs. The rollout itself should be opt-in with a deadline, not a forced migration. Give teams 2-3 months with the new template available and supported, then make it mandatory for new services immediately, and set a realistic migration deadline for existing ones. ### Leading Incident Response for an Active Security Breach ### The Question At 11 PM you get paged: unusual outbound traffic from a production database host to an unfamiliar external IP. What do you do, in order? ### What the interviewer is testing Whether you have an actual incident response sequence memorized under pressure, not whether you can describe security concepts in the abstract. ### The answer Contain before you investigate deeply - a confirmed active exfiltration in progress outweighs the value of preserving perfect forensic evidence. The sequence: confirm the signal is real (not a monitoring false positive), isolate the host (network-level, not necessarily powering it off, which can destroy memory forensics), declare an incident and assign an incident commander, then move to investigation in parallel with containment. 1. Confirm: is this traffic real and unexpected? 2. Contain: isolate at network level (security group, NACL) - do not power off yet, preserve memory state 3. Declare: open incident channel, assign IC 4. Investigate: what process initiated it, what data was accessed, how did the attacker get in 5. Eradicate: remove access, rotate every credential that host could have touched 6. Recover: restore from known-clean state 7. Postmortem: blameless, with concrete action items > ⚠️ Security: do not skip credential rotation scope assessment. If the compromised host had IAM role access, every credential, token, and secret it could have reached needs to be treated as potentially compromised, not just the obviously affected database. The decision point most candidates miss: when do you escalate to legal, PR, or executive leadership? The answer is as soon as you have reasonable evidence of actual data access or exfiltration, not after the incident is fully resolved - regulatory notification clocks (like breach disclosure windows under data protection law) often start from discovery, not from confirmation. ### Implementing Policy as Code Across a Multi-Team Organization ### The Question You want to enforce "no container runs as root" and "every S3 bucket must be private by default" as automated policy across 15 teams who currently have no shared standards. How do you roll this out without it becoming the thing every team route around? ### What the interviewer is testing Change management as much as the technical implementation - OPA and Kyverno are not hard to write policies in, but getting 15 teams to accept enforcement without revolt is the actual senior skill being tested. ### The answer Write the policy once, in a framework like OPA Rego or Kyverno, and run it everywhere identically - the technical part is the easy part. ```rego package kubernetes.admission deny[msg] { input.request.kind.kind == "Pod" container := input.request.object.spec.containers[_] not container.securityContext.runAsNonRoot msg := "containers must set runAsNonRoot: true" } ``` The rollout sequence is what determines whether this sticks. Audit mode first - the policy runs and logs violations but blocks nothing, for at least two to four weeks, giving every team visibility into how many of their existing workloads would be affected. Share that data with each team directly, with a fix deadline. Only after that grace period does the policy switch to enforcing, and even then, start enforcing on new deployments only, with a separate migration track for existing non-compliant workloads. > 📌 Remember: a policy that blocks on day one with zero warning, on workloads that have been running for years, does not read as security rigor to the affected team - it reads as the platform team breaking production without notice. The technical correctness of the policy will not save you from that reputational damage. ### Designing Secrets Management for a Regulated Fintech Environment ### The Question You are building secrets management for a payments company under PCI-DSS scope. What does the architecture look like, and what is different from a standard secrets manager rollout? ### What the interviewer is testing Whether you understand that compliance scope changes the architecture, not just the paperwork around it. ### The answer The core architecture is the same as any mature secrets program - centralized secrets manager, dynamic short-lived credentials, no hardcoded secrets anywhere. What changes under PCI-DSS is the scope boundary and the audit trail requirements layered on top. ```bash ## Vault dynamic credential scoped to PCI-scope database only, ## short TTL, every issuance logged vault write database/roles/payments-pci \ db_name=cardholder-data-db \ creation_statements="CREATE ROLE \"{{name}}\" \ WITH LOGIN PASSWORD '{{password}}' VALID UNTIL \ '{{expiration}}'; GRANT SELECT ON transactions \ TO \"{{name}}\";" \ default_ttl="30m" ``` Network segmentation matters more here than in a typical rollout - the PCI cardholder data environment (CDE) should be a genuinely separate network segment, with its own Vault namespace or even a separate Vault cluster, so a breach outside the CDE cannot reach payment-scoped secrets at all. Every secret access inside CDE scope needs to be logged in a way that satisfies an auditor's evidence request without manual reconstruction - this is the detail that gets missed when teams treat PCI as "the same thing, but stricter." > 🔴 Red Flag: treating PCI-DSS scope as "encrypt everything a bit more." The real architectural change is network and access segmentation around the cardholder data environment specifically, not a blanket increase in encryption strength everywhere. ### Building a Security Champions Program That Actually Works ### The Question You want to scale security practices across 15 engineering teams without growing your security team 15x. How do you design a security champions program that does not become symbolic? ### What the interviewer is testing Organizational design thinking - this question filters out candidates who think security scales by hiring more security engineers, which never keeps pace with engineering headcount. ### The answer A security champion is an embedded engineer on each team, not a security engineer, who gets extra training and is the first point of contact for security questions on that team. The program fails when the champion role has no real authority, no protected time, and no visible support from leadership - it becomes a title on a slide with zero behavior change. What makes it real: protected time (explicitly, not "whenever you have a free moment" - ideally a few hours a week recognized in sprint planning), a direct relationship with the central security team (regular sync, not just a Slack channel), and actual decision-making power within their team - a champion should be able to block a PR for a real security issue, not just flag it and hope. > 💡 Green Flag: the candidate mentions measuring the program by outcome (did the team's finding remediation time improve, did the team start catching issues in review before they reached the central security team) rather than by attendance at champion meetings. The anti-pattern worth naming explicitly: a champions program that exists only to make a slide for the board ("we have security champions in every team") with no real training investment behind it. That is worse than no program, because it creates the appearance of coverage without the substance. ### Making the Business Case for Security Investment With No Immediate ROI ### The Question You want budget and headcount to build a vulnerability management platform. The CFO asks: what is the ROI? How do you answer? ### What the interviewer is testing Whether you can translate security risk into business language without either inflating fear (FUD) or being unable to quantify anything at all. ### The answer Security ROI is rarely "this generates revenue." It is closer to insurance: quantify the cost of the bad outcome you are reducing the likelihood of, and the cost of the current manual or absent process you are replacing. Concretely: pull your last 12 months of security incidents or near-misses and estimate engineering hours spent on manual, ad-hoc response. Compare that to industry data on average breach cost for a company your size and sector (these numbers exist in published reports and are credible references in this conversation). Frame the platform cost against both: "manual vulnerability triage currently costs us roughly 15 engineer-hours a week across the org, and our last close call took 40 hours to fully remediate and would have cost significantly more if it had reached production with customer data exposed." > 📌 Remember: never present a single inflated worst-case number as your only justification - CFOs are trained to discount FUD-driven arguments. Pair the risk-avoidance argument with a concrete efficiency argument (hours saved, faster remediation) that stands on its own even if the worst case never happens. ### Deciding Between Building an Internal Security Tool and Buying a Platform ### The Question Your team is evaluating whether to build a custom internal vulnerability tracking and triage tool, or buy a platform like DefectDojo or a commercial alternative. You have 2 dedicated security platform engineers. What is your recommendation? ### What the interviewer is testing A senior, not junior, build-vs-buy instinct - junior candidates tend to default to "buy is always safer," senior candidates know the real decision criteria. ### The answer The right question is not which option is technically superior, but what your 2 engineers' time is actually worth spent building a tracking tool versus spent on the work only your org can do - triaging your own findings, tuning policies to your own risk tolerance, working with your own engineering teams. | Dimension | Build | Buy | |:----------|:------|:----| | Time to value | 2-4 months minimum | Days to weeks | | Ongoing maintenance | Consumes your 2 engineers indefinitely | Vendor-owned | | Customization | Unlimited | Limited to vendor roadmap | With only 2 dedicated engineers, building a tracking platform from scratch usually means those 2 people spend the next year maintaining infrastructure instead of doing security engineering work that only your company can do. The honest recommendation in most cases at this team size is buy, and redirect the 2 engineers toward the high-leverage work a vendor tool cannot do for you - triage, policy tuning, and direct engineering team engagement. > 🔴 Red Flag: recommending build because it is more technically interesting for the team, without weighing the multi-year maintenance cost against the org's actual security engineering capacity.
**Q11. What is the difference between STRIDE and an attack tree, and when would you use each?** STRIDE is a checklist-style framework - for each component, you systematically ask whether Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, or Elevation of Privilege applies. It is fast and good for broad coverage across a new system design. An attack tree starts from a specific goal an attacker might have - "exfiltrate customer payment data" - and works backward, branching into every path that could achieve it, including chained, multi-step attacks that STRIDE's component-by-component approach can miss. Use STRIDE for a new feature's initial design review. Use attack trees when you are specifically worried about a high-value target and need to reason about chained, multi-step compromise paths. --- **Q12. How do you measure whether your AppSec program is reducing actual risk, not just generating more findings?** Raw finding count is a misleading metric - it goes up the moment you add a new scanner, regardless of whether the codebase got safer. Track mean time to remediate by severity, the percentage of vulnerabilities caught pre-production versus found in production, and recurrence rate (is the same class of bug showing up again after a fix, indicating a systemic gap rather than a one-off mistake). A falling production-catch rate alongside a rising pre-production-catch rate is the clearest signal that shift-left investment is actually working. --- **Q13. What is SLSA, and how would you apply it to your build pipeline?** SLSA (Supply-chain Levels for Software Artifacts) is a maturity framework for build integrity, with levels from 1 to 4 representing increasing guarantees that an artifact was built from the source you think it was, by a process you trust, without tampering. Level 1 just requires a documented build process. Level 3-4 requires hermetic, fully isolated builds with cryptographic provenance that cannot be forged even by someone with access to the build system. ```bash ## Generate provenance attestation for a build (SLSA-style) slsa-generator generate \ --artifact checkout-service:1.4.0 \ --output provenance.json ``` Most organizations realistically target SLSA level 2-3: signed builds with provenance metadata, run on a CI system you control, verified at deploy time. Level 4's fully hermetic, reproducible builds are a significant additional engineering investment, worth it primarily for organizations with the highest supply chain risk exposure. --- **Q14. How do you secure a GitOps-based deployment model end to end?** GitOps removes the CI pipeline's need to hold cluster credentials at all - a controller inside the cluster (ArgoCD, Flux) pulls changes from Git rather than CI pushing them. The remaining risks shift to the Git repository itself and the controller's own permissions: enforce branch protection and signed commits on the manifest repo, store no secrets in Git at all (use the Secrets Store CSI driver or an external secrets operator instead), and scope the GitOps controller's own RBAC tightly per namespace rather than granting it cluster-admin for convenience. > **Note:** the security benefit of GitOps is specifically that compromising your CI system no longer grants direct cluster access - the attacker could push a bad image, but they cannot directly execute commands against the cluster, since no external system holds those credentials. --- **Q15. What is the difference between containment and eradication in incident response, and why does the order matter?** Containment stops the bleeding - isolating an affected host or revoking a compromised credential to stop ongoing damage, without necessarily understanding the full scope yet. Eradication removes the actual root cause - patching the vulnerability that was exploited, rotating every credential the attacker could have touched, rebuilding from a known-clean state. Doing eradication before containment is complete risks the attacker reacting to your remediation in real time and pivoting elsewhere before you have fully cut off their access. Contain first, even if your understanding is incomplete, then investigate and eradicate with containment already in place. --- **Q16. How do you detect and respond to a container escape in real time?** Detection relies on runtime monitoring, since a container escape is fundamentally a kernel-level event that static scanning cannot see. Tools like Falco watch system calls and flag patterns associated with escape attempts - a container process spawning a shell with host-level privileges, unexpected writes to host filesystem paths, or a process attempting to load a kernel module. ```yaml ## Falco rule: detect a shell spawned inside a ## production container - a common escape precursor - rule: Shell in production container condition: > container.id != host and proc.name in (bash, sh, zsh) and k8s.ns.name = "production" output: "Shell spawned (pod=%k8s.pod.name)" priority: WARNING ``` Response follows the same contain-first sequence as any incident: isolate the affected node immediately (it may be compromised at the host level, not just the container), assume host-level compromise until proven otherwise, and treat any credentials or secrets accessible to that node as potentially exposed. --- **Q17. What is the difference between a compliance framework and a security control, and why does conflating the two cause problems?** A compliance framework (SOC 2, ISO 27001, PCI-DSS) defines *what* must be demonstrated - access is controlled, data is encrypted, incidents are tracked. A security control is the actual technical implementation that satisfies that requirement - an IAM policy, an encryption-at-rest setting, an incident response runbook. The problem with conflating them is teams start building "for the audit" instead of building genuinely secure systems that happen to also satisfy the audit. A control built purely to check a compliance box, without engineering judgment about whether it addresses real risk, tends to be brittle and gets quietly worked around the moment it becomes inconvenient. The senior framing: build the controls because they reduce real risk, and let compliance evidence be a byproduct of controls that were going to exist anyway. --- **Q18. How do you handle a compliance requirement that conflicts with a real engineering constraint?** Name the actual conflict specifically rather than treating it as immovable on either side. A common example: a framework requires 90-day credential rotation, but a specific legacy system cannot support automated rotation without a multi-month migration. Document the gap honestly, propose a compensating control (more aggressive monitoring on that credential, network-level restriction limiting where it can be used from), and get explicit sign-off on the accepted residual risk with a remediation timeline - rather than either silently ignoring the requirement or blocking the business on an unrealistic immediate fix. --- **Q19. What is the difference between threat hunting and waiting for alerts?** Alert-driven security is reactive by definition - you only see what your existing detection rules were built to catch. Threat hunting is proactive: a human (or an automated hunt query) goes looking for signs of compromise that would not trigger any existing alert, often based on a hypothesis ("if an attacker got admin access through this service, what would they likely do next, and would we see it"). ```bash ## Example threat hunt: looking for IAM role ## assumptions from unusual source IPs in the ## last 24 hours, outside normal CI/CD ranges aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,\ AttributeValue=AssumeRole \ --start-time $(date -d '24 hours ago' --iso-8601) ``` Mature programs run both - alerting catches known patterns fast, threat hunting catches the gaps in what you have not thought to alert on yet, and the findings from hunts often become new permanent alerting rules. --- **Q20. How do you decide whether to build a custom admission controller versus using an existing tool like Kyverno or OPA Gatekeeper?** Existing tools cover the vast majority of policy needs - resource limits, image registry restrictions, label requirements, security context enforcement - with a much lower maintenance burden than custom code. Build a custom admission controller only when your policy logic needs to call out to an external system in a way the existing tools cannot express cleanly - checking an internal asset inventory before allowing a deployment, for example, or validating against a business rule specific to your organization that has no generic policy-language equivalent. > 🔴 Common Mistake: building a custom admission controller for a policy that Kyverno or OPA could express natively, just because the team is more comfortable writing Go than learning a policy language. The maintenance cost of custom webhook code - availability requirements, certificate management, upgrade compatibility with each Kubernetes version - is a real ongoing tax that a declarative policy tool avoids entirely. --- **Q21. What security concerns come up specifically with AI and LLM-integrated features, and how do you test for them?** Beyond standard application security testing, LLM-integrated features introduce a newer class of issues: prompt injection (malicious input designed to override the system's intended instructions), data leakage through model outputs (a model trained or fine-tuned on sensitive data inadvertently revealing it), and excessive agency (an LLM-driven agent being given more tool access or autonomy than the actual use case requires). Testing for these is still maturing as a discipline compared to traditional AppSec, but the core approach is similar in spirit: adversarial test cases specifically designed to attempt prompt injection and data extraction, treating any LLM-callable tool or function as needing the same least-privilege scoping as a service account, and logging model inputs and outputs at a level that lets you investigate after the fact if something goes wrong. > **Note:** this is a genuinely evolving area. A strong senior answer acknowledges that the tooling and best practices here are less mature than traditional SAST and DAST, rather than pretending there is a fully solved playbook. --- **Q22. How do you implement continuous compliance instead of scrambling manually before each audit window?** Continuous compliance means the technical controls behind a framework are running and exporting evidence all the time, not assembled reactively when an auditor's request lands. Configure automated exports: quarterly IAM access reviews, vulnerability scan results with remediation timestamps, change management logs from your CI/CD and infrastructure-as-code pipeline, and incident records. ```bash ## Scheduled job exporting access review evidence ## automatically, every quarter, no manual step aws iam generate-credential-report aws iam get-credential-report --query 'Content' \ --output text | base64 -d > \ evidence/access-review-$(date +%Y-Q%q).csv ``` Tools like Vanta or Drata can automate much of the mapping between raw technical evidence and specific control requirements. The senior engineer's actual job here is usually not picking the compliance framework, but making sure the underlying controls are genuinely continuous, so the audit becomes an export, not a fire drill.
### Q23. Scenario - The 90-Day Plan for Zero Security Maturity You join a 150-engineer company as the first dedicated DevSecOps hire. There is no SAST, no SCA, no secrets scanning, and no formal vulnerability process. Walk me through your first 90 days. Spend the first two weeks listening, not fixing - talk to engineering leads, find out what has already gone wrong (every org with no security tooling has a near-miss story they remember), and use that to build a real problem map instead of guessing priorities. Weeks 3-6, add the cheapest, highest-blast-radius-reduction controls first: secrets scanning and SCA across the highest-risk services, not a full platform rollout everywhere at once. Weeks 7-12, formalize a lightweight vulnerability triage process with simple severity-based SLAs, and start the security champions conversation with the two or three teams who showed the most interest during your listening tour. By day 90 you should have measurable coverage on the riskiest services, a working triage process, and early allies - not a finished program, and not a Kubernetes admission controller rollout that nobody asked for yet. ### Q24. Scenario - The Friday Night CVE on Launch Day A critical CVE is published at 6 PM on the day of a major product launch, affecting a library used by your authentication service. The fix requires an untested version bump. What do you do? Assess actual exploitability before treating it as an automatic fire drill - check whether the vulnerable code path is reachable from your authentication flow specifically, and whether the service is internet-facing (it almost certainly is, if it is authentication). If genuinely exploitable and the service is public-facing, the launch itself is now the lower priority - delay or proceed with a documented, accepted risk only with explicit sign-off from engineering leadership, never silently. If a same-day patch is the right call, deploy it to the highest-risk path first with focused smoke testing on the auth flow specifically, not full regression, and have a rollback ready before you deploy. ### Q25. Scenario - Convincing Leadership to Fund a Platform Rebuild Your CI/CD security tooling is a patchwork of scripts nobody fully understands, built by an engineer who left two years ago. You want budget to rebuild it properly. The CTO says "it works, why does it need money." How do you make the case? Do not argue from elegance - argue from risk and velocity cost. Quantify what the current patchwork actually costs: how many hours per month does the team spend debugging pipeline failures caused by the fragile scripts, how many security gates are silently being skipped because nobody trusts the current tooling enough to enforce them strictly, and what happens to onboarding time for new engineers who have to learn an undocumented system. Pair that with a concrete, scoped proposal - not "give us six months and a blank check" but a phased plan with a defined first deliverable in 6-8 weeks, so the CTO is approving a bounded first step, not an open-ended initiative. ### Q26. Scenario - Discovering a Months-Long Undetected Breach A penetration test reveals evidence that an attacker has had access to an internal system for an estimated three months, undetected by any existing monitoring. What do you do, starting from the moment you see the report? Treat this as an active incident immediately, not a finding to schedule for next sprint - a three-month dwell time means the assumption has to be that the attacker has had ample time to move laterally, and the investigation needs to scope the full blast radius before anything is publicly communicated. Engage incident response formally, bring in legal and executive leadership early given the likely regulatory and disclosure implications of a multi-month undetected compromise, and resist the urge to immediately revoke all access before you understand what the attacker has touched - premature action can tip them off and destroy your ability to fully scope the damage. Once contained and scoped, the postmortem has to honestly examine why three months passed with zero detection, because that gap is the real systemic finding, not just the breach itself. ### Q27. Scenario - Compliance Deadline Colliding With an Active Incident You are in week two of remediating a security incident when your compliance team tells you the SOC 2 audit window opens in five days and several required evidence artifacts are not ready because your team has been fully consumed by incident response. What do you do? Communicate the conflict explicitly and immediately rather than trying to quietly do both at full speed - an auditor can usually accommodate a short, well-justified delay far better than they can accommodate evidence that was rushed and incomplete. Triage which evidence artifacts are genuinely blocked by the incident response work versus which can be produced by someone not currently on the incident. Propose a revised timeline to the compliance team and, if needed, the auditor directly, with a clear explanation - active incident response is itself evidence the incident response control is working, which is something a mature auditor can usually appreciate rather than penalize. ### Q28. Scenario - A Senior Engineer Refuses to Follow Secure Coding Standards A senior backend engineer, more senior than you in tenure, consistently pushes back on code review comments about SQL injection risk, arguing their queries are "fine because we control the input." How do you handle this? Do not escalate immediately and do not let it slide because of their seniority - first make the risk concrete with something they cannot wave away with "the input is controlled," such as a quick proof-of-concept showing how that input assumption breaks down (a downstream integration, a future API consumer, an internal tool that changes how the function gets called). If the technical argument alone does not land after a genuine attempt, escalate to their engineering manager with the specific risk and the conversation history, framed around the risk rather than the personality conflict - "I want to make sure this gets resolved, here is the specific exposure and what I have already tried," not "they won't listen to me." ### Q29. Scenario - Build vs Buy Under Real Budget Pressure for a SIEM Your org needs a SIEM. Your annual security tooling budget was just cut by 40 percent. The leading commercial options are now out of reach. What do you do? Reframe the goal before reframing the budget - the actual need is detection and correlation capability, not necessarily a named commercial SIEM product. Evaluate the open-source stack (the ELK stack with detection rules, or Wazuh) honestly against your team's actual operational capacity to run it, since open-source SIEM is materially more engineering-intensive to operate well than a managed commercial product. If the team genuinely has the capacity, propose the open-source path with a clear accounting of the engineering time it will consume instead of license cost. If the team does not have that capacity, the honest recommendation might be a smaller-scope commercial tool covering your highest-risk log sources only, rather than full coverage with a tool nobody can maintain.
**Q30. Tell me about a time you had to influence a security decision in a team you had no authority over.** *Strong Answer Framework:* Describe the specific resistance you encountered and what you actually did about it beyond simply asking nicely - quantifying risk concretely, finding a smaller compromise solution, or building a proof of concept that made the risk undeniable. Close with the actual outcome and what you would do differently, since pure success stories with no friction tend to read as polished rather than real. **Q31. Describe a security incident you led the response for. What happened and what changed afterward?** *Strong Answer Framework:* This is one of the highest-signal questions in a senior round. Walk through detection, containment decisions made under uncertainty, and the actual root cause - not just "we fixed it" but the specific technical and process change made afterward so the same class of incident cannot recur the same way. Avoid any framing that shifts blame onto a specific individual; ownership of the systemic gap is what senior interviewers are listening for. **Q32. Tell me about a time you had to say no to a deadline because of a security risk, and how that conversation went.** *Strong Answer Framework:* Show that your "no" came with a concrete alternative, not a flat refusal - a scoped-down version of the work, a documented accepted-risk path with explicit sign-off, or a faster but narrower review. Interviewers are listening for whether you can hold a position under real business pressure while still being someone people want to work with again. **Q33. Describe building or scaling a security program with limited headcount.** *Strong Answer Framework:* Be specific about the actual leverage mechanisms you used - automation, a champions program, platform-level enforcement that did not require manual review of every change - rather than a vague "we prioritized well." A strong answer names what you deliberately chose not to do, because resource-constrained prioritization is the actual skill being tested. **Q34. Tell me about a time your security recommendation turned out to be wrong, or overcautious.** *Strong Answer Framework:* This question specifically tests intellectual honesty. A strong answer names a real instance where, in hindsight, a control you pushed for was not worth its cost, explains how you found that out, and what you changed about how you make these calls afterward. Avoid reframing a clear miss as secretly correct. **Q35. How do you build trust with engineering teams who see security as something that slows them down?** *Strong Answer Framework:* Describe concrete actions rather than philosophy - showing up to a team's planning meeting before pushing a new requirement on them, fixing a noisy false-positive-heavy tool before asking a team to adopt a new one, or being the person who helps debug a blocked pipeline rather than just the person who blocked it. The signal is whether you understand trust as something built through specific actions over time, not declared. **Q36. Tell me about a time you had to deliver bad news to engineering leadership about a security posture.** *Strong Answer Framework:* Show that you led with the data and a path forward, not just the alarming finding - "here is what we found, here is the realistic exposure, here is what I recommend we do in what order." Mention how you calibrated the framing to avoid both downplaying a real risk and triggering unnecessary panic that leads to a rushed, poorly-scoped reaction. **Q37. Describe a time you mentored someone on secure coding or secure architecture practices.** *Strong Answer Framework:* Be specific about what you actually changed in how they approached the problem, not just that a conversation happened. The strongest answers describe a shift in the other person's independent judgment afterward - they started asking the right question on their own in a later, unrelated situation - rather than just a single fix you walked them through. **Q38. Tell me about a time you disagreed with a compliance or audit requirement and how you handled it.** *Strong Answer Framework:* Show that you engaged with the actual intent behind the requirement rather than either blindly complying or dismissing it. A strong answer describes proposing an alternative control that satisfied the underlying risk concern more effectively than the literal requirement, and how you got that accepted by the compliance team or auditor. **Q39. Where do you see the gap between mid-level and senior in DevSecOps, and what are you doing to close it?** *Strong Answer Framework:* The honest answer usually centers on scope and influence rather than raw technical depth - a mid-level engineer owns a service or a pipeline; a senior engineer is expected to influence security posture across teams that do not report to them, and to make resourcing and risk-acceptance calls with incomplete information. Name something specific you are actively doing to build that muscle - leading a cross-team initiative, writing the recommendation document that gets multiple teams to align, or taking on the uncomfortable conversations rather than avoiding them.
You have rotated a leaked credential at 1 AM. You have argued a SAST rollout down from "block everything" to something a...
These are table stakes for a senior round. If you need to look several of these up, go back to the relevant module first...
Designing a Zero-Trust Security Architecture for Microservices The Question Your company is moving from a flat internal ...
Q11. What is the difference between STRIDE and an attack tree, and when would you use each? STRIDE is a checklist-style ...
Q23. Scenario - The 90-Day Plan for Zero Security Maturity You join a 150-engineer company as the first dedicated DevSec...
Q30. Tell me about a time you had to influence a security decision in a team you had no authority over. Strong Answer Fr...
Practice What It Addresses SLSA levels 2-3 Build provenance and tamper-resistant artifacts Risk-based vulnerability SLA ...
DevSecOps Engineer / Platform Engineer (5-8+ years, senior) Company Type Range Service company Rs 20L - Rs 32L Mid-size ...
Aligns directly with DevOps, Site Reliability (SRE), and Platform Engineering job descriptions.