Cybersecurity interview questions

What is the difference between hashing, encryption and encoding, and when do you use each?

The strongest answer: Hashing is one-way and used to verify, such as a password check; encryption is reversible with a key and used to keep data confidential; encoding such as base64 is only a format change and protects nothing

Why it works: Exactly — and calling out encoding matters, because that is the confusion the question is testing for.

• One-way, reversible, or neither.
• Hash to verify; encrypt to protect.
• Encryption needs a managed key.
• Encoding is a format, not a control.

A teammate commits an API key “just for staging.” What do you do?

The strongest answer: Treat it as a leak: rotate the key, pull it from a vault or CI secrets, and assume the commit was copied — staging is not “fake enough”

Why it works: Exactly. A committed secret is public to anyone with the repo history. Rotate, do not decorate.

• Rotate the leaked key.
• Store secrets outside git.
• Staging is still a system.
• Do not encode and call it safe.

What is the CIA triad, and why do interviewers keep asking about it?

The strongest answer: Confidentiality, integrity, availability — the three things an attack damages. Naming which one a risk hits tells you which control to reach for

Why it works: Exactly — it is a sorting tool. Ransomware is availability and integrity; a leaked export is confidentiality.

• Three goals, not three products.
• Confidentiality: who may see it.
• Integrity: is it still true.
• Availability: can we reach it.

What is the difference between a region and an availability zone?

The strongest answer: A region is a geographic area with several availability zones; each zone is one or more separate data centres with its own power and network, so spreading across zones survives a data-centre failure

Why it works: Right. The zone is the fault boundary you design around; the region is where your data lives.

• Region: a geography with multiple zones.
• Zone: isolated power, cooling and network.
• Spread across zones for availability.
• Spread across regions for disaster recovery.

Why must credentials stay out of query strings?

The strongest answer: URLs land in logs, history, Referer, and support tickets — a password in a GET is a leak, not a shortcut

Why it works: Exactly. HTTPS protects the path on the wire; it does not unsay access logs and browser history.

• No secrets in URLs.
• Logs and Referer copy query strings.
• HTTPS is not enough.
• Use a body or a header.

IaaS, PaaS, SaaS — what does each one leave to you?

The strongest answer: IaaS gives you machines and networks and you run everything on them; PaaS runs the platform and you bring code and data; SaaS is a finished application you configure

Why it works: Exactly. The line that moves is who patches, scales and operates the layer underneath.

• IaaS: VMs, disks, networks — you run the rest.
• PaaS: bring code and data, the platform runs it.
• SaaS: a finished product you configure.
• The difference is who operates each layer.

What is the difference between authentication and authorization?

The strongest answer: Authentication is who you are; authorization is what you may do — a valid login can still be forbidden on a path

Why it works: Exactly. Who versus what. Mixing them is how IDOR and “but I logged in” bugs ship.

• Authn = who.
• Authz = what.
• Login is not permission.
• MFA does not skip authz.

What does a firewall actually decide, and what can it not protect you from?

The strongest answer: It allows or blocks traffic by source, destination, port and protocol — it cannot tell a good request from a malicious one on a port you have allowed

Why it works: Exactly — that gap is why an allowed port still needs application controls, and why egress rules matter too.

• Firewalls filter reachability, not intent.
• Match on address, port, protocol.
• Allowed ports still carry attacks.
• Filter egress as well as ingress.

When would you use object storage rather than a block volume?

The strongest answer: For files you read and write whole over HTTP — uploads, backups, static assets, data-lake files — because object storage is durable, cheap and shared, while a block volume is a disk attached to one machine

Why it works: Right. Whole-object access, shared, durable and cheap; a disk is for a filesystem or a database.

• Object: whole files over HTTP, shared, cheap, durable.
• Block: a disk for one machine's filesystem or database.
• Pick by access pattern, not by speed.
• Static assets and backups belong in object storage.

When do you return 401 versus 403 on an API?

The strongest answer: 401 when we do not have a valid identity; 403 when we know who you are and you still may not do this — do not hide both as 404 unless you have a reason to

Why it works: Exactly. Clients branch: sign in versus give up. 404-as-policy is a choice you can name, not a default muddle.

• 401 = authenticate.
• 403 = you may not.
• 404-hiding is a named policy.
• Do not wrap either in 200.

You create a new storage bucket for user uploads. Who can read it by default, and what should you check?

The strongest answer: Nobody outside your account — buckets are private by default; check that public access stays blocked and grant access through the application's role or signed URLs, never by making the bucket public

Why it works: Right. Private by default, and keep it that way; a signed URL is how a user gets one file.

• Buckets are private by default.
• Keep public access blocked at the account level.
• Serve user files by signed URL or through a role.
• A public bucket of uploads is a data breach waiting.

What is the core of injection, in this interview?

The strongest answer: Untrusted input reaching an interpreter — SQL, shell, HTML, LDAP — without a boundary that keeps it data

Why it works: Exactly. Data versus instruction. SQL is the famous case, not the only interpreter.

• Untrusted input + interpreter.
• Keep it data.
• Not only SQL.
• A scanner is not the definition.

How do you use STRIDE without turning it into a homework novel?

The strongest answer: As a prompt on one feature: spoof, tamper, repudiate, info-leak, deny, elevate — write the two that are real, skip the empty boxes

Why it works: Exactly. A prompt, not a spreadsheet religion. Empty cells are honesty.

• Use STRIDE as a prompt.
• Write the real two.
• Empty is ok.
• Do not replace it with a CVE dump.

A user has an allow policy for an action and their group has a deny for it. What happens?

The strongest answer: The deny wins — policy evaluation starts from implicit deny, an explicit allow grants, and an explicit deny anywhere overrides every allow

Why it works: Right. Deny beats allow, always; that is what makes guardrail denies trustworthy.

• Default: implicit deny.
• Explicit allow grants.
• Explicit deny overrides everything.
• Guardrails are written as denies for that reason.

How do you use the OWASP Top 10 in a design review?

The strongest answer: As a risk checklist for this feature — broken access, injection, crypto, design — not as trivia to recite the numbers

Why it works: Exactly. It is a conversation starter about this change. Reciting numbers is trivia.

• Map Top 10 to this feature.
• Broken access first, often.
• Do not recite numbers.
• Modern ≠ immune.

When would you use symmetric encryption, when asymmetric, and why do real systems use both?

The strongest answer: Symmetric is fast and fine for bulk data when both sides can hold the same key; asymmetric solves getting a key to someone you have never met and lets you verify a signature — so systems use asymmetric to agree a symmetric key and then encrypt the data with it

Why it works: Right — that hybrid pattern is what the question is fishing for, and it is what a TLS session does.

• Asymmetric distributes, symmetric carries.
• Same key both sides: symmetric.
• Key pair for strangers and signatures.
• Hybrid is the normal design.

A service on a VM needs to read from a storage bucket. How does it get permission?

The strongest answer: Attach a role to the instance with a policy scoped to that bucket; the SDK picks up temporary credentials from the instance metadata, and nobody ever creates or stores an access key

Why it works: Exactly. Instance roles are the pattern; keys on disks are the breach.

• Instance or workload role, scoped to the resource.
• Temporary credentials from metadata.
• No access keys on machines.
• Least privilege on the policy.

A GitHub Action prints the environment “for debug.” What do you fear?

The strongest answer: Secrets in the log — masked or not, I stop the print, rotate what might have appeared, and keep debug behind an allow-list

Why it works: Exactly. CI logs are a public-ish diary. Masking fails in pieces and concatenations.

• Do not dump env.
• Rotate if it might have printed.
• Masking is incomplete.
• Debug is allow-listed.

Your application servers are in private subnets and need to call an external API. How do they reach it?

The strongest answer: Through a NAT gateway in a public subnet: outbound connections work, nothing inbound can reach the servers, and for provider services a VPC endpoint avoids the NAT entirely

Why it works: Right. NAT for outbound to the internet; endpoints for the provider's own services.

• NAT gateway: outbound only.
• Servers keep no public address.
• VPC endpoints for provider services.
• NAT has a per-gigabyte cost — watch it.

GET /invoices/184 works for any logged-in user. What is the bug?

The strongest answer: IDOR / broken object authz — the server must check this caller may see 184, not only that they have a cookie

Why it works: Exactly. Identity is not authorization on this row. Hiding the URL is not a check.

• Check object-level authz.
• A session is not enough.
• Do not hide the id as a fix.
• Rate limit is a different control.

How do you protect an object store against accidental deletes and stop it from growing forever?

The strongest answer: Turn on versioning so a delete or overwrite keeps the previous version, and add lifecycle rules to expire old versions and move cold data to cheaper tiers

Why it works: Right. Versioning is the undo; lifecycle rules are the cost control that makes it affordable.

• Versioning keeps previous versions.
• Lifecycle rules expire and tier them.
• Durability is not undo.
• MFA delete for the crown jewels.

The interviewer asks: “JWT access token versus a server session cookie — how do you choose?” Strongest answer?

The strongest answer: Sessions (HttpOnly Secure cookie, server-side revocation) are the default for a browser app I own. JWTs fit APIs and services where I need stateless verification — short-lived access, a revocation story for refresh, never secrets in the payload.

Why it works: Exactly. Browsers + cookies + rotation is still the safest first-party web setup. JWTs are a tool for distributed APIs, not a personality.

• Browser apps: HttpOnly session cookies first.
• JWTs: short-lived, for APIs that must verify without a lookup.
• Plan revocation either way.
• Never put secrets or hashes in a JWT.

Why does a security team care about DNS, both as a control and as evidence?

The strongest answer: As a control it can refuse to resolve known-bad or newly registered domains, so the connection never happens; as evidence, resolver logs show which host asked for what, which is often the first thread in an investigation

Why it works: Right — cheap prevention plus a per-host trail that survives even when the payload itself is encrypted.

• DNS is control and evidence.
• Refuse to resolve known bad.
• Keep and actually read resolver logs.
• Look for odd lookup patterns.

Multi-AZ database and a read replica — what does each give you?

The strongest answer: Multi-AZ is a synchronous standby for availability — automatic failover, no extra read capacity; a read replica is asynchronous and serves reads, scaling read load but not a failover target without lag

Why it works: Right. Availability versus read scale; they are often used together.

• Multi-AZ: synchronous standby, failover.
• Read replica: async, serves reads.
• Replica lag makes it a poor failover.
• Use both for availability and read scale.

How do you keep threat models from rotting after the launch review?

The strongest answer: Store them next to the service, update on auth or data-shape change, and let a PR lint ask “did you touch the model?” — not a SharePoint museum

Why it works: Exactly. A living note beside the code. Museums and slides are where models go to die.

• Keep the model with the service.
• Update on auth / data change.
• Lint the question.
• No SharePoint museums.

The business asks for a disaster recovery plan. What two numbers do you ask for first, and why?

The strongest answer: RPO — how much data loss is acceptable — and RTO — how long the service may be down; together they decide whether backups, a warm standby or an active second region is the right answer, and what it costs

Why it works: Right. Every DR design is a point on the RPO/RTO/cost triangle; get the two numbers before the architecture.

• RPO: acceptable data loss.
• RTO: acceptable downtime.
• They pick backup, warm standby or active-active.
• Cost rises steeply as both approach zero.

What makes a pentest program, not a PDF you buy once a year?

The strongest answer: A scope that matches the money path, time to fix, and a retest — plus an owner for each finding, not a trophy in a drawer

Why it works: Exactly. Scope, fix, retest, owners. Audit-week theatre and trophy PDFs are not a program.

• Scope the money path.
• Time to fix + retest.
• Named owners.
• Do not buy a trophy PDF.

One customer asks for ISO 27001 and another asks for SOC 2. What is the difference, and what does each ask of engineering?

The strongest answer: ISO 27001 certifies a management system — scope, risk assessment, controls, continual improvement; SOC 2 is an auditor’s report on whether controls met the trust criteria, usually across a period. Both want evidence that controls actually ran

Why it works: Right — and the engineering cost is the same in both: evidence the system produces, not screenshots gathered in a rush.

• ISO certifies a system; SOC 2 reports.
• Both want evidence over time.
• Map controls once, reuse evidence.
• Automate evidence, not screenshots.

Active-passive versus active-active across regions — what does active-active cost you beyond money?

The strongest answer: Data consistency: two regions taking writes means conflict resolution, replication lag and a data model that tolerates both, so active-active is a design constraint on the application, not only a bigger bill

Why it works: Right. The hard part is the data; the compute is the easy part.

• Active-active means writes in two places.
• Conflict resolution and lag are yours.
• Design the data model for it.
• Active-passive keeps one truth.

Finance wants USB drives blocked after a lost stick; three engineering teams say they need them for lab equipment.

How do you land a device-control policy that survives?

The strongest answer: Default block with a real exception path — allow specified device classes on named machines, require encryption where data is written, log the use, and review the exception list on a schedule

Why it works: Exactly — default deny with a usable exception path and an expiry is what stops the control being switched off in month two.

• Default deny, real exception path.
• Allow device classes, not everything.
• Encrypt and log what is written.
• Expire and review the exceptions.

A customer requires their data to stay in the EU. What does that change in your design?

The strongest answer: Every store, backup, log and replica that holds their data must be in EU regions, including where support tooling and analytics copies land; you prove it with region-restricted policies, not with promises

Why it works: Right. Residency is the whole data path, and policy is how you enforce it.

• Residency covers every copy: backups, logs, replicas.
• Restrict regions by policy.
• Analytics exports are the usual leak.
• Prove it, do not promise it.

You have 200 Highs in the scanner. How do you pick this week’s work?

The strongest answer: Internet-facing, known exploit, and data class — I will not pretend all Highs are equal or hide the queue

Why it works: Exactly. Exposure and exploitability. Mass-accept is a lie with a timestamp.

• Face the internet first.
• Known exploits next.
• Data class matters.
• Do not mass-accept.

Design a consumer for an event stream that must not lose events and must not stall on one bad event.

The strongest answer: Retry with backoff a bounded number of times, then move the event to a dead-letter queue with the error, alert on the DLQ depth and build a way to replay from it after the fix

Why it works: Right. Bounded retries, a DLQ that is monitored, and a replay path — losing nothing and blocking nothing.

• Bounded retries with backoff.
• Dead-letter queue for the rest.
• Alert on DLQ depth.
• Replay after the fix.

How do detections survive a noisy week?

The strongest answer: Detections as code: review, test on known-good and known-bad, and an owner — a GUI full of unsigned rules is folklore

Why it works: Exactly. Same discipline as product code. News-driven piles and private notebooks fail the next holiday.

• Review and test detections.
• Name an owner.
• Do not pile rules from the news.
• Do not turn the SIEM off.

At 2am you are asked one question about a suspected compromise of a web application: did they get in, and what did they reach?

Which logs do you want, and in what order?

The strongest answer: Authentication and session events first, then application access logs for that account, then outbound network and database query logs — a timeline around one identity rather than reading everything

Why it works: Right — an identity-anchored timeline answers both halves of the question and shows what you cannot yet prove.

• Anchor on one identity.
• Authentication, then access, then egress.
• Build a timeline, not a pile.
• Write down what stays unproven.

A vendor promises exactly-once delivery. How do you design around that claim?

The strongest answer: Assume at least once and make every handler idempotent — the only exactly-once that holds end to end is the one your own deduplication and idempotent writes create

Why it works: Right. Exactly once is an end-to-end property you build, whatever the transport says.

• Assume at least once.
• Idempotent handlers, deduplicate by key.
• Exactly once ends at the vendor's boundary.
• Your writes make it exactly once.

You are asked for a two-year security strategy. What are the first three pages?

The strongest answer: The risks you owe (identity, money, data), the paved road (SSO, secrets, patches), and the evidence you will show — not a tool catalogue

Why it works: Exactly. Risks, road, evidence. Tools and empire are appendices.

• Name the risks you owe.
• Describe the paved road.
• Say what evidence you will emit.
• Put tools in the back.

You are asked to make a payments service active in two regions. What is the first design question?

The strongest answer: Which data must be strongly consistent and which can be eventually consistent — balances need one writer or a consensus store, receipts can replicate later; that split decides the architecture and most of the cost

Why it works: Right. Sort the data by consistency need first; everything follows from that.

• Classify data by consistency requirement.
• One writer or consensus for the strongly consistent part.
• Eventual replication for the rest.
• Cost follows the split.

What does an honest risk register refuse to do?

The strongest answer: Invent a precise “expected loss” you cannot defend, or hide a risk because it is embarrassing — it names owner, residual, and review date

Why it works: Exactly. Owners and residuals. Fake precision and hidden rows are how you lose the next incident review.

• Owner, residual, date.
• No invented precision.
• Do not hide embarrassing rows.
• Work happens off a living list.

EDR flags credential-dumping behaviour on the laptop of a finance director, an hour before the quarterly close.

Isolating the host stops their work. How do you make that call, and how do you own it?

The strongest answer: Isolate — credential theft spreads while we debate — then work an alternative path for the close with their team, and rely on a standing rule that says who may isolate so the authority is not invented in the moment

Why it works: Right — pre-agreed authority is what makes a fast containment decision defensible the next morning.

• Contain first on credential theft.
• Pre-agree who may isolate.
• Offer a continuity path.
• Record the call and the time.

What is a cell-based architecture and when is it worth the complexity?

The strongest answer: Running many small, independent copies of the whole stack, each serving a slice of customers, so a failure or a bad deploy hurts one cell rather than everyone; worth it once a single shared stack's blast radius is the biggest risk you have

Why it works: Right. Blast radius is the product; complexity is the price.

• Many independent full-stack copies.
• Customers routed to a cell.
• Failure contained to one cell.
• Adopt when blast radius is the top risk.

How does AppSec scale past a heroic reviewer?

The strongest answer: Libraries, lints, and default-safe frameworks — the reviewer becomes a teacher of the road, not a gate on every PR

Why it works: Exactly. Leverage is the job. Hero review does not survive 40 squads.

• Ship default-safe paths.
• Lint the dangerous ones.
• Teach, do not bottleneck.
• Vendors are extra, not the memory.

Your DR runbook is a document. How do you make it real?

The strongest answer: Run it: scheduled game days where the team fails over to the secondary using only the runbook, timed against the RTO, with every gap fixed and the runbook updated afterwards; automate the steps that keep failing

Why it works: Right. A runbook that has not been run is a story.

• Execute the runbook on a schedule.
• Time it against RTO.
• Fix and update after every run.
• Automate the flaky steps.

The interviewer asks: “A user asks us to delete their data. What does a backend actually do?” Strongest answer?

The strongest answer: A tested erasure path: production data, backups/retention windows we have documented, search indexes, logs we can justify, and derived stores. I don't promise 'everywhere' if backups are immutable — I state the policy we actually run.

Why it works: Exactly. Deletion is a product+legal design: what we erase, what we anonymise, how long backups last. Engineering implements that policy and can demonstrate it.

• Erasure is a designed path, not a DELETE.
• Inventory every store, including logs.
• Document backup windows honestly.
• Append-only still needs a PII story.

How do you treat the SOC like a product?

The strongest answer: Users (analysts), SLOs (time-to-triage, true-positive rate), and a backlog of detections — not a room that only grows seats

Why it works: Exactly. SLO and backlog. Seats and magic AI without tuning are how queues die.

• SLO: triage time and precision.
• A detection backlog.
• Seats last.
• Do not reward dismissals.

Sixty accounts, many teams. How do you stop anyone disabling logging or leaving approved regions?

The strongest answer: Organisation-level policies that deny those actions everywhere, applied above the accounts so even an account admin cannot undo them, with exceptions granted deliberately and audited

Why it works: Right. Guardrails above the account cannot be removed from inside it.

• Deny at the organisation level.
• Account admins cannot undo it.
• Cover logging, regions, key deletion.
• Exceptions are explicit and audited.

You are asked to fund a threat-intelligence function. What must it produce for you to keep paying for it?

The strongest answer: Decisions we would not otherwise make — which detections to write, which assets to harden first, which supplier to question — tied to threats that plausibly target our sector and our stack

Why it works: Right — intelligence is judged by the decisions it changes, not by the volume of reporting.

• Judge intel by decisions changed.
• Tie reporting to our own stack.
• Every report names an action.
• News is not intelligence.

How do you stop compliance from becoming a second company?

The strongest answer: Map every ask to a running control and reuse the artefact — auditors see what operators see, not a parallel universe of screenshots

Why it works: Exactly. One system of record. Binders and disconnected GRC are a second company.

• One running control per ask.
• Reuse operator artefacts.
• No binder company.
• GRC must connect.