- 3-5 years experience. - Roles: Mid-Level DevSecOps Engineer, Security Automation Engineer, Cloud Security Engineer. - 32 checklist questions, 22 real interview Q&A, 7 scenarios, 10 behavioral questions. - Companies: Razorpay, Zerodha, Swiggy, Flipkart, Freshworks.
You have owned a pipeline, not just used one. You have debugged a failed deployment without someone walking you through it. You have probably been the person who added the first SAST gate to a project, or the one who got paged when a container kept restarting. That experience is exactly what this round is built to surface. Mid-level interviews shift in a specific direction from junior ones. Junior interviews ask "do you know what this is." Mid-level interviews ask "have you actually built this, and what went wrong when you did." You are expected to reason about tradeoffs, not just definitions - not just "what is SAST" but "when would you accept the false positive cost of a stricter SAST ruleset, and when would you not." You are expected to have opinions backed by something you have actually run in production or at least in a real staging environment, not just a tutorial. Three things separate strong mid-level candidates from junior candidates who happen to know the same vocabulary. They talk about failure - what broke, how they found out, what they changed - because real ownership always includes a few real incidents. They reason about severity and tradeoffs unprompted - explaining not just that they would block a deployment, but under what condition they would not. And they connect tools to outcomes - "we added Trivy to the pipeline" is a junior answer; "we added Trivy with a tuned severity threshold after the first version blocked 40 percent of our builds on low-risk base image CVEs" is a mid-level answer. This module has four parts, numbered so you always know exactly where you are. **Tier 1 - Mid-Level Fundamentals Checklist (no answers)** 32 questions across 6 categories: CI/CD pipeline security at scale, container and Kubernetes security, cloud and infrastructure security, secrets and identity management, application security testing, and compliance and monitoring. 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)** 22 questions asked at mid-level DevSecOps screens at companies like Razorpay, Zerodha, and Swiggy. Every answer includes the reasoning, real code or commands, and the tradeoff a mid-level engineer is expected to mention without being asked. **Tier 3 - Scenario Round (Q23 to Q29)** 7 open-ended scenarios with no single correct answer. The interviewer is watching how you reason under incomplete information and real organizational friction, not whether you recite the textbook answer. **Behavioral Round (Q30 to Q39)** 10 behavioral questions covering ownership, pushback, mistakes, and working with people who disagree with your security recommendation.
These are table stakes for a mid-level round. If you need to look several of these up, go back to the relevant module first. ### CI/CD Pipeline Security at Scale * How do you decide which severity levels block a build versus create a ticket? * What is the difference between scanning on every commit versus only on merge to main? * How do you handle a pipeline where security scans add 15+ minutes to every build? * What is a software bill of materials (SBOM), and when is it generated? * How do you prevent a compromised CI pipeline from gaining cluster credentials? * What is the difference between SAST, DAST, and IAST? * How would you roll out a new SAST tool to a team without blocking all existing work? ### Container and Kubernetes Security * What is the difference between Pod Security Standards and NetworkPolicies? * How do you prevent a container from running as root at the cluster level, not just the Dockerfile level? * What is an admission controller, and what is it used for? * How do you scan a Helm chart or Kubernetes manifest before it is applied? * What is the risk of a default-allow network policy in a multi-tenant cluster? * What is the difference between a liveness probe and a readiness probe, from a security availability angle? ### Cloud and Infrastructure Security * What is IaC scanning, and what tools would you use for Terraform? * How do you detect configuration drift between your IaC and the live environment? * What is the principle behind a Service Control Policy versus an IAM policy? * How would you secure cross-account access in a multi-account AWS setup? * What is the risk of an overly broad VPC peering connection? ### Secrets and Identity Management * What is the difference between static secrets and dynamic secrets? * How do you rotate a database credential without downtime? * What is the risk of storing secrets as plain Kubernetes Secrets without an external secrets manager? * How do you authenticate a pod to Vault without a long-lived static token? ### Application Security Testing * What is the OWASP Top 10, and can you name at least five categories? * What is the difference between a vulnerability scan and a penetration test, and when would you schedule each? * How do you test API security specifically, beyond standard DAST? * What is mutation testing, and why does test coverage alone not guarantee good tests? ### Compliance and Monitoring * What does "policy as code" mean in practice? * How do you automate evidence collection for a SOC 2 or ISO 27001 audit? * What metrics would you track to show a DevSecOps program is working? * What is the difference between a SIEM and a vulnerability management platform? * How do you reduce alert fatigue without missing real incidents?
### CI/CD Pipeline Security **Q1. Walk me through how you would implement security in a CI/CD pipeline end to end, for a service handling user data.** A mature pipeline layers checks across every stage, with severity deciding what blocks versus what tickets. Pre-commit handles secrets scanning, locally, before anything ever reaches the shared repository. The build stage runs SAST against the source. The test stage runs SCA against dependencies and generates an SBOM. The packaging stage scans the built container image. Post-deploy, an automated DAST scan runs against staging before promotion to production. Commit -> Pre-commit secrets scan -> Build -> SAST + SBOM -> Test -> SCA (dependencies) -> Package -> Container image scan -> Staging -> DAST scan -> Production (only if all gates pass) ```yaml ## Simplified GitLab CI pipeline with staged security gates stages: [scan-secrets, build, test, package, deploy-staging, dast] secrets-scan: stage: scan-secrets script: gitleaks detect --source . --exit-code 1 sast: stage: build script: sonar-scanner -Dsonar.qualitygate.wait=true sca-and-sbom: stage: test script: - snyk test --severity-threshold=high - syft . -o spdx-json > sbom.json image-scan: stage: package script: trivy image --severity CRITICAL,HIGH --exit-code 1 $IMAGE dast: stage: dast script: zap-baseline.py -t https://staging.company.com ``` The tradeoff worth saying out loud unprompted: blocking on every finding at every stage from day one will stall the team. The rollout itself should be staged - warn-only for the first two to three weeks while the team triages the existing backlog, then switch to blocking on new findings only, then gradually tighten the threshold as the noise drops. **Q2. How would you reduce a 40-minute pipeline down to under 10 minutes without removing any security checks?** Measure before changing anything - pull per-stage timing data, since teams often assume tests are the bottleneck when it is usually image builds or sequential scanning. The highest-impact fixes, in order: run independent scans in parallel rather than sequentially (SAST and SCA do not depend on each other and can run at the same time), cache dependencies and base image layers so they are not re-downloaded every run, and use path-based change detection in a monorepo so unrelated services are not rebuilt and rescanned on every commit. ```yaml ## Run SAST and SCA in parallel instead of sequentially sast: stage: scan script: sonar-scanner sca: stage: scan script: snyk test ## Both jobs share the same stage name, so GitLab ## runs them concurrently instead of one after the other ``` The one thing not to do: skip DAST entirely to save time. DAST is the only check that tests the actual running application, so cutting it removes a category of bugs none of the other checks would have caught. If DAST is the slowest stage, run it against staging asynchronously after deploy rather than removing it. **Q3. What is the difference between SAST, DAST, and IAST, and when would you use IAST specifically?** SAST reads source code without running it. DAST attacks a running application from the outside with no knowledge of the source. **IAST** (Interactive Application Security Testing) sits in between - it instruments the running application with an agent and watches code execution from the inside while the application is being exercised by normal functional tests, combining the code-level visibility of SAST with the runtime accuracy of DAST. IAST is worth adding when DAST alone produces too many false positives or misses logic-level vulnerabilities that only show up when you can see what the code actually did with a given input, not just the HTTP response. The tradeoff is operational: IAST agents add overhead to the test environment and only catch what your existing functional test suite happens to exercise, so it is a complement to DAST and SAST, not a replacement for either. **Q4. How do you prevent a compromised CI pipeline from gaining full Kubernetes cluster credentials?** Two complementary approaches. First, scope the CI service account narrowly - it should only be able to update the image tag of the specific deployments it owns, never have cluster-admin or broad RBAC. Second, and more robust, move to a **GitOps** model where the CI pipeline never holds cluster credentials at all; it only pushes a new image and updates a manifest in Git, and a controller running inside the cluster (ArgoCD or Flux) pulls that change and applies it. ```yaml ## Scoped RBAC for a CI service account - ## can only update one specific deployment's image apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: ci-deploy-checkout namespace: production rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "patch"] resourceNames: ["checkout-service"] ``` > 💡 Green Flag: candidate mentions GitOps unprompted as the more robust long-term answer, not just "use RBAC," and explains why - no external system holding cluster credentials at all is a meaningfully different risk profile than a narrowly scoped one. ### Container and Kubernetes Security **Q5. How do you enforce that no container runs as root, at the cluster level rather than relying on every Dockerfile being written correctly?** Relying on every developer to remember `USER appuser` in every Dockerfile does not scale. Enforce it centrally using Pod Security Standards or an admission controller, so a pod that violates the policy is rejected before it is ever scheduled, regardless of what the Dockerfile says. ```bash ## Enforce the restricted Pod Security Standard ## on a namespace - blocks root containers, ## privileged mode, and host path mounts kubectl label namespace production \ pod-security.kubernetes.io/enforce=restricted ``` ```yaml ## Equivalent enforcement using Kyverno, with a ## clearer error message for developers apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: disallow-root-containers spec: validationFailureAction: Enforce rules: - name: check-runasnonroot match: resources: kinds: ["Pod"] validate: message: "Containers must set runAsNonRoot: true" pattern: spec: securityContext: runAsNonRoot: true ``` > 📌 Remember: Dockerfile-level controls are a good first layer, but they are advisory - a developer can always remove `USER appuser` under deadline pressure. Cluster-level enforcement is what actually guarantees the policy holds. **Q6. What is an admission controller, and how would you use one for security policy?** An admission controller is a piece of logic that intercepts requests to the Kubernetes API server before an object is persisted, and either approves, rejects, or modifies it. A **validating** admission controller can reject a pod outright - for example, blocking any image that has not been signed. A **mutating** admission controller can change the object automatically - for example, injecting a sidecar or adding default resource limits if none were specified. ```yaml ## Validating policy: only allow images ## from the company's private, scanned registry apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: restrict-image-registries spec: validationFailureAction: Enforce rules: - name: validate-registry match: resources: kinds: ["Pod"] validate: message: "Images must come from registry.company.com" pattern: spec: containers: - image: "registry.company.com/*" ``` The practical use cases worth naming in an interview: enforcing image provenance (only signed, scanned images run), enforcing resource limits on every pod, and blocking privileged containers cluster-wide. **Q7. How would you scan a Helm chart or raw Kubernetes manifests before they are applied, and what would you be looking for?** Static analysis tools for Kubernetes manifests - Checkov, Kubescape, or `kube-score` - check rendered YAML against known misconfiguration patterns: containers without resource limits, containers running privileged, missing NetworkPolicies, secrets mounted as environment variables instead of files, and missing `runAsNonRoot`. ```bash ## Render a Helm chart and scan the output before deploying helm template ./checkout-service > rendered.yaml checkov -f rendered.yaml --framework kubernetes ``` This should run as a CI step before the manifest is ever applied, not as a manual check someone remembers to do occasionally. The same scan should run in a pre-commit hook for fast local feedback, and again in CI as the enforced gate. **Q8. What is the risk of a default-allow network policy in a Kubernetes cluster running multiple teams' services?** Without an explicit NetworkPolicy, Kubernetes defaults to allowing all pod-to-pod traffic within the cluster. In a multi-tenant cluster, that means a compromised pod from one team's low-risk internal tool can directly reach another team's payment service over the network, with nothing in between to stop it - the blast radius of any single compromised pod is the entire cluster. ```yaml ## Default deny all traffic in a namespace, ## then explicitly allow only what is needed apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: production spec: podSelector: {} policyTypes: [Ingress, Egress] ``` The fix is starting from default-deny in every namespace and explicitly allowlisting only the specific service-to-service traffic that is actually needed. This is one of the highest-value, most commonly skipped controls in real clusters, because it has to be done deliberately - the unsafe default is the path of least resistance. ### Cloud and Infrastructure Security **Q9. How do you implement IaC security scanning for Terraform, and where in the workflow does it run?** Tools like Checkov or Terrascan parse Terraform files statically and check them against known misconfiguration patterns - public S3 buckets, security groups open to 0.0.0.0/0, unencrypted RDS instances - before any `terraform apply` ever runs. ```bash ## Scan Terraform before applying checkov -d ./infra --framework terraform ## Example finding: security group allows ## unrestricted ingress on port 22 ``` It should run in three places: as an IDE plugin for instant feedback while writing, as a pre-commit hook, and as a required CI step on every pull request, with critical findings blocking the merge. Catching a public S3 bucket in a PR review costs nothing. Catching it after `terraform apply` has already created the real bucket means you are now doing incident response. **Q10. How do you detect configuration drift between your Terraform state and what is actually running in the cloud account?** Drift happens when someone makes a manual change directly in the console - fixing something "quickly" during an incident, for example - and that change is never reflected back into the Terraform code. Run `terraform plan` on a schedule, even when no code has changed, and alert if it reports any difference; a non-empty plan against unchanged code means something in the real environment has drifted from what is declared. ```bash ## Scheduled drift detection - run nightly via CI cron terraform plan -detailed-exitcode ## Exit code 2 means a difference was detected ## between live state and the Terraform config ``` Tools like Terraform Cloud or Spacelift can automate this detection and alerting natively. The follow-up question worth anticipating: what do you do when drift is found? Either reconcile the code to match the legitimate manual change, or run `terraform apply` to revert the unauthorized change back to the declared state - which path depends entirely on whether the manual change was a deliberate, approved fix or an unauthorized one. **Q11. What is the difference between an IAM policy and a Service Control Policy, and when would you use each?** An IAM policy grants permissions to a specific user, role, or service within an account. A **Service Control Policy** (SCP) sets the maximum permissions boundary for an entire AWS account, evaluated before any IAM policy - it is a guardrail, not a grant. Even a user with full administrator IAM permissions cannot exceed what the SCP allows. ```json { "Effect": "Deny", "Action": ["ec2:RunInstances"], "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": ["ap-south-1"] } } } ``` This SCP blocks launching EC2 instances outside the Mumbai region for every identity in the account, regardless of their individual IAM permissions. Use SCPs at the organization level for non-negotiable guardrails - region restrictions, blocking the disabling of CloudTrail - and IAM policies for the day-to-day, fine-grained access that differs by role. ### Secrets and Identity Management **Q12. What is the difference between static and dynamic secrets, and why would you prefer dynamic secrets for database access?** A static secret is a fixed credential that exists until someone manually rotates it - a database password sitting in a secrets manager, valid indefinitely until changed. A dynamic secret is generated on demand, scoped to a single use or a short time window, and automatically expires. ```bash ## Vault generates a unique, time-limited ## database credential per request vault write database/roles/checkout-service \ db_name=production-db \ creation_statements="CREATE ROLE \"{{name}}\" \ WITH LOGIN PASSWORD '{{password}}' \ VALID UNTIL '{{expiration}}';" \ default_ttl="1h" ``` The security benefit is direct: if a dynamic credential leaks, it is only useful for up to an hour and only for the specific permissions it was scoped to. A leaked static credential is useful indefinitely until someone notices and manually rotates it. The tradeoff is operational complexity - dynamic secrets require running Vault or an equivalent and integrating every service with it, which is more setup than just dropping a password into a secrets manager. **Q13. How would you rotate a database credential in production without causing downtime?** The key is overlap, not a hard cutover. Create the new credential alongside the old one rather than replacing it in place, update the application to use the new credential, confirm it is working, and only then revoke the old one. 1. Create new DB user/credential (old one still active) 2. Update secret in Vault/Secrets Manager 3. Application picks up new credential (rolling restart or live reload, depending on your secret delivery method) 4. Confirm new credential is working in logs/metrics 5. Revoke old credential only after step 4 is confirmed If your secret delivery mechanism does not support a live reload, a rolling pod restart with the new credential mounted achieves the same overlap, since old pods keep serving traffic with the old (still valid) credential while new pods start up with the new one. **Q14. What is the risk of storing secrets as plain Kubernetes Secrets without an external secrets manager?** Kubernetes Secrets are base64-encoded, not encrypted, by default - base64 is an encoding, not encryption, and anyone with read access to the Secret object (or to etcd, if it is not encrypted at rest) can trivially decode it. There is also no built-in rotation, and access auditing is limited to standard Kubernetes RBAC audit logs rather than the detailed access logging a dedicated secrets manager provides. ```bash ## This is not encryption - it is reversible in one command echo "U3VwM3JTZWNyZXQxMjM=" | base64 -d ## Output: Sup3rSecret123 ``` The fix is enabling encryption at rest for etcd at minimum, and ideally integrating an external secrets manager (Vault, AWS Secrets Manager) via the Secrets Store CSI driver, which mounts secrets as files synced from the external system rather than storing them natively as Kubernetes objects. ### Application Security Testing **Q15. Can you name at least five categories from the OWASP Top 10, and explain one in depth?** Broken Access Control, Cryptographic Failures, Injection, Insecure Design, and Security Misconfiguration are five of the current categories. Going deeper on **Broken Access Control**: this happens when an application checks that a user is logged in but fails to check that they are allowed to access the *specific* resource they are requesting - the classic example is changing `/api/orders/1234` to `/api/orders/1235` in the URL and successfully viewing another user's order because the backend only verified authentication, not authorization for that specific record. ```python ## Vulnerable: checks login, not ownership @app.route("/api/orders/<order_id>") @login_required def get_order(order_id): return db.get_order(order_id) ## anyone logged in can fetch any order ## Fixed: verify the order actually belongs to this user @app.route("/api/orders/<order_id>") @login_required def get_order(order_id): order = db.get_order(order_id) if order.user_id != current_user.id: abort(403) return order ``` > **Note:** this category consistently ranks at or near the top of the OWASP list because it is an application logic flaw, not something a generic scanner reliably catches - it requires understanding the business rule of who should be allowed to see what. **Q16. How do you test API security specifically, beyond what a standard DAST scan covers?** Standard DAST crawls and attacks an application largely based on what it can discover automatically, which works reasonably well for traditional web pages but misses a lot in API-first applications where there is no UI to crawl. API security testing instead starts from the API specification (OpenAPI/Swagger) and systematically tests every documented endpoint and parameter, including ones DAST's crawler would never find on its own. ```bash ## Feed an OpenAPI spec directly into ZAP's API scan ## instead of relying on crawling zap-api-scan.py -t https://api.company.com/openapi.json \ -f openapi ``` Beyond the automated scan, API-specific testing should cover authorization at the object level (the broken access control pattern above, tested systematically across every endpoint), rate limiting (can you hammer an endpoint without being throttled), and excessive data exposure (does the API return more fields in the response than the frontend actually uses, leaking internal data unintentionally). **Q17. What is mutation testing, and why doesn't high test coverage alone guarantee good security testing?** Test coverage tells you what percentage of your code *ran* during your test suite - it says nothing about whether your tests would actually catch a bug if one were introduced. A test that calls a function but never checks its output still counts toward coverage. **Mutation testing** addresses this gap by automatically introducing small deliberate bugs ("mutants") into your code - flipping a `>` to `>=`, changing a `true` to `false` - and then running your test suite against each mutant. If your tests still pass with the bug introduced, that test was not actually verifying the behavior it claimed to cover. ```bash ## Example: running PIT mutation testing on a Java project mvn org.pitest:pitest-maven:mutationCoverage ## Reports a mutation score - the percentage of ## introduced bugs that your tests actually caught ``` A codebase can have 90 percent line coverage and a poor mutation score, which means most of that coverage is decorative. For security-relevant code specifically - authentication, authorization, input validation - mutation testing is a genuinely useful signal that your tests would catch a regression, not just that they execute the code. ### Compliance and Monitoring **Q18. What does policy as code mean, and how would you implement it for a Kubernetes platform?** Policy as code means writing your security and compliance rules in a machine-readable, version-controlled format and having them evaluated automatically, instead of relying on a manual checklist or a wiki page nobody reads. Tools like Open Policy Agent (OPA) with Rego, or Kyverno with plain YAML, let you express a rule like "no container may run as root" or "every namespace must have a default-deny NetworkPolicy" as code that runs at admission time. ```rego ## OPA Rego policy: deny pods without resource limits package kubernetes.admission deny[msg] { input.request.kind.kind == "Pod" container := input.request.object.spec.containers[_] not container.resources.limits msg := sprintf("Container %v has no resource limits", [container.name]) } ``` The value over a manual checklist is consistency and speed - the policy runs identically on every single deployment, every time, with no human having to remember to check, and the same policies can be version-controlled, reviewed, and tested like any other code. **Q19. How would you automate evidence collection for a SOC 2 audit instead of scrambling manually when the audit window opens?** Continuous evidence collection beats point-in-time scrambling. Configure your tools to continuously export the artifacts an auditor will eventually ask for: access review reports from your IAM system on a quarterly schedule, vulnerability scan results with remediation timestamps, CloudTrail logs proving change management, and ticket records showing incidents were investigated and closed. ```bash ## Example: scheduled job exporting quarterly ## IAM access review evidence 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 automate much of this mapping between technical evidence and specific SOC 2 control requirements. The mid-level engineer's role is usually not choosing the compliance framework, but making sure the technical controls behind it (encryption, access control, logging, vulnerability management) are actually running continuously and exporting evidence automatically, rather than being something the team has to reconstruct manually every audit cycle. **Q20. What metrics would you track to show a DevSecOps program is actually working, not just busy?** Pick metrics that show trend and outcome, not just volume of activity. Mean time to remediate (MTTR) for vulnerabilities, broken down by severity, shows whether fixes are actually happening quickly, not just being found. The percentage of vulnerabilities caught pre-production versus in production directly demonstrates whether shift-left is working - a rising pre-production catch rate is a real signal. Deployment frequency alongside change failure rate together show that security additions are not silently slowing the team down or, worse, getting bypassed under pressure. > 📌 Remember: a metric like "number of vulnerabilities found" on its own is a misleading vanity number - it goes up when you add a new scanner regardless of whether the codebase got more or less secure. Pair it with remediation rate and trend over time, not a raw count. **Q21. What is the difference between a SIEM and a vulnerability management platform, and do you need both?** A **SIEM** (Security Information and Event Management) aggregates logs and events from across your systems in near real time and looks for patterns that indicate an active attack or anomaly happening right now - failed login spikes, unusual data access patterns. A **vulnerability management platform** tracks known weaknesses that exist in your systems whether or not anyone is actively exploiting them - unpatched CVEs, misconfigurations - and tracks them through to remediation. Yes, you generally need both, because they answer different questions. The SIEM answers "is something bad happening right now." The vulnerability management platform answers "what weaknesses exist that could let something bad happen." A mature program correlates the two: a vulnerability platform might flag a critical unpatched CVE on an internet-facing service, and the SIEM is what would actually detect someone exploiting it before the patch lands. **Q22. How do you reduce alert fatigue in a security monitoring setup without missing real incidents?** Alert fatigue happens when the signal-to-noise ratio gets so bad that engineers start ignoring pages by reflex, which is more dangerous than having no alerting at all - a real incident gets dismissed as "probably another false positive." The fix is tiered severity with different response expectations per tier, and aggressive tuning of anything with a high false-positive rate. Audit every alert that fired over the last 30 days. Anything with a false-positive rate above roughly 20 percent gets fixed (better thresholds, better correlation rules) or removed entirely - a bad alert deleted is worth more than a bad alert tolerated. Route truly critical, high-confidence alerts to page immediately. Route everything else to a ticket queue reviewed during business hours rather than a 3 AM page. The goal is that every page someone receives is one they genuinely need to act on right then.
### Q23. Scenario - The Pipeline With Zero Security Gates You join a team with a CI/CD pipeline that has never had a single security gate. You have one sprint to propose and implement the first three security controls. What do you pick, and in what order? Order by blast radius prevented per unit of effort, not by what is most impressive to demonstrate. Secrets scanning first - it is a few hours of setup and prevents the single worst failure mode, a live credential in a public or widely shared repository. Dependency scanning (SCA) second - most codebases are carrying known CVEs in their dependencies without anyone realizing it, and the fix is often a version bump rather than a code change. IaC scanning third, if the team manages its own infrastructure - a single misconfigured security group or public S3 bucket can be a bigger incident than most application-level bugs. Resist the instinct to also propose a full SIEM or a DAST pipeline in week one; those are real but second-wave priorities once the cheap, high-impact controls are in place and the team has adjusted to the new workflow. ### Q24. Scenario - The Friday CVE A critical CVE drops at 4 PM on a Friday, affecting a library used by five of your services. The fix requires a version bump that has not been tested against your codebase. What do you do? First, assess actual exploitability in your context before treating every critical CVE as an immediate fire - check whether the vulnerable function is actually reachable from your code paths, and whether the affected services are internet-facing or internal-only. If it is genuinely exploitable and internet-facing, that changes the calculus toward acting today rather than Monday. If a same-day fix is warranted, patch and deploy the internet-facing, highest-risk service first with focused smoke testing rather than full regression, and treat the other four as a tracked, prioritized Monday morning task with the risk explicitly communicated to your lead in the meantime. What you do not do is silently decide it can wait until Monday without telling anyone the decision was made, or panic-deploy an untested version bump to all five services simultaneously with no rollback plan. ### Q25. Scenario - The False Positive Mutiny A SAST tool you championed is now blocking 50 deployments a day with what the team insists are mostly false positives. They want it disabled entirely. How do you respond? Do not simply defend the tool, and do not simply agree to disable it - investigate the actual false-positive rate first, because "mostly false positives" said in frustration and "mostly false positives" confirmed by data are often different numbers. Pull a sample of the last 30 flagged findings and triage each one honestly. If the rate genuinely is high, the fix is tuning the ruleset and adjusting severity thresholds, not abandoning static analysis entirely - propose a two-week tuning sprint with a clear before/after metric. If the rate turns out lower than the team's perception, that is also worth surfacing honestly, along with a faster feedback mechanism (inline IDE warnings instead of only failing in CI) so issues are caught before they ever become a blocked deployment. ### Q26. Scenario - The Buried Secret You discover that a teammate committed a hardcoded secret in a pull request that was merged and deployed three weeks ago. How do you handle it? Treat the timeline as it is, not as you wish it were - a three-week-old exposed secret needs to be rotated immediately regardless of how uncomfortable that conversation is, because the exposure window has already happened and waiting longer only extends it. Notify the teammate directly and privately first, not in a public channel, framing it as a process gap (why didn't the pre-commit hook or pipeline catch this) rather than a personal failure. Rotate the credential, audit any access logs for unusual activity during the exposure window, and use it as the concrete justification for adding (or fixing) automated secrets scanning if it was not already catching this pattern. ### Q27. Scenario - The Tool Choice Under Budget Pressure You are asked to choose between two SAST tools with a small budget and no existing standard. How do you make the decision and avoid it becoming a months-long debate? Set a one-week, time-boxed evaluation with explicit criteria agreed before you start, not after - language and framework support for your actual stack, integration effort with your existing pipeline, false-positive rate on a real sample of your own codebase (not the vendor's demo repo), and total cost including any per-seat licensing. Run both tools against the same real repository for the trial, not separate toy projects, since false-positive rate especially only means something measured against your actual code. Present the comparison with the data, make a recommendation, and set a revisit date (six to twelve months out) rather than treating the decision as permanent - tooling decisions under time pressure should be reversible, not perfect. ### Q28. Scenario - The Unprioritized Pen Test Report An external penetration test report comes back with 40 findings and no prioritization beyond a generic severity label from the vendor. What do you do before bringing it to your team? Vendor severity labels are a starting point, not the final word - re-prioritize using your own context, because a "critical" finding on an internal admin tool with no internet exposure is genuinely less urgent than a "high" finding on a public-facing payment endpoint. Build a simple matrix: exploitability, actual business impact if exploited, and estimated remediation effort. Group findings into quick wins (high impact, low effort - fix this week), real projects (high impact, high effort - schedule and resource properly), and accepted risk for now (low impact - track but do not let it block other work). Bring your team a prioritized, actionable list with a proposed plan, not a raw 40-item PDF, which is far more likely to actually get acted on instead of becoming permanent backlog clutter. ### Q29. Scenario - The Deadline Pressure to Skip Review Your manager asks you to skip the security review for a feature to hit a launch deadline. How do you respond? Do not frame your answer as a flat refusal, and do not simply comply either - get specific about what "skip" actually means and what it would cost. Ask what about the review is the bottleneck; often a full review can be compressed into a focused 30-minute check of the highest-risk surfaces (authentication, data access, new external integrations) rather than skipped entirely. Offer that compressed version as a concrete alternative with a clear statement of residual risk: "I can do a focused review of just the auth flow and data access paths in 45 minutes instead of the full review - that covers the highest-risk parts, but I want it on record that we're accepting reduced coverage on the rest to hit this date." This gives your manager an actual decision to make with the tradeoff visible, instead of either silently complying with a risk nobody acknowledged, or being the engineer who only ever says no.
**Q30. Tell me about a time you found a vulnerability and had to manage the disclosure and fix.** *Strong Answer Framework:* Walk through how you confirmed the finding was real before escalating, who you told and in what order (usually the owning team first, then a broader security or leadership channel if severity warranted it), and how you balanced urgency against not causing unnecessary panic. Close with the actual fix and what changed afterward - a new gate, a new test, a new piece of documentation - so the story shows a system improvement, not just a one-time save. **Q31. Describe a time you had to convince a developer to fix a security issue they did not think was important.** *Strong Answer Framework:* The strongest answers do not lean on authority ("I told them it was a policy"). They explain how you made the risk concrete and specific to that developer's context - showing an actual exploit path rather than citing an abstract CVSS score, for instance. Mention what you did when persuasion alone was not enough (escalating with data, proposing a smaller interim fix) and be honest if the resolution was a compromise rather than a clean win. **Q32. Tell me about a CI/CD pipeline you owned or significantly improved.** *Strong Answer Framework:* Be specific about what state it was in before, what you changed, and a real measurable outcome - build time reduced from X to Y, a specific class of bug caught that previously reached production, deployment frequency increased because the pipeline became trustworthy enough to deploy on. Avoid describing only the tools added; describe the actual before-and-after behavior of the team. **Q33. Describe how you handle conflicting priorities between security requirements and delivery velocity.** *Strong Answer Framework:* Show that you do not treat this as a binary - good answers describe finding the smallest control that addresses the real risk rather than either blocking everything or waving everything through. Give a specific example where you proposed a scoped, faster alternative to a full process, and explain how you decided that scoped version was still sufficient. **Q34. Tell me about a mistake you made in a deployment or pipeline, and what you learned.** *Strong Answer Framework:* Pick a real incident, however small, and be precise: what happened, how you found out, what the immediate fix was, and what specific process or technical change you made afterward so it cannot happen the same way again. A vague "I learned to be more careful" is a weak close. A specific "I added a pre-deploy check that would have caught this exact class of mistake" is a strong one. **Q35. How do you keep up with new vulnerabilities, tools, and techniques at a level beyond reading headlines?** *Strong Answer Framework:* Go beyond "I read security blogs." Mention something hands-on - running a vulnerable-by-design lab environment occasionally, reading the actual CVE writeups for vulnerabilities relevant to your stack rather than just the headline, or contributing to or reading the source of a security tool your team actually uses so you understand its real limitations, not just its marketing. **Q36. Tell me about a time a team pushed back on a security control you added.** *Strong Answer Framework:* Show that you treated the pushback as signal worth investigating rather than an obstacle to overcome. Describe what you actually changed as a result, even if the core control stayed - tuning a threshold, improving the error message, adding a faster local feedback loop. The signal interviewers want is whether you can hold a security position while still being genuinely responsive to legitimate friction, rather than digging in or caving entirely. **Q37. Describe a time you had to learn a new tool or technology quickly to solve a problem at work.** *Strong Answer Framework:* Unlike the junior version of this question, the mid-level answer should show judgment about *what* to learn and how deep to go, not just learning speed. Describe how you scoped the learning to what the immediate problem actually required, used the official documentation and source code over scattered blog posts when the stakes were high, and validated your understanding with a small test before applying it to anything that mattered. **Q38. How do you handle being on call and responding to a security alert at an inconvenient time?** *Strong Answer Framework:* Describe your actual triage process under time pressure: confirming the alert is real before acting, containing first if there is active risk, then investigating root cause once the immediate danger is handled rather than the other way around. Mention how you handled communication during the incident - who you informed and when - and what you did afterward, ideally a blameless writeup with concrete follow-up actions. **Q39. Tell me about a time you gave feedback to a peer about a security issue in their code.** *Strong Answer Framework:* Show that you delivered the feedback in a way that kept the relationship intact - direct and specific about the issue, not vague or softened to the point of being unclear, but also not framed as a personal failing. Mention the actual outcome: did they fix it, did you pair on the fix, did it change how either of you approached code review afterward.
| Tool / Practice | What It Addresses | |:-----------------|:-------------------| | Checkov / Terrascan | IaC misconfigurations before `apply` | | Kyverno / OPA | Cluster-level policy enforcement | | Vault dynamic secrets | Short-lived, scoped database credentials | | Syft + Grype | SBOM generation and CVE matching | | PIT / Stryker (mutation testing) | Whether tests actually catch regressions | ### Common Mistakes Mid-level candidates often describe tools without describing tradeoffs, which is the single clearest signal an interviewer uses to separate junior-adjacent answers from genuinely mid-level ones - always be ready to say not just what a control does but what it costs and when you would relax it. A related mistake is presenting every security recommendation as non-negotiable, which reads as inflexibility rather than rigor; the stronger move is showing you can scope a control down to fit real constraints while still protecting against the actual risk. Many candidates underestimate how much weight interviewers put on real incident stories, and arrive without one prepared, which leaves them improvising a thin answer to what is often the single highest-signal question in the interview. Another frequent gap is talking about Kubernetes or cloud security only at the Dockerfile or IAM-policy level without mentioning cluster-wide or account-wide enforcement (admission controllers, SCPs), which suggests experience with individual services rather than a platform. Some candidates also conflate compliance with security, treating "we pass our SOC 2 audit" as proof the system is secure, when a mature answer distinguishes the two and explains how continuous technical controls feed the compliance evidence rather than being driven by it. A subtler mistake is being unable to explain *why* a tool's rollout failed or succeeded with a team, only that it was adopted, since interviewers are specifically listening for change management awareness at this level. Finally, candidates sometimes answer scenario questions with a purely technical fix and skip the communication and prioritization reasoning entirely, when the scenario questions at mid-level are usually testing judgment under ambiguity just as much as technical correctness.
You have owned a pipeline, not just used one. You have debugged a failed deployment without someone walking you through ...
These are table stakes for a mid-level round. If you need to look several of these up, go back to the relevant module fi...
CI/CD Pipeline Security Q1. Walk me through how you would implement security in a CI/CD pipeline end to end, for a servi...
Q23. Scenario - The Pipeline With Zero Security Gates You join a team with a CI/CD pipeline that has never had a single ...
Q30. Tell me about a time you found a vulnerability and had to manage the disclosure and fix. Strong Answer Framework: W...
Tool / Practice What It Addresses Checkov / Terrascan IaC misconfigurations before apply Kyverno / OPA Cluster-level pol...
Mid-Level DevSecOps Engineer (3-5 years) Company Type Range Service company Rs 10L - Rs 16L Mid-size product startup Rs ...
Aligns directly with DevOps, Site Reliability (SRE), and Platform Engineering job descriptions.