This page is for anyone facing a security round, whether it's a first analyst job or a move into a senior security or security-minded engineering role. Most interviews open with the CIA triad and threat, vulnerability and risk, then test common attacks like phishing, SQL injection, XSS and CSRF, move to encryption, hashing and TLS, and finish with access control, testing and incident response. Senior rounds add a real incident story and a judgement call under pressure. Each question shows what the interviewer is checking, the shape of a strong answer and a short answer to say out loud. Practise them, then swap in your own stories.
Search all questions by round, difficulty and level, or save the ones you want to practise.
Confidentiality: only the right people can read the data; broken by a leaked database or a misconfigured storage bucket.
Integrity: data is not changed without permission; broken when someone edits a payment record or a log.
Availability: people can use the system when they need it; broken by a DDoS or ransomware.
Controls: encryption and access control, hashes and signatures, backups and redundancy.
"The CIA triad is confidentiality, integrity and availability, the three things security tries to protect. Confidentiality means only authorised people can see the data. A customer database dumped online is a confidentiality failure, and access control plus encryption are the usual defences. Integrity means the data hasn't been changed without permission. If an attacker quietly edits a bank account number on an invoice, that's integrity, and you protect it with access control, hashes, digital signatures and audit logs. Availability means the system works when people need it. A DDoS that takes a site down is the classic example, and redundancy, backups and capacity planning help there. Ransomware is interesting because it hits availability first, and these days often confidentiality too, because attackers steal data before they encrypt it."
Listing the three words with textbook definitions but no example or control for any of them.
Threat: someone or something that could cause harm, like a criminal group or a flood.
Vulnerability: a weakness the threat could use, like an unpatched server.
Risk: how likely the threat exploits the weakness, times how bad the impact would be.
Treatment: reduce it, transfer it, avoid it or accept it.
"Take a company web server that's missing a critical patch. The threat is whoever might attack it, say criminals scanning the internet for that exact flaw. The vulnerability is the missing patch itself, the weakness. The risk is the combination: how likely it is that someone exploits it, and how bad it would be if they did. If that server is internet-facing and holds customer data, the risk is high. If it's an isolated test box with nothing on it, the same vulnerability is a much lower risk. That's why I don't treat every finding the same. Once you understand the risk you can reduce it by patching, transfer some of it with insurance, avoid it by shutting the service down, or formally accept it if the cost of fixing is higher than the harm."
Using the three words as synonyms, or saying risk is just the severity score of a vulnerability.
Purpose: a shared structure for deciding what to protect and checking that you've covered the basics.
NIST CSF: voluntary guidance organised into functions: Govern, Identify, Protect, Detect, Respond, Recover.
ISO 27001: a standard for an information security management system that an outside auditor can certify.
In practice: pick one as the backbone and map customer or legal requirements onto it.
"Frameworks give a company a common structure, so security isn't just a list of tools someone bought. The NIST Cybersecurity Framework is voluntary guidance. The current version groups outcomes into six functions: Govern, Identify, Protect, Detect, Respond and Recover. It's good for asking where you're strong and where you have gaps. ISO 27001 is different: it's a standard for running an information security management system, with risk assessment, policies, controls and regular review, and an outside auditor can certify you against it. Customers often ask for that certificate. Then there are more targeted ones, like the CIS Controls for a prioritised technical checklist, or PCI DSS if you handle card data. In my experience you pick one as the backbone and map the others onto it, so one control can satisfy several requirements."
Claiming a certificate proves a company can't be breached, or naming frameworks without knowing what any of them is for.
Signs: urgency, a sender domain that's slightly off, links that don't match the text, unexpected attachments, requests for passwords or payment changes.
Before the inbox: SPF, DKIM and DMARC, filtering, link and attachment scanning.
After a click: phishing-resistant MFA, least privilege, endpoint protection.
People: an easy report button and a blame-free culture so reports come fast.
"The usual signs are pressure and mismatch. There's urgency, like your account closes today, a sender address that looks almost right, a link where the visible text says one domain but hovering shows another, an attachment you didn't expect, or a request to log in or change bank details. But I assume someone will click eventually, so I think in layers. Before the inbox, SPF, DKIM and DMARC make it harder to spoof our own domain, and filtering catches known bad links and files. After a click, phishing-resistant MFA means a stolen password alone isn't enough, least privilege limits what that account can reach, and endpoint protection can stop a malicious file. And I want a one-click report button and a culture where reporting fast is praised, because the first report often lets us pull the same email from every other inbox."
Saying training alone solves phishing, or blaming the user who clicked as the whole answer.
Idea: many machines, often a botnet, overwhelm a target so real users can't get through.
Volumetric: fills the network pipe, often using reflection and amplification; stopped upstream by a scrubbing service or CDN.
Protocol: like a SYN flood, exhausts connection tables; SYN cookies and network gear help.
Application layer: realistic-looking requests to expensive pages; rate limits, WAF rules, caching, bot checks.
"A DDoS is a distributed denial of service: lots of machines, usually a botnet, send traffic at once so real users can't get in. It hits availability. The types matter because they exhaust different things. Volumetric attacks try to fill your internet link, often by reflection, where attackers send small spoofed requests to open servers that reply with much bigger answers aimed at you. You can't fix that on your own server; you need upstream capacity like a scrubbing service or a CDN. Protocol attacks like SYN floods exhaust connection state, and things like SYN cookies help there. Application-layer attacks are the sneaky ones: fewer requests, but they look real and hit expensive pages like search or login. For those I use rate limiting, WAF rules, caching and bot challenges, and I make sure we have a runbook agreed with our provider before we need it."
Saying a firewall on the server or simply adding more servers will stop any DDoS.
Entry: phishing, stolen or reused passwords, exposed remote access, unpatched edge devices.
Spread: privilege escalation, lateral movement, going after backups, often stealing data first.
Impact: mass encryption and a ransom note, often with a threat to leak the stolen data.
Recovery: offline or immutable backups that are tested, segmentation, MFA, a practised response plan.
"Ransomware is rarely a single click that encrypts everything. Usually the attacker gets in first through a phishing email, a reused password on remote access, or an unpatched VPN or firewall. Then they spend time inside: they escalate to admin, move sideways to other machines, find the backups and try to delete them, and more and more often copy data out so they can threaten to leak it. Only at the end do they run the encryption across as many machines as possible at once. That's good news for defenders, because every step is a chance to detect them. What decides recovery is backups the attacker couldn't touch: offline or immutable copies, and restores you've actually practised, because an untested backup is a hope, not a plan. Segmentation, MFA on remote access and admin accounts, and fast patching of internet-facing devices shrink the blast radius."
Describing ransomware as instant and unstoppable, or saying backups on a network share solve it.
Cause: user input is glued into the SQL string, so it can change the query's logic.
Example: the quote closes the string and OR '1'='1' makes the condition always true.
Fix: parameterised queries, so input is always treated as data.
Extra layers: least-privilege database accounts, allow-lists for things you can't parameterise, a WAF as backup only.
"SQL injection happens when an app builds a query by pasting user input into the SQL text. If the code does WHERE name = quote, plus whatever the user typed, plus quote, and I type a quote followed by OR '1'='1, my quote closes the string early and the query becomes name equals empty OR one equals one. That's always true, so the check passes or the query returns every row. The real fix is parameterised queries. The SQL text is fixed, the values are sent separately, and the database never treats them as code, whatever characters they contain. Escaping and blocking words are fragile and easy to bypass. I'd also give the app's database user only the rights it needs, so a mistake can't drop tables, and for things you can't parameterise, like a column name for sorting, I'd check against a fixed list."
import sqlite3
db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE users (id INTEGER, email TEXT)")
db.executemany("INSERT INTO users VALUES (?, ?)", [(1, "a@example.com"), (2, "b@example.com")])
email = "' OR '1'='1"
# Unsafe: input becomes part of the SQL text
unsafe = "SELECT id FROM users WHERE email = '" + email + "'"
print(db.execute(unsafe).fetchall()) # [(1,), (2,)] every row
# Safe: the value is sent separately as a parameter
print(db.execute("SELECT id FROM users WHERE email = ?", (email,)).fetchall()) # []Saying the fix is to strip quotes or block words like SELECT, rather than using parameterised queries.
Stored: the payload is saved, like in a comment, and runs for everyone who views it.
Reflected: the payload comes in the request, like a search term, and is echoed straight back.
DOM-based: client-side script takes data from the URL or page and writes it unsafely into the page.
Defence: context-aware output encoding and safe DOM APIs first; CSP and HttpOnly cookies limit the damage.
"XSS is when an attacker gets their script to run in someone else's browser on your site, so it can act as that user or steal what's on the page. Stored XSS is when the payload is saved, say in a comment or profile name, and runs for everyone who views it, which makes it the most dangerous. Reflected XSS is when it comes in with the request, like a search term the page echoes back, so the attacker has to get the victim to click a crafted link. DOM-based XSS never touches the server's HTML: the page's own JavaScript reads something from the URL and writes it into the page with something like innerHTML. The main defence is encoding output for the context it lands in, and using frameworks that escape by default and safe APIs like textContent. A Content Security Policy is a second layer: it can block inline scripts and unknown sources, so a bug that slips through is much harder to exploit."
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'Saying input validation alone or a CSP alone fixes XSS, or not knowing the DOM-based type exists.
Attack: a page on another site makes the victim's browser send a request to your site.
Why it works: the browser attaches the victim's session cookie automatically, so the request looks legitimate.
Tokens: a secret value in the form that the attacker's page can't read or guess.
SameSite and more: SameSite cookies, checking the Origin header, and never changing state on GET.
"CSRF, cross-site request forgery, is when a malicious page makes your browser send a request to a site you're logged into. Say I'm signed into my bank, and I visit a page that silently submits a form to the bank's transfer endpoint. My browser attaches my session cookie automatically, so the bank sees a normal, authenticated request. The attacker can't read the response, but they don't need to; the action already happened. The classic fix is a CSRF token: the server puts a random secret in each form or session, and the attacker's page can't read it, so it can't include it. SameSite cookies help too. With Lax or Strict, the browser won't send the cookie on cross-site POST requests. I'd also check the Origin header and make sure GET requests never change anything, because GET links are the easiest thing to forge."
Confusing CSRF with XSS, or thinking HTTPS or a login requirement prevents CSRF.
What it is: an awareness document from the OWASP community listing the most critical web app risk categories, refreshed every few years.
Examples: broken access control, injection, cryptographic failures, security misconfiguration, vulnerable components, authentication failures.
Use: training, code review checklists, test cases and threat modelling prompts.
Limit: a starting point, not a full standard; ASVS goes deeper.
"OWASP is an open community that publishes free security guidance, and the Top 10 is its awareness list of the most critical risk categories for web apps. It's refreshed every few years based on real data and community input. Categories I'd expect to see include broken access control, which has been at the top of recent editions, injection, cryptographic failures, security misconfiguration, using components with known vulnerabilities, and authentication failures. On a team I'd use it as shared vocabulary: a short training session, a checklist in code review, test cases for each category that applies, and a prompt when we threat-model a new feature. But I'd be clear it's a floor, not a ceiling. It's a list of categories, not a test plan, and if we need something we can verify against, the OWASP ASVS is the more detailed standard."
Treating the Top 10 as a complete security standard, or being unable to name a single category.
Name: insecure direct object reference, a form of broken access control.
Root cause: the server checks you're logged in but not that this object is yours.
Fix: on every request, check ownership or permission for that specific object, on the server.
Not a fix alone: random IDs; they make guessing harder but leave the missing check in place.
"That's an insecure direct object reference, which is a kind of broken access control. The app checked that the user is logged in, but never checked that order 1042 belongs to them. The fix is on the server: every time the endpoint loads an object, it checks that the current user is allowed to see that specific object. Often the simplest way is to build it into the query, so I look up the order by its ID and the user's ID together, and if nothing comes back I return not found. I'd put that check in one shared place so new endpoints can't forget it, and add tests that log in as user A and try to fetch user B's data. Switching to random IDs makes guessing harder, and it's fine as an extra layer, but on its own it just hides the bug. IDs leak through links, logs and shared screenshots."
Saying the fix is to encrypt or randomise the IDs, or to hide the link in the interface.
Symmetric: one shared key encrypts and decrypts; fast; AES is the common choice.
Asymmetric: a public key and a private key; slower; RSA and elliptic-curve schemes.
Problem: symmetric needs a safe way to share the key; asymmetric solves that.
Together: asymmetric methods agree or protect a key, then symmetric encryption carries the data.
"Symmetric encryption uses one key for both locking and unlocking. AES is the usual example. It's fast, so it's what you use for large amounts of data, like disk encryption or the traffic in a TLS session. The catch is that both sides need the same key, and sending it safely is the hard part. Asymmetric encryption uses a pair: a public key anyone can have and a private key only the owner keeps. RSA and elliptic-curve schemes are examples. It solves the sharing problem and also gives you digital signatures, but it's much slower and not meant for bulk data. So real systems combine them. In TLS, for example, asymmetric cryptography is used to authenticate the server and agree on a fresh session key, and then all the actual data is encrypted with a fast symmetric cipher using that key."
Saying asymmetric is simply more secure so it should be used for everything.
Encoding: changes format for transport, like Base64; anyone can reverse it; no secret, no security.
Encryption: reversible only with the right key; protects confidentiality.
Hashing: one-way, fixed-length fingerprint; checks integrity and stores passwords.
Mistakes: Base64 treated as protection, or encrypted passwords that could be decrypted.
"Encoding is only about format. Base64, for example, turns binary data into text so it can travel safely in an email or a URL. Anyone can decode it, there's no key, so it gives no security at all. Encryption is reversible, but only with the right key, so it's for keeping data secret: files on a laptop, traffic on the network, a column of card numbers you'll need to read later. Hashing is one-way. It turns any input into a fixed-length fingerprint, like with SHA-256, and a good hash makes it infeasible to find the input or another input with the same output. I use hashing to check a file hasn't been changed and, with special slow algorithms, to store passwords. The classic mistake I watch for is someone calling Base64 encryption, or storing passwords encrypted instead of hashed."
Calling Base64 encryption, or saying a hash can be decrypted with the right key.
Problem: SHA-256 is built to be fast, so stolen hashes can be guessed at huge rates on GPUs.
Salt: a unique random value per user, stored with the hash; kills precomputed tables and hides reused passwords.
Slow hash: Argon2id, scrypt or bcrypt, with a work factor you can raise over time.
Extras: a pepper kept outside the database, and upgrading old hashes when users next log in.
"SHA-256 is a fine hash, but it's designed to be fast, and for passwords speed helps the attacker. If our database leaks, they can try billions of guesses on GPUs against each hash. Without a salt it's even worse: the same password always gives the same hash, so they can use precomputed rainbow tables and instantly see which users share a password. A salt is a random value, unique per user, stored right next to the hash and mixed in before hashing. It isn't secret; its job is to make every hash different, so precomputed tables are useless and each password has to be attacked on its own. Then I'd use a password hashing function that's slow on purpose, like Argon2id, scrypt or bcrypt, with a work factor I can raise as hardware gets faster. Some teams add a pepper too, a secret kept outside the database."
Saying the salt must be secret, reusing one salt for every user, or suggesting encryption for passwords.
Certificate: binds a domain name to a public key, signed by a certificate authority the browser trusts.
Proof: in the handshake the server proves it holds the matching private key.
MITM: an attacker can't show a trusted certificate for your domain, so the browser warns.
Gaps: users clicking through warnings, downgrade to plain HTTP (fixed by HSTS), a rogue trusted CA.
"A certificate says this public key belongs to this domain name, and a certificate authority the browser already trusts has signed that statement. On its own a certificate is public, anyone can copy it. What matters is that during the handshake the server proves it has the matching private key. Now picture an attacker on café Wi-Fi sitting between me and my bank. They can intercept my connection, but they can't produce a valid certificate for the bank's domain signed by an authority my browser trusts, and they don't have the bank's private key. So the browser shows a warning instead of connecting quietly. The attack still works in a few cases: if the user clicks through the warning, if the site can be reached over plain HTTP first so the attacker strips out TLS, which HSTS prevents, or if a device has been made to trust the attacker's own root certificate."
Saying the certificate itself encrypts the traffic, or that a padlock means the website is trustworthy.
Old RSA exchange: the client encrypted the session secret with the server's long-term public key.
The risk: steal that private key later and every recorded session can be decrypted.
Forward secrecy: each session uses a fresh ephemeral Diffie-Hellman key; the long-term key only signs.
Result: a stolen server key doesn't unlock past traffic.
"Forward secrecy means that if a server's long-term private key is stolen later, past sessions still can't be decrypted. With the old RSA key exchange, the browser picked a secret and encrypted it with the server's long-term public key. That's fine until the private key leaks. Then anyone who had been recording the traffic, for months or years, can decrypt the key exchange of every session and read all of it. With ephemeral Diffie-Hellman, usually the elliptic-curve version, each side generates a fresh temporary key pair for that one connection, they derive the session key together, and then throw the temporary keys away. The server's long-term key is only used to sign the exchange, to prove who it is. So stealing it lets you impersonate the server going forward, but not read what you recorded before. TLS 1.3 made that the rule by dropping static RSA key exchange."
Confusing forward secrecy with longer keys, or thinking it protects against a stolen key being used for future impersonation.
Stateless: judges each packet alone by addresses, ports and protocol.
Stateful: tracks connections, so reply traffic is allowed automatically and stray packets are dropped.
Next-generation: adds application awareness, user identity and often intrusion prevention.
WAF: sits in front of web apps and inspects HTTP requests for things like injection and XSS patterns.
"A stateless packet filter looks at each packet on its own: source and destination address, port and protocol, checked against rules. It's fast but dumb, because it doesn't know whether a packet belongs to a connection someone inside actually started. A stateful firewall tracks connections, so if a laptop inside opens a connection out, the replies are allowed back automatically, and random packets pretending to be replies are dropped. A next-generation firewall goes further: it can recognise applications regardless of port, tie traffic to users, and often has intrusion prevention built in. A web application firewall is different in where it sits. It's in front of web apps and reads the actual HTTP requests, so it can block things like SQL injection or XSS patterns that a network firewall can't see. Whatever the type, I start from default deny and only open what's needed."
Saying a network firewall stops SQL injection, or that any firewall makes an app secure on its own.
IDS: watches a copy of traffic and raises alerts; can't stop anything by itself.
IPS: sits inline and can drop or block traffic in real time.
Detection: signatures for known attacks, anomaly or behaviour rules for unusual activity.
Trade-off: an IPS false positive blocks real users, so rules are tuned in detect-only mode first.
"An intrusion detection system watches traffic, usually a copy from a mirrored port or tap, and raises alerts when something looks like an attack. It can't stop anything; a person or another system has to act. An intrusion prevention system sits inline, right in the path of the traffic, so it can drop or block a bad connection in real time. Both detect in similar ways: signatures that match known attack patterns, and anomaly rules that flag behaviour that's unusual for that network. You also get host-based versions that run on a server instead of the network. The catch with an IPS is that a false positive doesn't just create an alert, it blocks a real customer or a business process. So a sensible team runs a new rule in detect-only mode first, checks what it would have blocked, tunes it, and only then switches it to block."
Saying an IDS blocks attacks, or ignoring the business cost of false positives in blocking mode.
Old model: a strong perimeter, and anything inside the network is trusted.
Zero trust: network location earns no trust; every request is checked on identity, device and context.
In practice: strong authentication everywhere, least privilege, segmentation, device health checks, logging every access.
Reality: a gradual journey, starting with the most sensitive apps, not a product you buy.
"The old castle-and-moat model puts a strong wall around the network and trusts whatever is inside. The problem is that once an attacker gets in, through a phished laptop or a VPN account, they can move around freely. Zero trust says being on the network earns you nothing. Every request to a resource is checked on who you are, the state of your device and the context, like location or time, and you only get access to that one app, not the whole network. In practice that means strong MFA everywhere, least-privilege access per application, segmenting the network so a compromised machine can't reach everything, checking device health before granting access, and logging every decision. I'd be honest that you don't buy zero trust in a box. It's a direction you move in, usually starting with remote access and the most sensitive systems."
Describing zero trust as a single product, or as trusting nobody so nothing works.
Authentication: proving who you are, with a password, a key, a token or MFA.
Authorization: deciding what that identity is allowed to do.
Order: authentication comes first; authorization is checked on every action.
HTTP: 401 means not authenticated; 403 means authenticated but not allowed.
"Authentication is about who you are. When I log in with a password and a code from my phone, the system is authenticating me. Authorization is about what I'm allowed to do once it knows who I am. I might be able to read reports but not delete users. Authentication usually happens once per session, but authorization has to be checked on every single action, and a lot of real bugs come from teams checking the first and forgetting the second. In HTTP, a 401 means the server doesn't know who you are, so log in or send valid credentials. The name Unauthorized is a bit misleading there. A 403 Forbidden means the server knows who you are, and the answer is still no. Some apps return 404 instead of 403 so they don't even confirm the thing exists."
Using the two words interchangeably, or saying authorization only needs to be checked at login.
Factors: something you know, something you have, something you are.
SMS: weakest; SIM swaps, interception and phishing proxies.
Apps and push: better, but codes can be phished live and push can be spammed until someone taps approve.
Security keys and passkeys: strongest; FIDO2 ties the login to the real site, so a fake site gets nothing.
"MFA means combining two different kinds of factor, like something you know with something you have, and any MFA beats a password alone. But they're not equal. SMS codes are the weakest: attackers can do a SIM swap to take over the number, and a fake login page can simply ask for the code and replay it straight away. Authenticator app codes avoid SIM swaps, but they can still be phished in real time the same way. Push approvals are convenient, but attackers spam them until a tired user taps approve, which is why number matching was added. The strongest are FIDO2 security keys and passkeys. The browser ties the cryptographic response to the real website's address, so a look-alike site gets nothing useful, even if the user is fooled. For admins and anyone with access to sensitive data, that's what I'd push for."
Treating all MFA as equally strong, or calling a password plus a security question two-factor.
Principle: each person or process gets only the access its job needs, for as long as it needs it.
People: role-based groups, separate admin accounts, just-in-time elevation with approval.
Services: one identity per service, scoped permissions, short-lived credentials, no shared keys.
Upkeep: regular access reviews, removing unused rights, joiner-mover-leaver process.
"Least privilege means every person and every process gets only the access it needs to do its job, and ideally only for as long as it needs it. For people, I give access through role-based groups rather than one-off grants, keep admin rights on separate accounts, and where possible use just-in-time elevation, so someone requests admin for an hour with a reason and it expires. For services, each one gets its own identity with only the permissions it uses. If a reporting job only reads one table, it shouldn't be able to write anything. I prefer short-lived credentials over long-lived keys. The hard part is creep. People change teams and keep old access. So I'd set up regular access reviews where managers confirm each grant, use logs to find permissions nobody has used in months and remove them, and make sure leaving the company removes everything the same day."
Defining the principle but having no answer for permission creep, or giving services shared admin credentials.
Context: the control, why it mattered, and who pushed back.
Listening: what their real objection was.
Design: changes that made it easier without weakening it.
Outcome: adoption, and what you learned about rolling out controls.
"At my last company we rolled out MFA for everyone, and the sales team pushed back hard. They were on the road, switching devices, and they'd heard it would lock them out before a client call. Instead of just setting a deadline, I sat with two of them and listened. The real fear was being locked out with no quick way back in. So we changed the rollout. We ran short setup sessions where we set it up together on their phones, we offered authenticator apps and a few hardware keys instead of SMS, and we set up a fast recovery process with the help desk that still verified identity properly. We started with a pilot group who then told their colleagues it was painless. We reached full adoption about a month later with very few tickets. What I learned is that most resistance is about fear of getting stuck, not about security itself."
A story where the candidate simply forced the change and treated the users as the problem.
Assessment: broad, mostly automated scanning that lists known weaknesses and rates them.
Pentest: a skilled tester tries to exploit and chain weaknesses to prove real impact.
Rules: a pentest has a written scope, rules of engagement and signed permission.
When: assessments continuously; pentests before a big launch, after major change, or when required.
"A vulnerability assessment is about breadth. You scan your systems, mostly with automated tools, and get a list of known weaknesses, like missing patches or weak settings, each with a severity. It doesn't try to break in, so some findings will be false positives and it won't show how issues combine. A penetration test is about depth. A skilled tester actually tries to exploit weaknesses and chain them, say a small information leak plus a weak password leading to admin access, to show what an attacker could really do. Because it's an active attack, it needs a written scope, rules of engagement and signed permission from the system owner. In practice I'd run vulnerability scanning continuously, because new flaws appear every week, and bring in a pentest before a major launch, after big architecture changes, or when a customer or regulation requires one."
Saying a pentest is just running a scanner, or that anyone can test a system without written permission.
Understand: how exploitable it is, who can reach it and what data or actions it exposes.
Options: a quick fix, a compensating control, launching without the affected feature, or a short delay.
Decide: the business owner accepts the risk formally, in writing, with an expiry date.
Follow through: a tracked fix date and extra monitoring until it's closed.
"First I'd make sure I understand the finding properly: can it be exploited from the internet without logging in, what data or actions does it expose, and how hard is it to pull off? Severity labels don't always match real risk. Then I'd go to the product manager with options, not just a no. Maybe the developers can fix it in a day. Maybe we can add a compensating control, like a WAF rule or turning off the affected feature with a flag. Maybe we launch without that one part. If none of those work and they still want to ship, I don't think it's my call alone to block the business. But the risk has to be accepted formally by someone with the authority to own it, in writing, with a clear description and an expiry date, and we add monitoring and a firm fix date. What I won't do is quietly sign it off."
Either blocking the launch with no alternatives, or silently approving it to avoid conflict.
Finding: what you noticed and how, in plain terms.
Impact: what an attacker could have done with it, without exaggerating.
Raising it: who you told, how you framed it, how you handled pushback.
Result: the fix and the change that stops it happening again.
"At my last company I was helping debug a login problem and noticed our application logs were writing full session tokens on every request. Anyone with log access, which included a support tool and a third-party log service, could have copied a token and taken over a live customer session. I checked a few days of logs to confirm it wasn't a one-off, then raised it with the team lead privately rather than in a big channel, with a short note: what was logged, who could see it, and a suggested fix. There was some pushback because the tokens helped with debugging, so I suggested logging a short hash of the token instead, which still let us match requests. The fix shipped that week, we purged the old logs, and I added a logging check to our code review list so sensitive fields get masked by default."
A story where the candidate found something and posted it publicly, or where the story ends at spotting the issue with no fix.
Preparation: a plan, roles, contact list, logging and tools ready before anything happens.
Detection and analysis: confirm it's real, work out scope and severity, start a timeline.
Containment, eradication, recovery: stop the spread, remove the cause, restore safely and watch.
Post-incident: a blameless review that turns lessons into tracked fixes.
"I usually think of it in the classic four-phase NIST lifecycle. First, preparation: a written plan, clear roles, an up-to-date contact list including legal and communications, logging that actually captures what you'll need, and practice runs. Then detection and analysis: confirm it's a real incident and not noise, work out what's affected and how serious it is, and start a timeline and evidence notes straight away. Then containment, eradication and recovery. Contain first, like isolating a machine or disabling an account, while being careful not to destroy evidence. Then remove the cause, patch the hole, rotate credentials, and restore from clean backups, watching closely for the attacker coming back. Finally, the post-incident review: blameless, focused on what let it happen and what would have caught it sooner, with every action given an owner and a date. That last step is where the real improvement comes from."
Jumping straight to wiping machines, or skipping preparation and the post-incident review.
Contain: reset the password, revoke active sessions and tokens, check MFA methods for anything newly added.
Investigate: sign-in logs, new mailbox rules or forwarding, emails sent, files accessed, password reuse elsewhere.
Protect others: block the phishing domain, find and remove the same email from other inboxes.
People: thank them, keep them involved, record everything, escalate if anything was accessed.
"First I'd thank them, because reporting in 20 minutes is exactly what we want, and I'd keep them on the call. Then I'd contain: reset the password, revoke all active sessions and tokens, because a reset alone doesn't always kill a session that's already logged in, and check whether any new MFA device or app was registered, since attackers add their own to keep access. Then I'd look at what happened: sign-in logs for unfamiliar locations, new mailbox rules that forward or hide mail, messages sent from the account, and files or systems accessed. I'd ask if they use that password anywhere else. In parallel I'd block the phishing domain and search for the same email in other inboxes, pulling it before anyone else falls for it. I'd write down every step with times, and if logs show the attacker got in, it becomes a full incident."
Only resetting the password, or making the colleague feel blamed so people stop reporting.
Revoke first: disable and rotate the key immediately; assume it's already been copied.
Check use: review the provider's logs for any activity with that key since it was pushed.
Clean up: remove it from history, update the apps that used it, move secrets to a manager.
Prevent: secret scanning before commit and in the pipeline, short-lived credentials.
"I'd assume it's already been found, because automated bots scan public repositories for keys constantly. So step one is to revoke it and issue a new one straight away, even if something breaks for a few minutes. Deleting the commit isn't enough; the key has been public for two days and could be in anyone's copy. Then I'd check the cloud provider's logs for every action taken with that key since it was pushed: new servers, new users, data read from storage. If anything looks unfamiliar, it becomes a full incident. Once it's contained, I'd update the apps that relied on the old key, remove it from the repository history, and talk to the developer without blame, because it's a process gap. Then I'd fix the gap: secrets in a proper secret manager, scanning before commits and in the pipeline, and short-lived credentials where possible."
Deleting the commit or making the repository private and treating that as the fix, without revoking the key.
Situation: what was detected, how, and how serious it was.
Your role: what you personally did, not what the team did.
Containment: the steps that stopped the harm, in order.
After: the review and the lasting changes.
"At my last company our monitoring flagged a big jump in failed logins on the customer site one evening. I was on call, so I started digging. The attempts came from thousands of IP addresses, each trying a few different email and password pairs, which looked like credential stuffing with passwords leaked from other sites. A small number of logins had succeeded. My part was the investigation and first containment: I added stricter rate limits and a challenge on the login page, and pulled the list of accounts that had logged in successfully from those sources. We forced resets on those accounts, ended their sessions and emailed the owners. In the review we agreed we'd been relying on passwords alone for customers, so we added a check against known breached passwords, better bot protection on login and optional MFA. The biggest lesson for me was how much faster the response goes when the login logs are already clean and searchable."
Using 'we' for everything so the candidate's own role is unclear, or a story with no lasting change afterwards.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your resume and notes are never stored on our servers. It stays out of screen share on every plan; only you can see it.