Security engineer interview questions, with worked answers

How to use these questions

Say each short answer aloud until it sounds like you. Then attach one real case: a design you reviewed, an alert you chased, a gap you closed. Interviewers dig into details, and a true story survives the digging. Leave out anything a former employer would not want shared.

What a security engineer is expected to know

• Foundations: networkingAsked in 20% of security engineer ads (as of 5 Nov 2026).TCP/IP, DNS, TLS, firewalls and segmentation; enough to read a packet capture and spot odd traffic., LinuxAsked in 24% of security engineer ads (as of 5 Nov 2026).Harden a server, read its logs and find what a process is doing; most cloud workloads run on Linux. and Windows, and how real attacks move from a first foothold to the data.
• Design: threat modelling, the OWASP Top 10 web risks, identity and access, and secrets management.
• Cloud: guardrails, identity and logging on AWSAsked in 13% of security engineer ads (as of 5 Nov 2026).IAM, organisation guardrails, logging and the security services of Amazon's cloud. or AzureAsked in 8% of security engineer ads (as of 5 Nov 2026).Entra ID (identity), policies, Defender and logging in Microsoft's cloud, common in European companies., and container platforms such as KubernetesAsked in 9% of security engineer ads (as of 5 Nov 2026).Pod security, network policies, secrets and admission rules for container platforms..
• Detection and response: a SIEM, alert triage and the steps of incident response.
• Running the programme: vulnerability management, secure development, standards such as ISO 27001Asked in 30% of security engineer ads (as of 5 Nov 2026).The international standard for an information security management system: risks, controls, audits., and explaining riskAsked in 29% of security engineer ads (as of 5 Nov 2026).Explain a risk to people who are not in security, in their terms, without fear or jargon. to people outside security.

Threats, web risks, identity and secrets

How would you threat-model a new feature before it is built?

What they check: that you find the risks early and in a structured way, not by gut feeling.

Short answer: "I draw how data flows through the feature: users, services, data stores and the trust boundaries between them. At each boundary I ask what could go wrong, using STRIDE as a checklist, then rank the threats by likelihood and impact and agree a fix or an accepted risk for each with the team."

The full answer, in four steps:

1. Draw it. A simple data flow diagram: who sends what to where, what is stored, and where trust changes, such as the internet meeting your API or one service calling another.
2. Ask what can go wrong. STRIDE names six kinds of threat: spoofing an identity, tampering with data, repudiation (denying an action because nothing proves it), information disclosure, denial of service, and elevation of privilege. Walk each boundary with them.
3. Rank. Not every threat matters equally. Weigh how easy it is and how much harm it would do, and start with the few that are both likely and serious.
4. Decide and record. For each top threat: a control, an owner and a date, or a risk the product owner accepts in writing. Revisit the model when the design changes.

A weak answer: "I would run a scanner when it is finished." A scanner finds bugs in code; a threat model finds design flaws no scanner sees.

Follow-up: "The team has two days. What do you cut?" Keep the diagram and the boundaries, skip the long write-up, and focus on authentication, authorisation and the most sensitive data.

Which risks of the OWASP Top 10 do you see most, and how do you prevent them?

What they check: that you know the common web flaws and the fix that works, not only the names.

Short answer: "The OWASP Top 10 is a ranked list of the most serious web application risks. Broken access control comes up most in my reviews: a user reaches data or actions that are not theirs. Injection, weak authentication, risky settings and outdated components follow. Each has a standard defence, and most belong in shared code so every team gets them."

The full answer: Broken access control is stopped by checking, on the server, for every request, that this user may do this to this object, never by hiding a button. Injection, where input is treated as a command, is stopped by keeping data and commands apart with parameterised queries and safe library calls. Cryptographic failures are avoided with standard libraries, encryption in transit and at rest, and no home-made crypto. Security misconfiguration shrinks with hardened defaults and settings in code. Vulnerable components need a list of what you run and a way to update it quickly.

A weak answer: reciting the list in order without a single fix. Follow-up: "A tester changes an invoice number in the address bar and sees another customer's invoice." That is broken access control; fix the ownership check on the server, look for the same pattern in other endpoints, and check the logs for anyone who used it.

How do you design identity and access for a growing company?

What they check: least privilege that works in daily life, not on paper.

Short answer: "One identity per person from a central provider with single sign-on, MFA (multi-factor authentication) everywhere, access granted through roles rather than one by one, and least privilege: each person and service gets only what the task needs. Access is reviewed regularly and removed the day someone leaves."

The full answer: Identity and access management, IAM for short, covers people and machines. For people: single sign-on so there is one place to switch access off, phishing-resistant MFA such as security keys for admins, and roles mapped to jobs. Admin rights are granted just in time, for an hour and with a reason, instead of permanently. For machines: workload identities and short-lived credentials instead of shared accounts. Keep an emergency break-glass account, locked away and alarmed. Review access each quarter with the managers who own it.

A weak answer: "Everyone in engineering gets admin so they are not blocked." Follow-up: "Developers say just-in-time access slows them down." Measure the wait, make the request one click with automatic approval for low-risk roles, and keep the human check for production data.

A developer pushed an API key to a public repository. What do you do?

What they check: calm, ordered action, and a fix for the cause, not just the key.

Short answer: "Revoke the key at once, because deleting the commit does not help: public repositories are copied by bots within minutes. Issue a new key from a secrets manager, check the provider's logs for any use of the old key, and then make it hard to happen again with secret scanning before code is pushed."

The full answer: Secrets management means keys, passwords and certificates live in a vault, are handed to applications at run time, and rotate on a schedule. In this case: revoke first, then rotate, then investigate what the key could reach and whether anyone used it. Clean the history if you like, but treat the key as burned. Afterwards, add scanning in the developer's editor and in the pipeline, move the application to fetch its key from the vault, and talk to the developer without blame, so the next person reports quickly.

A weak answer: "Delete the file and force-push." The key is already out. Follow-up: "The provider shows calls from an unknown address an hour ago." Now it is an incident: limit what the attacker can reach, collect the evidence, and follow the incident process.

Cloud and container security

How would you secure a company's cloud accounts from the start?

What they check: cloud security as guardrails at scale, not settings fixed one by one.

Short answer: "I set up an organisation with separate accounts or subscriptions for production, testing and security tooling, sign-in only through the company's identity provider, guardrail policies that block the dangerous settings, logs from every account sent to one place nobody can delete, and a tool that flags drift. Infrastructure is written as code so every change is reviewed."

The full answer: Most cloud breaches come from settings, not clever attacks: a storage bucket open to the internet, a key with too much power, a forgotten test server. Guardrails stop the worst at the organisation level, for example no public storage and no resources outside approved regions. Logging covers who did what, and goes to a separate security account. Cloud security posture management tools compare the live setup with the rules every day. With TerraformAsked in 8% of security engineer ads (as of 5 Nov 2026).Infrastructure written as code, so security settings are reviewed and repeated, not clicked by hand. or similar, the security team reviews settings in a pull request instead of finding them later.

A weak answer: "I would check the console every week." Follow-up: "A team needs a public bucket for a website." Allow an exception through a reviewed policy for that one bucket, with only public files in it, and put a content delivery network in front.

How do you secure containers and Kubernetes?

What they check: that you know where container platforms break, from the image to the cluster.

Short answer: "Small, scanned images from a trusted registry; containers that do not run as root and cannot gain more rights; network policies so pods talk only to what they need; secrets from a vault, not baked into images; and admission rules in KubernetesAsked in 9% of security engineer ads (as of 5 Nov 2026).Pod security, network policies, secrets and admission rules for container platforms. that refuse anything that breaks those rules."

The full answer: Start at the build: a minimal base image, a scan for known flaws, and a signature so the cluster runs only what your pipeline built. At run time, drop privileges, make the file system read-only where possible, and set resource limits. In the cluster, keep the control plane private, use role-based access for people and service accounts, and separate teams by namespace. Watch for odd behaviour, such as a shell started inside a container, with a run-time detection tool feeding the SIEM.

A weak answer: "Containers are isolated, so they are safe." They share the host's kernel. Follow-up: "A scan shows two hundred known flaws in one image." Most come from the base image; switch to a smaller one, then fix what is reachable and exploitable first.

Detection and incident response

It is Monday morning and several servers show encrypted files. Walk me through the first hours.

What they check: incident response under pressure: order, evidence and communication.

Short answer: "I start the incident process and call in the right people, then contain: isolate the affected machines from the network without switching them off, and protect the backups. Then I work out the scope from the logs, keep evidence, and keep leadership, legal and communications informed, because some breaches must be reported within days or hours."

The full answer, in the phases most teams use:

1. Prepare. This happens before the day: a written plan, contacts, offline backups that were tested, and the authority to cut systems off.
2. Detect and assess. Confirm it is real, name an incident lead, and find the first affected machine and the account used. Ransomware groups often steal data before they encrypt it.
3. Contain. Isolate machines, disable the compromised accounts, block the attacker's addresses and tools, and cut the backup systems off so they cannot be encrypted too.
4. Eradicate and recover. Remove the way in, rebuild from clean images, restore data from backups checked to be clean, and watch closely for the attacker's return.
5. Learn. A review without blame: what let them in, what slowed the response, and the fixes, each with an owner.

A weak answer: "Restore from backup straight away." Without finding the way in, the attacker comes back. Follow-up: "Who decides whether to report it?" Legal and leadership decide, with the facts from you; under the GDPR (EU) a personal data breach must usually be reported to the authority within 72 hours.

How do you build SIEM detections that people actually act on?

What they check: detection engineering: signal over noise, and rules tied to real attacks.

Short answer: "I start from the attacks that matter to us, often mapped with MITRE ATT&CK, a public catalogue of attacker techniques, and check we collect the logs to see them in the SIEMAsked in 20% of security engineer ads (as of 5 Nov 2026).Collect logs in one place, write detection rules people trust, and tune away the noise; Splunk is a common SIEM.. Each rule gets a test, a clear description of what to do when it fires, and a review of its false alarms after a few weeks. A rule nobody acts on is switched off or fixed."

The full answer: Alert fatigue is the enemy: analysts who see hundreds of false alarms stop reading them. Write detections for behaviour, such as a new admin created at night followed by logging switched off, rather than for one known bad file. Add context to every alert: who the user is, what the machine does, what happened just before. Keep the rules in version control, test them by replaying the technique in a lab, and track how many alerts turn out real.

A weak answer: "I switch on all the vendor's default rules." Follow-up: "Your rule fires fifty times a day, always on the backup service." Find out why the backup account behaves that way, then narrow the rule for it, document the exception, and keep watching that account another way.

An alert shows the finance director signing in from two countries an hour apart. What do you do?

What they check: practical triage of an identity alert, the most common real case.

Short answer: "I check whether it can be innocent, such as a VPN or a travel booking, by looking at the devices, the network and what the sessions did. If one session looks foreign, I end all sessions, reset the password, check the MFA methods for one an attacker added, and look for mailbox rules that forward or hide email."

The full answer: Impossible travel alerts are often false, so look at evidence: is the device known, does the address belong to the company's VPN, did MFA succeed, and what was touched. Real takeovers often start with a phishing page that steals the session, so MFA alone did not stop it. Look for forwarding rules, new app consents and payment changes, because finance accounts are a favourite for invoice fraud. Contact the director by phone, not by email.

A weak answer: "I would email the user and ask." If the mailbox is taken, the attacker answers. Follow-up: "How would you stop it next time?" Phishing-resistant MFA, sign-in only from managed devices for sensitive roles, and an alert on new forwarding rules.

Vulnerabilities, secure development and zero trust

How do you run vulnerability management so the important fixes actually happen?

What they check: priorities based on real risk, and fixes that land, not longer reports.

Short answer: "I start with a list of what we own, because you cannot fix what you do not know about. Then I rank findings by real risk: is it exploited in the wild, can an attacker reach it, and how valuable is the system. Fix deadlines follow that rank, owners are the teams that run the systems, and I report what is overdue, not how many findings exist."

The full answer: Scanners produce thousands of findings; a severity score alone sends teams after the wrong ones. Add context: public lists of flaws known to be exploited, the likelihood of exploitation, whether the system faces the internet, and what data it holds. Automate the routine, such as patching operating systems on a schedule, so people work only on the hard cases. When a team cannot fix in time, record an exception with an end date and a temporary control.

A weak answer: "I send every team the full scan report each month." Follow-up: "A critical flaw is in a system the business says cannot be restarted this quarter." Reduce the exposure now, such as blocking the port or adding a filter in front, record the accepted risk with its owner, and plan the patch.

How do you build security into the way software is developed?

What they check: a secure SDLC that developers accept, not a gate at the end.

Short answer: "A secure SDLC, or secure software development life cycle, puts security into each stage: threat models at design, safe defaults in shared libraries, automatic checks in the build pipelineAsked in 26% of security engineer ads (as of 5 Nov 2026).Security checks run in the build pipeline, so a risky change is caught before it ships. for code flaws, secrets and outdated dependencies, review of risky changes, and tests before release. The fastest way to adoption is to make the secure way the easy way."

The full answer: Shift security earlier, but carefully: a pipeline that blocks on every low-risk finding gets switched off. Block only on high-confidence, high-risk results and report the rest. Give teams paved roads, such as a login library and a service template that are secure by default. Train security champions, developers in each team who know the basics and know when to call you. Measure time to fix and repeat findings, not the number of scans.

A weak answer: "We do a penetration test before each major release." That finds problems when they are most expensive to fix. Follow-up: "Developers ignore the scanner results." Cut the noise first, put the results where they already work, in the pull request, and fix a few with them.

What does zero trust mean in practice?

What they check: that you can turn a buzzword into concrete controls.

Short answer: "Zero trust means no request is trusted because of where it comes from, inside the office network or not. Each access is checked against who the user is, the state of their device and what they want to reach, every time. In practice: strong identity with MFA, device checks, access per application instead of a VPN into everything, and segmentation so one breach does not open the whole network."

The full answer: The old model was a castle: hard outside, soft inside. Attackers who got in through one laptop could reach everything. Zero trust moves the check to each application and each request. You get there in steps: inventory users, devices and applications; put the most sensitive applications behind an identity-aware proxy; require managed, patched devices for them; then split the network so servers talk only to what they need. Log every decision for the detection team.

A weak answer: "We bought a zero trust product." It is an approach, not a box. Follow-up: "Where would you start in a company of five hundred people?" With identity: single sign-on and phishing-resistant MFA for every application, then the admin accounts.

A product team wants to ship a feature you think is risky. How do you handle it?

What they check: judgement and communicationAsked in 29% of security engineer ads (as of 5 Nov 2026).Explain a risk to people who are not in security, in their terms, without fear or jargon.: security that helps the business decide, rather than only saying no.

Short answer: "I explain the risk in business terms: what could happen, how likely it is, and what it would cost. Then I offer options: a fix before launch, a smaller launch with a control, or shipping with the risk accepted in writing by the person who owns it. My job is to make the decision informed, not to make it for them."

The full answer: Most disputes end when the risk is concrete: "anyone with a link could read other customers' contracts" lands better than "this has an access control weakness". Bring a fix that costs the team as little as possible. If the owner still accepts the risk, record it with an end date and escalate only when the harm would be severe, such as a legal breach.

A weak answer: "I block the release." Follow-up: "The manager accepts the risk and it goes wrong." Handle the incident first, then use the review to improve how risks are decided, not to say I told you so.

Senior, lead, staff, security architect, head of security and CISO

These questions come up for senior, lead and staff security engineer, security architect, head of security and CISO roles.

As a lead or staff security engineer, how do you set security direction for several teams?

What they check: influence beyond your own tickets: standards, reviews and people.

Short answer: "I pick the few risks that matter most across the company, agree a target for each with the engineering leads, and turn them into paved roads and standards the teams can use. I review the designs with the highest risk myself and coach other engineers to review the rest. Progress is measured, and shown to the teams and their managers."

The full answer: A lead or staff engineer multiplies: one person cannot review every change, so they build what makes changes safe by default, write the short guidance teams follow, and grow security champions. They also say no to work that does not move the top risks. On the way to security architect, the scope becomes the whole system: how identity, data, networks and monitoring fit together, written as reference designs.

A weak answer: "I review every pull request with security impact." That does not scale. Follow-up: "Two teams want opposite standards." Write down the risk each choice leaves, pick the one that fits most teams, and allow a documented exception.

As head of security or CISO, how do you build a security programme and report it to the board?

What they check: at the top of the ladder, turning risk into priorities, budget and trust.

Short answer: "I start from the business: what would hurt it most, which rules apply, and what customers ask for. I set a short list of goals for the next year or two, often built around a framework such as ISO 27001Asked in 30% of security engineer ads (as of 5 Nov 2026).The international standard for an information security management system: risks, controls, audits. or NIST, staff and fund them, and report to the board in risk terms: what is better, what is still exposed, and what I need them to decide."

The full answer: A programme has people, processes and tools, but the first two decide the result. Map the duties that apply, such as NIS2 in the EU or customer audits, and meet them with one set of controls instead of one project per rule. Boards want few numbers: how fast serious incidents are found and contained, how much critical exposure is overdue, and progress on the top risks. Run an incident exercise with leadership once a year, so the first real one is not the first rehearsal.

A weak answer: "I would buy the best tools on the market." Follow-up: "The board asks whether we are secure." No company is fully secure; say which risks are under control, which are not, and what it would take to reduce them.

Your CV for these questions

A security interview pulls on every claim in your CV, so write the lines that set up the answers above. Put each one under the job where you did the work:

Then run a score against a real security engineer job: it marks the lines this employer looks for and the claims your CV has not backed up yet.