What Security Engineers Actually Get Asked in 2026 Interviews

First, assess exploitability. Can it read data, modify data, or execute commands? That gap matters a lot for prioritization. Document the finding with a proof-of-concept in a controlled way, then report to the engineering owner with severity and reproduction steps.

The fix itself is parameterized queries or prepared statements – not input sanitization alone. Sanitization is not a primary control here; it’s a secondary layer. Then verify the fix with retesting, not just code review.

Where candidates get this wrong: they describe the fix before they describe the discovery and communication steps. Interviewers at mature companies care a lot about how you handle disclosure and prioritization, not just remediation.

Authentication is verifying identity. A bug: accepting expired JWTs because the server skips signature validation on certain paths (misconfigured middleware).

Authorization is what that identity is allowed to do. A bug: an API endpoint that checks “is the user logged in?” but not “does this user own the resource they’re requesting?” That’s broken object-level authorization, which OWASP currently ranks as the top API security risk.

A vulnerability scan is automated – it finds known CVEs, misconfigurations, missing patches. Fast, repeatable, broad. Falls short with logic flaws, business-context bugs, and chained vulnerabilities that only reveal themselves when exploited together.

A penetration test is manual, constrained by scope and time, and tries to simulate what an attacker would actually do. Falls short because it’s periodic – you might pen-test in March and deploy a vulnerable dependency in April. Neither alone is sufficient. The honest answer is: use scanners continuously and pen-test annually at minimum, plus after major architectural changes.

TLS 1.3 reduces handshake latency (1-RTT instead of 2-RTT), removes legacy cipher suites like RSA key exchange and RC4, makes forward secrecy mandatory, and encrypts more of the handshake itself including the server certificate.

Teams still running TLS 1.2 only are exposed to downgrade attacks in misconfigured environments and legacy cipher negotiation. The practical instruction: configure servers to prefer TLS 1.3, disable 1.0 and 1.1 entirely, and test with OpenSSL or testssl.sh quarterly. I’ve seen staging environments where someone re-enabled TLS 1.0 “temporarily” two years ago and it was still on.

Zero-trust assumes there’s no implicit trust based on network location. Every access request is authenticated, authorized, and continuously validated regardless of whether the request comes from inside the perimeter or outside it.

VPNs solve “getting onto the network” but create a problem: once you’re inside, the castle-and-moat model gives you lateral movement capability. A compromised device with VPN access can reach a lot of internal systems it has no business touching. Zero-trust makes that much harder by enforcing identity-based, per-resource access. The hard part is implementation complexity – especially for legacy systems that weren’t built for per-request auth.

The NIST 800-61 framework is a reasonable baseline: Preparation, Detection and Analysis, Containment/Eradication/Recovery, Post-Incident Activity. But interviewers want to hear how you adapt it, not just name it.

For ransomware specifically: isolate the affected machine by cutting network access, but don’t shut it down – volatile memory may contain encryption keys or attacker tooling. Check for lateral movement immediately, because ransomware actors usually have been in the environment longer than the encryption event suggests. Notify legal and executive leadership early – ransom payment decisions are not engineering decisions.

One thing I didn’t know until I saw it firsthand: the time between initial access and ransomware detonation is often weeks, not hours. Most attackers establish persistence and exfiltrate data before encrypting. That changes your containment priority completely.

Start with context. Is this server known to do batch jobs or scheduled tasks overnight? Check asset inventory first. If there’s no legitimate reason for elevated DNS traffic, investigate the query content: unusually long subdomain strings, queries to domains registered within the last week, high query frequency to a single domain.

Those patterns suggest DNS tunneling – an attacker encoding data exfiltration or C2 communication in DNS queries. If that’s what you’re seeing, block the destination at the DNS resolver, isolate the host, pull memory and process logs, and correlate with recent logins and software installs. Document the timeline before touching anything else.

Context. Is this behavior normal for this specific user and system at this time of day? Does the timing correlate with any other events in the SIEM? Is the source IP or domain in a threat intel feed?

The harder question is what you do when context is ambiguous. My approach: treat it as a true positive until I have evidence otherwise, but scope the investigation proportionally. A low-severity alert with one weak indicator gets documented and monitored. A medium-severity alert with two correlated indicators gets escalated and contained if needed.

Alert fatigue is real. At one point I was triaging 200+ alerts a day and found myself pattern-matching to close rather than actually investigating. The honest answer is that SIEM tuning – reducing false positive rate through detection engineering – is as important as the investigation itself.

It depends on your threat model, but for a SaaS company the highest-value areas are: Initial Access (phishing, credential stuffing against your authentication endpoints), Persistence (new service accounts, scheduled tasks, OAuth app grants), Privilege Escalation, and Exfiltration.

Defense evasion is often under-monitored because it’s harder to detect by definition. Lateral movement matters more if you have on-prem infrastructure or complex VPC setups. For most SaaS companies in 2026, the attack paths that matter most start with credential compromise or supply chain – not network perimeter breaches.

Server-Side Request Forgery lets an attacker trick your server into making HTTP requests to unintended destinations. In isolation that sounds limited. In a cloud environment, the instance metadata service at 169.254.169.254 becomes the real target.

If your EC2 instance has an IAM role attached, an SSRF vulnerability that can reach the metadata endpoint can return the instance’s temporary IAM credentials. The Capital One breach in 2019 was SSRF-based – an attacker retrieved credentials from the metadata service and used them to access S3 buckets. Mitigation: use IMDSv2 (which requires a PUT request to get a token first, blocking basic SSRF), validate and whitelist URLs your server will fetch, and keep IAM roles scoped to least privilege.

The “moving fast” qualifier is the honest part of this question. A fully hardened K8s cluster with OPA/Gatekeeper policies, pod security admission controllers, network policies on every namespace, and Falco for runtime detection takes weeks to implement well and will slow down engineers who are used to deploying without guardrails.

Pragmatic starting point: RBAC with actual least privilege (not just “don’t use cluster-admin”), network policies to block pod-to-pod traffic by default, image scanning in the CI pipeline before deployment, and audit logging enabled on the API server. Those four things are achievable without grinding the team to a halt.

The rest – secrets management via Vault or Sealed Secrets, runtime threat detection, service mesh for mTLS – layer in over time as the team builds familiarity.

The API list is more specific about object-level concerns. BOLA (Broken Object-Level Authorization) is the top risk – where your API lets user A access user B’s data by changing an ID in the request. This is distinct from standard access control failures because it’s not about roles, it’s about ownership of specific records.

Other API-specific items: Broken Object Property Level Authorization (mass assignment, returning more fields than needed), Unrestricted Resource Consumption (no rate limiting leading to DoS or account enumeration), and SSRF. The web app list has more injection and XSS focus. For API-heavy architectures, the API Top 10 is the more relevant checklist.

The framework I reach for first is STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. It gives you a checklist to work through systematically for each component and data flow in the feature.

In practice, I start by drawing the data flow diagram – what data enters, where it goes, what transforms it, where it leaves the system. Then I ask STRIDE questions at each trust boundary. The goal is not to find every possible bug (you won’t) but to identify the highest-risk flows and make sure they have explicit mitigations.

The hardest part is getting engineers to do this before shipping, not after. If I’m honest, threat modeling works best when it’s embedded in the design review process, not treated as a separate security gate.

This is where a lot of teams have real exposure. Common bad patterns: secrets in environment variables passed as plain text, secrets committed to git (even accidentally), secrets stored in CI config files that get checked in.

Better: use a secrets manager (AWS Secrets Manager, HashiCorp Vault, GitHub secrets with OIDC) and have the pipeline authenticate to retrieve credentials at runtime rather than storing them statically. Give each pipeline only the permissions it needs for that specific job. Rotate credentials automatically. Scan commits for accidental secret exposure with something like truffleHog or git-secrets in pre-commit hooks. The OWASP CI/CD Security Top 10 calls insufficient credential hygiene out specifically – it’s one of the most common findings in pipeline audits.

This matters more than people expect in security interviews. The technical answer is never the whole answer.

I try to translate the risk into business language: what’s the realistic exploit scenario, what data or functionality is at stake, what’s the likely consequence (regulatory fine, customer notification requirement, incident response cost, reputational damage). Engineers respond to specifics. “This SSRF could give an attacker our AWS credentials and read every file in our customer data bucket” is more useful than “SSRF is a high-severity vulnerability.” If the team is still pushing back, the right escalation path is through the product or engineering manager, not security acting as a blocker unilaterally.

A SYN flood sends a large volume of TCP SYN packets with spoofed source IPs. The server allocates a connection state for each one (half-open connections), waiting for the ACK that never comes, eventually exhausting its connection table and dropping legitimate traffic.

SYN cookies are the standard mitigation: the server doesn’t allocate state until the client completes the handshake. The server encodes connection information in the sequence number itself. Cloud providers handle most of this at the network layer for anything hosted there – on-prem environments need rate limiting, firewall rules blocking SYN floods, and possibly a scrubbing service for volumetric attacks.

A network firewall operates at layers 3 and 4 – it allows or blocks based on IP addresses, ports, and protocols. Fast, stateful, but has no visibility into application-layer content.

A WAF operates at layer 7 and understands HTTP. It can inspect request bodies, headers, and payloads to block SQL injection, XSS, and malicious inputs. Falls short with API abuse patterns (valid requests from legitimate clients doing something they shouldn’t), complex logic vulnerabilities, and authenticated attacks where the WAF can’t distinguish malicious from benign traffic by structure alone. Neither is a substitute for writing secure code.

The ones that correlate fastest with attacker activity:

• 4624 and 4625: successful and failed logons, especially with logon type 3 (network) and type 10 (RemoteInteractive)
• 4688 with command-line logging enabled: process creation, where you’ll find things like encoded PowerShell executions
• 4698 and 4702: scheduled task creation and modification, a common persistence mechanism
• 1102: security audit log cleared – almost always suspicious
• 4104: PowerShell script block logging, which shows you what scripts actually executed

4672 (special privileges assigned) paired with an unexpected account is often where privilege escalation shows up.