Security Engineer — interview prep kit

The round where they hand you a system and watch you think adversarially. Use a framework so you are systematic, and reason about what an attacker wants and how they would get it.

1. known

   Walk me through how you would threat-model a new web application.

   What it tests Whether you have a systematic, adversarial method rather than an ad-hoc list of worries.

   Model answer

   I would work systematically rather than listing scary things, using a structure like: understand the system, identify what is worth protecting, enumerate how it could be attacked, and decide on controls. Concretely: first understand the architecture — draw the data flow (a DFD): the components, how data moves between them, where the trust boundaries are (where data crosses from less-trusted to more-trusted, like the internet to your server, which is where attacks concentrate). Then identify the assets — what an attacker wants: user data (PII, credentials), money, availability, integrity of the data. Then enumerate threats at each component and boundary, and this is where a framework like STRIDE helps you be exhaustive: for each element ask about Spoofing (can someone impersonate a user or service?), Tampering (can data be modified in transit or at rest?), Repudiation (can actions be denied — is there logging?), Information disclosure (can secrets or data leak?), Denial of service (can it be taken down?), and Elevation of privilege (can a low-privilege user gain higher access?). For each real threat, rate it by likelihood and impact so you prioritize, then decide controls — mitigate, and for the ones you accept, do so consciously. The framing interviewers want: a repeatable method (system → assets → trust boundaries → threats via STRIDE → prioritize → controls) so nothing is missed, adversarial thinking (what does the attacker want and how do they get it, focusing on trust boundaries), and prioritization by risk rather than trying to fix everything. Emphasize that threat modelling is done *early*, during design, because it is far cheaper to design out a class of vulnerability than to patch it later.

   Likely follow-ups:

   • What is a trust boundary, and why do attacks concentrate there?
   • How do you prioritize which threats to actually address?
2. known

   What is the principle of least privilege, and how do you apply it in practice?

   What it tests Whether a foundational security principle is a concrete reflex, not a slogan.

   Model answer

   Least privilege means every user, service, and process gets exactly the access it needs to do its job and no more — the minimum permissions, for the minimum scope, for the minimum time. The reason it is so central: it limits the blast radius of any compromise or mistake. When (not if) an account, a service, or a key is compromised, least privilege determines how much damage the attacker can do — a narrowly-scoped credential yields little, an over-privileged one yields the kingdom. Most serious breaches are made *worse* by excessive privilege: the attacker gets in through one foothold and then moves laterally and escalates because everything had more access than it needed. Applying it in practice, concretely: default deny — start with no access and grant specific permissions as needed, rather than granting broad access and trimming (which never happens); scope tightly — an application's cloud role gets read on the *one* bucket it uses, not s3:*; prefer short-lived credentials over standing ones (temporary role assumption, OIDC) so there is less to steal and it expires; separate duties and environments (prod access is not dev access, and no one person can do everything unchecked); just-in-time / time-bound elevation for administrative access rather than standing admin rights; and review and prune regularly, because permissions accumulate — use access analyzers to find and remove what is unused. The framing interviewers want: least privilege is a default posture (deny by default, grant the minimum) applied everywhere — IAM, network, database, filesystem — precisely because it is the control that contains the damage when something is inevitably compromised, and over-permissioning is the single most common thing that turns a small foothold into a full breach.

   Likely follow-ups:

   • Why do over-broad permissions turn a small compromise into a large breach?
   • How would you find and remove permissions a role is not actually using?
3. known

   What is defense in depth, and why isn't a single strong control enough?

   What it tests Whether you understand layered security and the assumption that any one control fails.

   Model answer

   Defense in depth means layering multiple independent security controls so that if one fails or is bypassed, others still protect the system — you never rely on a single control being perfect. The reasoning is an assumption of failure: any individual control *can* fail — a firewall rule is misconfigured, a patch is missing, a credential leaks, a WAF is bypassed, a person is phished — so a security posture that depends on one line of defense is one failure away from a breach. Layers give you resilience against that. Concretely, for a web application, layers might be: network (segmentation, security groups, so a compromised web server cannot reach the database directly or the internet freely); host (hardening, patching, endpoint protection); application (input validation, output encoding, authentication and authorization done right); data (encryption at rest and in transit, so stolen data or a stolen disk is useless); identity (least privilege, MFA, so a stolen password alone is not enough); monitoring and detection (so an attacker who gets through is *seen* — the layer that assumes prevention failed and focuses on catching the intrusion); and response (the ability to contain and recover). The key property is that the layers are independent — they should not all fail for the same reason (if every layer depends on the same SSO, that SSO is a single point of failure across all of them). The framing interviewers want: assume any single control will eventually fail, so layer independent controls across network, host, app, data, identity, and detection, so an attacker must defeat *several* to succeed — and crucially include detection and response layers, because defense in depth is not only about prevention but about limiting and catching what gets through. The anti-pattern is a 'hard shell, soft center' — a strong perimeter and no internal controls — which falls entirely the moment the perimeter is breached, which is exactly why network segmentation and least privilege *inside* matter.

   Likely follow-ups:

   • Why do the layers need to be independent, and what breaks if they are not?
   • Why is a strong perimeter with a soft interior a dangerous design?
4. known

   How would you secure the software supply chain — the dependencies and build pipeline that produce your software?

   What it tests Whether you understand a rising threat class and the concrete controls, which many candidates cannot detail.

   Model answer

   The supply chain is a rising, high-impact attack surface because compromising a dependency or a build system lets an attacker into everyone downstream, and several major real-world breaches worked exactly this way — you trust code and tools you did not write. Securing it, at the layers where it can be attacked: dependencies — know what you ship by generating an SBOM (software bill of materials, e.g. with Syft), scan it against vulnerability databases (OSV, Trivy) and gate builds on fixable criticals, pin dependencies (ideally with hashes) so a package cannot silently change under you, and minimize and vet what you pull in (fewer, trusted, watched dependencies). The build pipeline itself — it is a high-value target because it has the credentials to ship, so: pin your CI actions/steps to immutable versions (a mutable tag is how several compromises were delivered), use least-privilege short-lived credentials (OIDC, not stored keys), protect the branch that releases, and prevent untrusted (fork) code from running with secrets. Integrity of the artifact — sign your builds (Sigstore/cosign, keyless so there is no key to leak) and generate provenance/attestations (SLSA) that tie the artifact to the exact commit and build, so consumers can *verify* what they run came from your pipeline and was not tampered with — and then enforce that at deploy time (admission control that refuses unsigned images), so the verification is not optional. The framing interviewers want: secure the supply chain in layers — know and scan and pin dependencies, harden the build pipeline (its credentials are the prize), and sign and attest artifacts with verification enforced downstream — because you are defending against trusting code and tools you did not author, and the mature answer names SBOMs, pinning, signing, provenance, and *enforced verification*, not just 'scan for CVEs'.

   Likely follow-ups:

   • Why is the build pipeline itself a high-value target, and how do you harden it?
   • What does signing plus provenance give you that vulnerability scanning does not?

The vulnerability-class round. For each, interviewers want the mechanism, why it happens, and the real fix — not the name and a band-aid.

1. known

   Explain SQL injection: how it works, why it happens, and the correct fix.

   What it tests The archetypal injection vulnerability — depth here signals whether you understand the class, not just the name.

   Model answer

   SQL injection happens when user-controlled input is concatenated into a SQL query as *code* rather than treated as *data*, so an attacker can inject SQL that changes the query's meaning. Classic example: a login query built as "SELECT * FROM users WHERE user = '" + input + "'"; an attacker supplies ' OR '1'='1 (or '; DROP TABLE users; --) and the query's logic changes — they bypass auth, read arbitrary data, or destroy tables. Why it happens: the root cause is mixing code and data — the query is assembled as a string, so the database cannot tell the developer's intended SQL from the attacker's injected SQL; they are the same text stream by the time the database parses it. This is an instance of the general injection problem (the same root cause as command injection, XSS, etc.: untrusted data interpreted as code). The correct fix is parameterized queries / prepared statements: you send the query structure and the parameters *separately* to the database, so the parameters are always treated as data and can never be parsed as SQL, no matter what they contain — the injection is impossible by construction, not filtered out. This is the real fix; input sanitization / escaping is a band-aid (blocklisting quotes, escaping characters) that is error-prone and bypassable and should not be relied on as the primary defense. Defense in depth adds: least-privilege database accounts (the app's DB user cannot DROP tables or read other schemas, limiting the damage of any injection that slips through), and using an ORM or query builder that parameterizes by default. The framing interviewers want: injection is untrusted data being interpreted as code because they were concatenated together, and the correct fix is *structural separation* (parameterized queries), not trying to clean the input — plus least privilege to contain the blast radius. Naming parameterized queries as *the* fix, and explaining why sanitization is insufficient, is the depth signal.

   Likely follow-ups:

   • Why is input sanitization an insufficient fix on its own?
   • How does a least-privilege database account limit the damage of an injection?
2. known

   What is the difference between authentication and authorization, and what are the common ways each goes wrong?

   What it tests Whether you understand the two distinct problems and the vulnerability classes in each — access control is the most common serious flaw.

   Model answer

   Authentication is verifying *who* you are (proving identity — a login); authorization is verifying *what you are allowed to do* (access control — can this authenticated user perform this action on this resource). They are distinct problems and both go wrong in characteristic ways. Authentication failures: weak password handling (storing passwords in plaintext or with fast/unsalted hashing instead of a slow salted hash like bcrypt/argon2, so a database leak exposes them); no protection against credential stuffing/brute force (no rate limiting, no MFA — so leaked-password reuse works); weak session management (predictable or non-expiring session tokens, tokens not invalidated on logout); and missing MFA on sensitive accounts. Authorization failures — and these are the more common *serious* flaw class, topping the OWASP list as 'broken access control': the big one is IDOR / broken object-level authorization — the app checks you are logged in but not that *this* resource is yours, so changing an ID in the URL (/orders/123 → /orders/124) lets you see someone else's data; missing function-level checks (a regular user can call an admin endpoint because the check is only in the UI, not enforced server-side); privilege escalation (a user can grant themselves more access); and trusting client-side controls (hiding a button is not authorization — the server must enforce it). The framing interviewers want: authentication proves identity, authorization enforces permissions, and the most common serious flaw is broken access control — especially failing to check that an authenticated user actually owns or may access the specific object they requested (IDOR). The fix for authorization is to enforce access checks server-side on every request, per object and per function, never trusting the client, and to default-deny. The signal is knowing that 'logged in' is not 'allowed', and that the object-level 'is this yours?' check is the one most often missed.

   Likely follow-ups:

   • What is IDOR, and why is it so commonly missed?
   • Why is hiding a UI element not a form of authorization?
3. known

   Explain cross-site scripting (XSS): the types, the impact, and the fix.

   What it tests Whether you understand a core web vulnerability and the correct output-encoding defense.

   Model answer

   XSS is when an attacker gets their JavaScript to run in another user's browser in the context of your site, by injecting script into content the site renders — the injection problem again, but with the browser as the interpreter and JavaScript as the injected code. Types: stored (persistent) — the malicious script is saved on the server (in a comment, a profile field) and served to every user who views it, the most dangerous because it hits many victims; reflected — the script is in a request (a URL parameter) and reflected back in the response, so the attacker must trick a victim into clicking a crafted link; and DOM-based — the vulnerability is in client-side JavaScript that unsafely writes untrusted data into the DOM, without the server being involved. Impact: the attacker's script runs as the victim in your site's origin, so it can steal session cookies/tokens (account takeover), perform actions as the user, read data on the page, keylog, or deface — essentially it fully compromises that user's session with your app. The fix is context-aware output encoding: whenever you render untrusted data into a page, encode it for the context it appears in (HTML-encode for HTML body, attribute-encode for attributes, JS-encode for scripts, URL-encode for URLs) so the browser treats it as text to display, not code to execute — this is the primary, structural fix, analogous to parameterized queries for SQL. Modern frameworks (React, etc.) do this by default, which prevents most XSS — the danger is the escape hatches (dangerouslySetInnerHTML, direct DOM manipulation). Defense in depth adds: a Content Security Policy (restricts what scripts can run, so even injected script is blocked from executing or exfiltrating), setting cookies HttpOnly (so JavaScript cannot read the session cookie even if XSS occurs) and Secure, and validating input. The framing interviewers want: XSS is untrusted data executed as script in the victim's browser, the three types differ by where the payload lives (stored/reflected/DOM), the impact is running as the victim (session theft, account takeover), and the fix is context-aware output encoding (structural, like parameterized queries) backed by CSP and HttpOnly cookies — with the key insight that, as with SQL injection, the real fix is treating data as data at the point of rendering, not trying to blocklist bad input.

   Likely follow-ups:

   • Why is output encoding, not input filtering, the primary fix for XSS?
   • How do HttpOnly cookies and a Content Security Policy limit the damage of an XSS that does occur?
4. known

   How would you securely store user passwords, and why is a fast hash the wrong choice?

   What it tests Whether you understand password storage — a topic where wrong answers are common and consequential.

   Model answer

   You never store passwords in a recoverable form — not plaintext, not encrypted (encryption is reversible, so a leaked key exposes everything). You store a salted hash using a slow, purpose-built password hashing function — bcrypt, scrypt, or argon2 (argon2 is the current recommendation). The two essential properties: salting — a unique random salt per password, stored alongside the hash, so that identical passwords produce different hashes (defeating precomputed rainbow tables) and an attacker must attack each password individually rather than all at once; and slowness / work factor — the function is deliberately expensive (with a tunable cost parameter), which is the whole point. Why a fast hash (MD5, SHA-256) is wrong: fast is a *virtue* for general hashing but a *disaster* for passwords, because if the database leaks, an attacker runs the same fast hash over billions of candidate passwords per second on a GPU and cracks weak and medium passwords almost instantly — the speed that makes SHA-256 good for checksums makes it terrible for passwords, because it makes brute-forcing cheap. A slow password hash (bcrypt/argon2) is engineered to be expensive to compute — so a legitimate single login is fine (a few hundred milliseconds) but an attacker's billion-guess brute force becomes computationally infeasible or vastly slower, and the cost factor can be raised over time as hardware improves. Additional measures: enforce reasonable password strength / check against known-breached passwords, add MFA (so a cracked password alone is not enough), rate-limit login attempts, and consider a server-side secret pepper. The framing interviewers want: store a per-password salted hash with a slow, tunable password-hashing function (argon2/bcrypt/scrypt), and understand that a fast general-purpose hash is wrong precisely *because* it is fast — password hashing is one of the few places where you deliberately choose the slow algorithm, to make offline brute-forcing after a leak infeasible. Knowing *why* slow matters (offline GPU cracking) is the depth signal that separates real understanding from 'use bcrypt'.

   Likely follow-ups:

   • What does a per-password salt defend against specifically?
   • Why is the work factor tunable, and how would you set it?

Where most real breaches now happen — misconfigurations, not exotic exploits. Interviewers want the common breach causes and how you prevent them systematically.

1. known

   What are the most common cloud misconfigurations that lead to breaches, and how do you prevent them?

   What it tests Whether you know where real cloud breaches actually come from — misconfigurations, not zero-days.

   Model answer

   Most cloud breaches are misconfigurations, not sophisticated exploits, so knowing the common ones and preventing them systematically is the core of cloud security. The recurring culprits: publicly exposed storage (an S3 bucket or blob store set public, leaking data — the classic headline breach); over-privileged IAM (roles and users with far more access than needed — often wildcard * permissions — so any compromise becomes a large one, and lateral movement is easy); exposed secrets (credentials, API keys committed to code repos, baked into images, or in environment variables in plaintext); overly open network access (security groups allowing 0.0.0.0/0 to sensitive ports — databases, admin interfaces, SSH — directly exposed to the internet); unencrypted data (storage or databases without encryption at rest); disabled or unmonitored logging (no audit trail, so breaches go undetected); and public-facing management/debug endpoints. Preventing them systematically — the key word is *systematically*, because you cannot rely on every engineer getting every config right: secure defaults (block public access at the account level, encryption on by default); policy as code / preventative guardrails (Service Control Policies and admission/config policies that make the insecure state *impossible* — 'no bucket can be public', 'no security group can open the DB port to the world' — enforced, not documented); least privilege as the IAM default with regular pruning; secret scanning in repos and CI, and secrets in a proper secret manager with short-lived credentials (OIDC); CSPM tools (cloud security posture management) that continuously scan for these misconfigurations and flag or auto-remediate; and audit logging enabled everywhere with monitoring. The framing interviewers want: real cloud breaches come from misconfiguration — public storage, over-broad IAM, exposed secrets, open network access — and the defense is *systematic prevention* (secure defaults, enforced policy-as-code guardrails, continuous scanning) rather than trusting individuals to configure everything correctly, because at scale someone eventually will not. The maturity signal is 'make the insecure configuration impossible or immediately detected', not 'train people to be careful'.

   Likely follow-ups:

   • How does policy-as-code make an insecure configuration impossible rather than just discouraged?
   • Why are misconfigurations, rather than zero-days, the dominant cause of cloud breaches?
2. known

   How would you handle secrets — API keys, database passwords — in a cloud environment?

   What it tests Whether you know secrets management end to end, a topic where mistakes cause frequent breaches.

   Model answer

   The goals are: secrets are never exposed (not in code, images, or logs), access to them is least-privilege and audited, and they can be rotated. Concretely: never in source code or config committed to Git — this is the most common leak, so use secret scanning in the repo and CI to catch it, and treat any committed secret as compromised (rotate it, do not just delete the commit — it is in the history and possibly already cloned). Store secrets in a dedicated secret manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) rather than environment variables in plaintext or config files — the manager provides encryption at rest, access control, audit logging (who read what, when), and rotation. Inject at runtime — the application fetches the secret from the manager (or it is mounted) at startup or on demand, so it is never baked into the image (a secret in an image layer is extractable and shipped everywhere the image goes). Prefer eliminating long-lived secrets entirely where possible: use short-lived credentials via role assumption / OIDC federation / workload identity — for example, a pipeline or a workload assumes a role and gets temporary credentials, so there is no standing key to leak, and a leaked short-lived credential expires in minutes. Least-privilege access to each secret (a service reads only its own secrets), rotation (automated where the manager supports it, so a leaked secret has a limited lifetime), and audit logging so you can detect and investigate unusual access. The framing interviewers want: keep secrets out of code and images (with scanning to enforce it), store them in a secret manager with encryption, access control, and audit, inject at runtime, and *prefer short-lived credentials over standing secrets* (OIDC/role assumption) so the best-managed secret is the one that does not exist — plus rotation and least privilege. The signal is naming the full lifecycle (storage, injection, rotation, least-privilege, audit) and, especially, reaching for short-lived credentials as the superior approach rather than just 'put it in a vault'.

   Likely follow-ups:

   • Why is a secret committed to Git compromised even after you delete the commit?
   • Why are short-lived credentials via OIDC better than a well-stored long-lived secret?
3. known

   How would you design network segmentation for a cloud environment, and why does it matter?

   What it tests Whether you understand segmentation as a blast-radius control, not just 'have a firewall'.

   Model answer

   Network segmentation divides the network into isolated zones with controlled communication between them, so that a compromise in one zone cannot freely reach others — it is fundamentally a blast-radius and lateral-movement control. Why it matters: attackers rarely land on their ultimate target directly; they get an initial foothold (a compromised web server, a phished workstation) and then move laterally to reach the valuable systems. A flat network — everything can talk to everything — means one foothold gives access to the whole environment, which is how a single compromised server becomes a full breach. Segmentation forces the attacker to defeat additional controls to move, contains the damage, and gives you detection opportunities at the boundaries. Designing it in the cloud: tier separation — the classic public/private subnet split, with only load balancers and NAT in public subnets and application servers and databases in private subnets never directly reachable from the internet; security groups as the primary control, written as a chain so each tier accepts traffic only from the tier in front of it (the DB accepts only from the app tier's security group, not from a wide range) — micro-segmentation down to the workload; separate VPCs/accounts for different environments and trust levels (prod isolated from dev, with controlled or no connectivity), which is segmentation at the account level and a strong blast-radius boundary; egress controls (a compromised server should not be able to freely call out to the internet to exfiltrate data or fetch a payload — restrict outbound too, which people often forget); and zero-trust principles where feasible (authenticate and authorize service-to-service traffic, do not trust something just because it is 'inside the network'). The framing interviewers want: segmentation limits lateral movement and blast radius, implemented in the cloud through public/private tiering, security-group chains that only allow the necessary flows (least privilege for the network), account/VPC isolation across trust boundaries, and egress restrictions — all resting on the assumption that a foothold *will* happen, so the network is designed to contain it rather than to have a hard perimeter and a flat, trusting interior. The 'assume breach, contain lateral movement' framing, and remembering egress, are the depth signals.

   Likely follow-ups:

   • What is lateral movement, and how does segmentation impede it?
   • Why restrict outbound (egress) traffic, not just inbound?
4. known

   What is the shared responsibility model in cloud security, and where do teams get it wrong?

   What it tests Whether you understand the division of security duties — a conceptual foundation teams frequently misjudge.

   Model answer

   The shared responsibility model divides security duties between the cloud provider and the customer: the provider secures the infrastructure — the physical data centers, the hardware, the hypervisor, the managed-service internals — **security *of* the cloud; the customer secures what they put in it and how they configure it — their data, their access management (IAM), their network configuration, their application code, their OS patching (for IaaS) — security *in* the cloud. The exact line shifts by service model: with IaaS (VMs) the customer owns more (the OS, patching, everything above the hypervisor); with PaaS/managed services** (a managed database, serverless) the provider takes on more (patching the database engine, the runtime), but the customer *always* owns their data, their IAM/access configuration, and how they set the service up. Where teams get it wrong — and this is the important, breach-causing part: they assume the cloud provider secures more than it does, treating 'it's in AWS, so AWS secures it' as covering their own responsibilities. The provider secures the infrastructure, but it will happily let you make a bucket public, grant a role * permissions, open a database to the internet, or store data unencrypted — those are the *customer's* configuration, and the vast majority of cloud breaches are exactly these customer-side misconfigurations, not the provider's infrastructure failing. So the dangerous misunderstanding is a false sense of security: 'the cloud is secure' is true about the infrastructure and false about the customer's configuration and data, which is where breaches actually happen. The framing interviewers want: provider secures *of* the cloud (infrastructure), customer secures *in* the cloud (data, IAM, network config, app), the line moves with the service model but data and access are always yours, and the common, costly error is assuming the provider covers the customer's configuration responsibilities — leading to the public buckets and over-broad IAM that cause real breaches. Knowing that the model is why misconfiguration is *your* problem, not the provider's, is the maturity signal.

   Likely follow-ups:

   • How does the responsibility line shift between IaaS and a managed serverless service?
   • Why does 'it's in the cloud, so it's secure' lead to breaches?

When prevention fails — and it will — how you detect and respond. Interviewers want method, evidence discipline, and the right order of operations.

1. known

   Walk me through how you would respond to a confirmed security breach.

   What it tests Whether you know the incident-response lifecycle and the crucial ordering — evidence before eradication.

   Model answer

   I would follow the incident-response lifecycle in order, and the *order* is the point, because doing steps out of sequence (especially eradicating before preserving evidence) destroys your ability to understand and prove what happened. The phases: 1. Preparation (done beforehand — the plan, the tools, the contacts exist). 2. Detection and analysis — confirm it is a real incident, and scope it: what systems, what data, what accounts are affected, and how the attacker got in. Understanding scope before acting is critical, because containing only part of the breach lets the attacker persist. 3. Containment — stop the bleeding and prevent spread, but preserve evidence first — this is the crucial discipline: before you wipe or rebuild anything, capture forensic evidence (memory, disk images, logs) because eradication destroys the evidence you need to understand the attack and may need legally; isolate affected systems (network-isolate rather than immediately power off, which can lose volatile evidence and tip off the attacker), disable compromised credentials, and cut off the attacker's access. Distinguish short-term containment (immediate isolation) from a considered approach that does not just tip the attacker into doing damage. 4. Eradication — remove the attacker's foothold: malware, backdoors, created accounts, persistence mechanisms — *after* evidence is preserved and you understand scope, or you will miss backdoors and they return. 5. Recovery — restore systems to clean known-good state, rotate all potentially-compromised credentials, monitor closely for the attacker's return, and bring services back carefully. 6. Post-incident / lessons learned — a blameless review: how did they get in, what did we miss, what do we change (the systemic fixes), and did we handle it well. Throughout: communication (stakeholders, and legal/regulatory notification obligations — many breaches have mandatory disclosure timelines, so involve legal early), and a timeline/documentation of everything done. The framing interviewers want: the ordered lifecycle (prepare → detect/scope → contain-preserving-evidence → eradicate → recover → learn), with the two things people get wrong called out — preserve evidence before eradicating (forensic discipline), and scope fully before containing (or the attacker persists) — plus early legal/comms involvement and a blameless retro. The evidence-before-eradication ordering is the signal that you have thought about real incident response, not just 'find it and delete it'.

   Likely follow-ups:

   • Why preserve forensic evidence before eradicating the threat?
   • Why scope the full breach before containing, rather than reacting to the first sign?
2. known

   How would you design detection so that an attacker who gets in is actually caught?

   What it tests Whether you understand detection engineering — logging the right things and alerting on real signals.

   Model answer

   Prevention fails, so detection is the layer that assumes the attacker is already in and aims to catch them — and it only works if you log the right things and alert on meaningful signals rather than drowning in noise. The foundation is logging: collect the security-relevant events centrally (in a SIEM or log platform) and, critically, centralize them off the hosts — because an attacker with access to a host will tamper with its local logs, so logs must be shipped somewhere the attacker cannot reach and alter. Log authentication (logins, failures, privilege use), access to sensitive data, administrative and configuration changes (cloud API calls via CloudTrail/activity logs — 'who created this admin user'), network flows, and process/execution where you can. Then write detections for real attacker behaviour, mapped to how attackers actually operate (frameworks like MITRE ATT&CK enumerate the techniques): brute force / credential stuffing (many failed logins then a success), privilege escalation (a user granted new admin rights, a new account created), unusual data access or exfiltration (large or anomalous data egress), lateral movement, execution of suspicious commands, and changes to security controls (someone disabling logging is itself a strong signal). Detections should target symptoms of compromise, and you should test them — actually simulate the attacks (Atomic Red Team, a purple-team exercise) to confirm the detection fires, because an untested detection is a hope. Crucially, manage alert quality: too many false positives cause alert fatigue and the real alert gets missed, so tune for actionable, high-signal alerts — alert fatigue is itself a security risk. And measure coverage honestly (what techniques can you detect, what are your blind spots — you cannot detect execution without process logs, etc.). The framing interviewers want: detection assumes breach and catches the attacker via centralized, tamper-resistant logging of the right events, detections written for real attacker techniques (ATT&CK) and *tested* by simulating them, tuned to be high-signal to avoid fatigue, with honest coverage of blind spots — the mature answer is 'log the right things off-host, detect actual attacker behaviour, test the detections, and manage alert quality', not 'turn on all the logs and alerts'.

   Likely follow-ups:

   • Why must logs be centralized off the host, and what does an attacker do to local logs?
   • Why is an untested detection unreliable, and how would you test one?
3. known

   What would you look at first if you suspected an account had been compromised?

   What it tests Whether you can investigate a compromise practically, following the attacker's activity.

   Model answer

   The goal is to determine whether it is really compromised, and if so, what the attacker did — so I would follow the account's activity, working from 'is this the legitimate user' to 'what has this account touched'. Start with the authentication history: the login events for the account — from where (unusual IP, geography, country the user has never logged in from, an 'impossible travel' pattern of two logins from distant places too close in time), when (odd hours), and how (was MFA satisfied, or bypassed / a new MFA device added — attackers often register their own MFA to persist). A login that does not fit the user's normal pattern is the first red flag. Then the account's actions since the suspicious login — this is where the audit log is essential: what did the account *do*? For a cloud account, the API/activity log (CloudTrail) shows every action — did it create new users or access keys (persistence), change permissions (escalation), access data it does not normally touch, disable logging or security controls, or spin up resources (e.g. for cryptomining)? For an application account, what data did it access, what actions did it take, did it change its own settings (email, password, recovery options — attackers change these to lock out the real user and maintain access). I would also check for new persistence the attacker may have established (new credentials, new access grants, forwarding rules) because just resetting the password does not remove those. Based on what I find, contain — disable the account/credentials, revoke its sessions and any tokens/keys it created, and remove attacker-established persistence — while preserving the log evidence, and then scope whether the attacker moved from this account to others (lateral movement). The framing interviewers want: investigate a suspected compromise by following the account's authentication anomalies (location, time, MFA changes) and then its actions via the audit log (what it accessed, what it changed, what persistence it created), because the questions are 'is this really the user' and 'what have they done and how are they maintaining access' — and remembering that resetting the password is not enough if the attacker created new keys or access, which the audit log reveals, is the practical-experience signal.

   Likely follow-ups:

   • Why is resetting the password insufficient to remove a determined attacker?
   • What in the audit log would indicate the attacker established persistence?
4. known

   How do you balance security with developer productivity — how do you avoid being the team that just says no?

   What it tests Whether you understand that security must enable the business, a maturity and collaboration signal.

   Model answer

   This is a real tension and a career-defining attitude question: security that blocks everything gets bypassed — developers route around a security team that is a pure obstacle (shadow IT, disabled controls, 'we'll ask forgiveness'), which leaves you *less* secure than a pragmatic approach, because the controls people evade protect nothing. So the mature stance is that security's job is to enable the business to move fast safely, not to say no. Concretely: make the secure path the easy path — provide paved roads (secure defaults, vetted libraries, templates, pre-approved patterns) so doing the right thing is the low-effort thing, rather than a gauntlet of manual reviews; shift left — build security into the tools and pipeline (automated scanning, secure defaults, guardrails as code) so it is fast, automatic feedback in the developer's flow rather than a late blocking gate that feels like an ambush. Risk-based prioritization — not everything is critical, so focus friction where the risk is real and get out of the way on low-risk things, rather than treating every issue as a blocker (crying wolf on low-risk findings trains people to ignore you). Collaborate and educate — partner with developers, understand their constraints, explain the *why* (people follow controls they understand), and be a helpful advisor, not a gatekeeper. When you must say no, offer a yes — 'not that way, but here is a secure way to achieve what you need', because a flat no with no alternative is what breeds resentment and workarounds. The framing interviewers want: security must enable, not just gate — the team that only says no gets bypassed and is therefore ineffective, so you make the secure way the easy way (paved roads, secure defaults, automation in the pipeline), prioritize by real risk, collaborate and educate, and always pair a 'no' with a workable secure alternative. This 'enable the business securely / make the secure path the easy path' philosophy is exactly the maturity signal that separates a senior security engineer from a junior one who thinks the job is to block things.

   Likely follow-ups:

   • What happens to a security control that developers find too painful?
   • How does 'shifting left' reduce the security-versus-productivity tension?

The crypto round is not about implementing algorithms — it is about knowing what each primitive is for and how identity systems work. Interviewers want correct mental models and the common mistakes.

1. known

   What is the difference between symmetric and asymmetric encryption, and where is each used?

   What it tests Whether you understand the two encryption models and why real systems combine them.

   Model answer

   Symmetric encryption uses one shared key for both encryption and decryption (AES is the standard) — it is fast and efficient, so it is what actually encrypts bulk data (files, disks, the payload of a network connection). Its problem is key distribution: both parties need the same secret key, and getting that key to the other party securely, over an untrusted network, is hard. Asymmetric (public-key) encryption uses a key pair — a public key that anyone can have and a private key kept secret (RSA, elliptic-curve) — where something encrypted with the public key can only be decrypted with the private key (and signing works the reverse way). This solves key distribution — you can publish your public key freely — and enables digital signatures and identity, but it is much slower and only practical for small amounts of data. So real systems combine them, which is the key insight: TLS uses asymmetric crypto to authenticate the server and to securely exchange (or agree on) a symmetric session key, then switches to fast symmetric encryption for the actual data of the connection — you get asymmetric's key-distribution/identity solution and symmetric's speed. The framing interviewers want: symmetric is fast, one shared key, for bulk data, but hard to distribute keys; asymmetric is slow, a public/private pair, solves key distribution and enables signatures/identity, but only for small data; and practical protocols like TLS use asymmetric to establish trust and exchange a symmetric session key, then symmetric for the payload — 'use asymmetric to bootstrap, symmetric to transport' is the model. Knowing *why* they are combined (the speed/distribution trade-off) is the depth signal, versus just defining the two.

   Likely follow-ups:

   • Why does TLS use both rather than just one?
   • Why is asymmetric encryption impractical for encrypting large amounts of data directly?
2. known

   What is the difference between encryption, hashing, and encoding — and where do people confuse them?

   What it tests Whether you keep three distinct concepts straight — a confusion that leads to real security mistakes.

   Model answer

   They are three different things for three different purposes, and confusing them causes real vulnerabilities. Encoding (Base64, URL encoding, hex) is *not security at all* — it is a reversible transformation to represent data in a different format for transport or compatibility, with no key and no secret, so anyone can decode it trivially. The dangerous confusion is treating Base64 as if it hides or protects data — 'the password is Base64 encoded' provides *zero* confidentiality; it is obfuscation, not protection. Hashing is a one-way function — it maps input to a fixed-size digest that cannot be reversed to recover the input — used for integrity (has this data been tampered with — the same input always gives the same hash, so a changed hash means changed data) and for storing things you only need to verify, not recover, like passwords (you store the hash and compare hashes on login, never recovering the password). It is not encryption because it is irreversible and has no key. Encryption is a reversible transformation using a key that provides confidentiality — data is scrambled and can only be recovered with the key, so it protects secrets you need to read back later. The confusions to name: using encoding thinking it secures data (it does not — no key, trivially reversible); using encryption for passwords (wrong — encryption is reversible, so a leaked key exposes all passwords; use a slow *hash* instead, which you never need to reverse); and using a fast hash where you need encryption or vice versa. The framing interviewers want: encoding = reversible, no key, for format/transport, *not security*; hashing = one-way, no key, for integrity and verify-don't-recover (passwords); encryption = reversible, keyed, for confidentiality — and the classic mistakes are thinking Base64 protects anything and encrypting passwords instead of hashing them. Keeping these three straight, and naming the specific confusions, is the signal.

   Likely follow-ups:

   • Why is storing a password with encryption worse than with a hash?
   • Why does Base64-encoding a secret provide no protection at all?
3. known

   What is a digital signature, and how does it provide integrity and authenticity?

   What it tests Whether you understand signing — the basis of code signing, certificates, and much of trust online.

   Model answer

   A digital signature proves that a piece of data came from a specific holder of a private key and was not altered — it provides authenticity (who created/sent it), integrity (it was not modified), and non-repudiation (the signer cannot later deny it). How it works, combining hashing and asymmetric crypto: the signer hashes the data (producing a fixed digest that represents its exact contents) and then encrypts that hash with their private key — that encrypted hash is the signature, attached to the data. Anyone can verify it using the signer's public key: they decrypt the signature with the public key to recover the original hash, independently hash the data themselves, and compare — if the two hashes match, then (a) the data was not changed since signing (integrity — any modification changes the hash and the comparison fails), and (b) it was signed by the holder of the corresponding private key (authenticity — only that private key could have produced a signature the public key decrypts correctly). The reason both properties hold: the hash guarantees integrity (it is a fingerprint of the exact content), and signing the hash with the private key (which only the signer has) guarantees authenticity. This underpins a huge amount of trust online: TLS certificates (a CA signs a certificate vouching for a server's identity), code signing and software supply-chain provenance (proving a build came from a specific pipeline and was not tampered with — like Sigstore), signed commits, JWTs, and more. The framing interviewers want: a signature is 'hash the data, encrypt the hash with the private key', verified by 'decrypt with the public key and compare to a fresh hash', giving integrity (hash catches tampering) and authenticity (only the private-key holder could sign) — and it is the mechanism behind certificates, code signing, and provenance. Note that signing does *not* provide confidentiality (the data itself is not encrypted, only the hash is signed) — a common point of confusion — it proves origin and integrity, not secrecy.

   Likely follow-ups:

   • Does a digital signature keep the data secret? Why or why not?
   • How does a certificate authority use signatures to establish trust in TLS?
4. known

   What is multi-factor authentication, and why is it so effective against common attacks?

   What it tests Whether you understand MFA beyond 'it's more secure' — the specific attacks it defeats.

   Model answer

   Multi-factor authentication requires two or more *independent* factors from different categories to prove identity: something you know (a password/PIN), something you have (a phone, a hardware token, an authenticator app), and something you are (a biometric — fingerprint, face). The 'multi-factor' part specifically means factors from different categories — two passwords are not MFA, because they are both 'something you know' and both fall to the same attack. It is so effective because it breaks the most common attack path: the vast majority of account compromises start with a stolen or guessed password — from a data breach (password reuse), phishing, or brute force — and MFA means the password *alone* is not enough; the attacker also needs the second factor, which they typically do not have (they are not holding your phone or your hardware key). So MFA defeats credential stuffing (leaked passwords from one site reused on another — the password works but the second factor blocks the login), phishing of passwords (a phished password is useless without the second factor — though note that some MFA is itself phishable, see below), and brute-force/password-guessing. The nuance that shows depth: not all MFA is equal against phishing. SMS-based codes are the weakest (vulnerable to SIM-swapping and interception) and phishable (an attacker's fake site can relay the code in real time); authenticator apps (TOTP) are better but still phishable via real-time relay; phishing-resistant factors — hardware security keys / FIDO2/WebAuthn — are the strongest because they cryptographically bind the authentication to the real site's origin, so a fake phishing site cannot use the response (the key simply will not authenticate to the wrong domain). The framing interviewers want: MFA requires independent factors from different categories, and it is effective because most compromises begin with a stolen password, which MFA renders insufficient on its own — defeating credential stuffing, phishing, and brute force — and the mature answer adds that MFA strength varies (SMS weakest, hardware/FIDO2 phishing-resistant and strongest), so 'require MFA, and prefer phishing-resistant factors for sensitive access' is the nuanced recommendation rather than just 'turn on MFA'.

   Likely follow-ups:

   • Why are two passwords not multi-factor authentication?
   • Why is a hardware security key (FIDO2) phishing-resistant when an SMS code is not?