Cybersecurity Engineer Top 100 Interview Questions

Confidentiality, integrity and availability are the three properties security protects: data is seen only by the right people, changed only in authorized ways, and reachable when it is needed. Almost every attack harms at least one of them, so the triad is a quick way to reason about impact.

How to use it in practice:

• Rate an incident's impact on each property separately. Ransomware hits availability, and often confidentiality too when data is copied out before encryption.
• Watch for controls that trade one property for another. Strong encryption with no key backup protects confidentiality but can destroy availability.
• Many teams add authenticity (who sent it) and non-repudiation (the sender cannot deny it) as companion properties.

Interview tip: when you describe any control, say which of the three properties it protects; it shows you think in terms of impact rather than tools.

A vulnerability is a weakness, a threat is something that could exploit it, and risk is the likelihood and impact of that happening. A risk exists only where a threat can reach a vulnerability in an asset that matters.

Ways to lower a risk:

• Remove the vulnerability: patch the server or fix the code.
• Cut the threat's access: take the service off the internet or put it behind authentication.
• Reduce the impact: encrypt the data, segment the network and keep tested backups.

A simple working model is risk = likelihood × impact. It explains why a severe flaw on an isolated test machine can matter less than a moderate flaw on an internet-facing payment system.

Defense in depth means layering independent controls so that a single failure does not become a breach. Each layer assumes the one in front of it can be bypassed.

What makes the layers effective:

• They fail in different ways. Two filters that use the same pattern list are one layer, not two.
• Each layer is owned and tested, not assumed. A firewall rule nobody reviews decays over time.
• Detection sits behind prevention, because prevention eventually fails.
• Layers cost money and add friction, so the deepest stack belongs in front of the most valuable data.

Least privilege gives every person and system only the access needed for its task, for only as long as it is needed. Separation of duties splits sensitive actions so that no single person can complete them alone.

Least privilege

• Grant access through roles or groups, not to individuals one by one.
• Use just-in-time elevation for administrative work: access is requested, approved, time-limited and logged.
• Give each service its own account, scoped to the exact resources it uses.
• Review access regularly and remove what has not been used.

Separation of duties

• The developer who writes a change should not be the only approver who releases it to production.
• The person who adds a new supplier should not also be able to approve payments to that supplier.
• Emergency "break-glass" accounts exist, but their use triggers an alert and a review.

Both principles limit the blast radius of a stolen account, an insider or a simple mistake. The trade-off is friction, so automate requests and approvals to keep work moving.

Controls are grouped by when they act: preventive controls stop an incident, detective controls notice one, and corrective controls limit the damage and restore normal service. A sound program uses all three, because prevention alone eventually fails.

Controls are also classed by form:

• Administrative: policies, training and background checks.
• Technical: encryption, access control and logging.
• Physical: locks, badges and cameras.

When you assess a risk, check that it has at least one control of each timing type. A risk covered only by preventive controls has no plan for the day they fail.

Annualized loss expectancy estimates how much a risk costs per year on average: the loss from one occurrence multiplied by how often it is expected to occur.

• SLE = asset value × exposure factor
• ALE = SLE × ARO

What each term means:

• Asset value: what the asset is worth, including recovery work, fines and lost revenue, not only its purchase price.
• Exposure factor: the share of that value lost in one incident, from 0 to 1.
• SLE (single loss expectancy): the cost of one occurrence.
• ARO (annualized rate of occurrence): expected occurrences per year; once every four years is 0.25.

When to use it: to compare a risk with the cost of controlling it. A control is worth buying when its yearly cost is lower than the reduction in ALE it brings.

The inputs are estimates, so present the result as a range and record the assumptions. Its main value is making a cost-versus-benefit discussion concrete.

Once a risk is assessed, an organization can avoid, mitigate, transfer or accept it. The choice depends on the risk's size, the cost of each option and the business value of the activity.

Points interviewers look for:

• Acceptance must be formal: a named business owner signs it, with a reason and an expiry date, and it is reviewed again.
• Transfer moves money, not accountability. Insurance can pay for recovery, but customers still blame the company that lost their data.
• After mitigation some residual risk always remains, and that residual risk is what gets accepted.
• Security teams advise; the business owner of the asset makes the final risk decision.

Zero trust is a security model in which no request is trusted because of where it comes from: every access is verified using identity, device health and context, and is granted only to the specific resource needed. Perimeter security, by contrast, trusts anything inside the corporate network.

Core principles:

• Verify explicitly: strong authentication plus device posture and risk signals.
• Least privilege: short-lived, narrowly scoped access.
• Assume breach: segment everything and monitor as if an attacker is already inside.

Zero trust is a strategy that is adopted step by step, usually starting with strong identity and the most sensitive applications. No single product delivers it on its own.

The attack surface is the sum of all the points where an attacker could try to get in or pull data out: exposed services, applications, APIs, accounts, devices and people. Every one of those points needs defending, so a smaller surface is easier to protect.

Parts of the surface:

• Digital: open ports, web applications, APIs, cloud storage, remote access services and third-party integrations.
• Human: staff who can be phished or tricked over the phone.
• Physical: offices, laptops and removable media.

How to reduce it:

1. Inventory first: discover every internet-facing asset, including forgotten test systems and old domains.
2. Remove what is not needed: unused services, ports, features, accounts and dependencies.
3. Hide what must exist: put admin interfaces and databases on private networks behind authentication.
4. Harden defaults: disable sample content, default credentials and verbose error messages.
5. Watch for change: scan the external surface continuously, because new exposure appears with every deployment.

Attack surface reduction is often the cheapest security win available. A service that is switched off cannot be exploited.

Threat modeling is a structured way to find what could go wrong in a design before it is built, and to decide what to do about it. It answers four questions: what are we building, what can go wrong, what will we do about it, and did we do a good job?

flowchart LR
  A["Draw the data flow"] --> B["Mark trust boundaries"]
  B --> C["List threats per element"]
  C --> D["Rate and prioritize"]
  D --> E["Choose mitigations"]
  E --> F["Track and verify"]

A common checklist for the "what can go wrong" step is STRIDE:

Running the session: bring a developer, a product owner and a security engineer; keep it to about an hour; and turn each accepted threat into a tracked work item with an owner.

They form a hierarchy from intent to instruction: a policy states what must be achieved, a standard sets specific mandatory requirements, a procedure gives the exact steps, and a guideline offers optional advice.

Why keep them separate:

• Policies change rarely and need executive approval, while standards change as technology changes. Mixing them makes every technical update a leadership decision.
• Auditors test against policies and standards, so they must be specific enough to check.
• Procedures let anyone on call perform a sensitive task the same, safe way.

Every standard should trace back to a policy, and every exception should be documented, approved and given an expiry date.

Data classification sorts information into a few levels by the harm its disclosure, alteration or loss would cause. Each level then comes with required controls, so people do not have to make security decisions file by file.

How to make it work:

1. Assign owners: each dataset has a business owner who decides its level.
2. Label it: tags on files, storage buckets and database tables so tools can apply rules automatically.
3. Tie controls to labels: encryption, access approvals, data loss prevention rules and retention follow the label.
4. Review it: data changes over time, and a combined dataset can be more sensitive than its parts.

Keep the scheme to three to five levels. More than that and people pick at random, which defeats the purpose.

Encoding changes data into another format so systems can handle it, encryption hides data so only key holders can read it, and hashing produces a fixed-size fingerprint that cannot be reversed. Only encryption and hashing are security tools, and they do different jobs.

Common mistakes:

• Treating Base64 as protection. Anyone can decode it in one step.
• Saying a hash can be "decrypted". It cannot be reversed; attackers guess inputs and compare hashes instead.
• Using a fast hash for passwords. Speed helps attackers guess billions of candidates per second, so passwords need a slow, salted algorithm.

Symmetric encryption uses one shared secret key to encrypt and decrypt, and it is fast. Asymmetric encryption uses a key pair, a public key that anyone can have and a private key that stays secret, and it solves key distribution but is much slower.

Why systems combine them (hybrid encryption):

1. The two sides use asymmetric cryptography to agree on, or securely send, a fresh symmetric key.
2. All the actual data is then encrypted with that symmetric key.
3. The asymmetric keys also sign the exchange, so each side knows who it is talking to.

This gives the convenience of public keys with the speed of symmetric ciphers. Secure web connections, encrypted messaging and envelope encryption of stored data all work this way.

A secure hash function maps any input to a fixed-size output in a way that cannot be reversed, cannot be forced to collide, and changes completely when the input changes slightly.

• Preimage resistance: given a hash, it is infeasible to find any input that produces it.
• Second-preimage resistance: given one input, it is infeasible to find a different input with the same hash.
• Collision resistance: it is infeasible to find any two inputs with the same hash.
• Avalanche effect: changing one bit of input changes about half the output bits.
• Deterministic and fixed-size: the same input always gives the same output of the same length.

Which algorithms are safe: MD5 and SHA-1 have practical collision attacks, so they must not be used for signatures or certificates. SHA-256, SHA-512 and SHA-3 are current choices.

Being fast is a feature for file integrity checks but a weakness for passwords. Password storage needs a deliberately slow function with a salt, not a general-purpose hash.

Store passwords with a slow, salted, adaptive password-hashing function, never in plaintext and never with reversible encryption. The goal is that a stolen database gives attackers nothing they can use quickly.

1. Pick a password-hashing algorithm: Argon2id, scrypt, bcrypt or PBKDF2 with a high iteration count. General hashes such as SHA-256 alone are too fast.
2. Use a unique random salt per password, so identical passwords produce different hashes and precomputed tables are useless.
3. Tune the work factor so one hash takes a noticeable fraction of a second on your servers, and raise it as hardware improves.
4. Store the algorithm, parameters, salt and hash together, so old hashes can be upgraded when a user next logs in.
5. Compare in constant time to avoid leaking information through response timing.
6. Optionally add a pepper: a secret kept outside the database, such as in a key management service, so a database dump alone is not enough.

Pair storage with login protections: rate limiting, checks against known breached passwords and multi-factor authentication.

A message authentication code (MAC) is a short tag computed from a message and a shared secret key; anyone with the key can create or check it. A digital signature uses a private key to sign and a public key to verify, so anyone can check it but only the key owner can create it.

When to use which:

• Use a MAC between two parties that already share a secret, such as your server and a payment provider's webhook.
• Use a signature when many parties must verify without being able to forge, such as users checking a software update.
• Both prove integrity and origin. Neither hides the content; add encryption for that.

A digital signature binds a message to the holder of a private key: the signer hashes the message and signs the hash with the private key, and anyone can check the result with the matching public key.

1. Sign: the signer computes a hash of the message and creates a signature from that hash with the private key.
2. Send: the message travels with its signature, and usually with a certificate that holds the public key.
3. Verify: the receiver hashes the message it received and uses the public key to check the signature against that hash.
4. Decide: a valid signature means the message is unchanged and was signed with that private key.

sequenceDiagram
  participant S as Signer
  participant R as Receiver
  S->>S: Hash message and sign with private key
  S->>R: Message plus signature
  R->>R: Hash received message
  R->>R: Verify signature with public key
  R-->>S: Accept only if the check passes

What it does and does not give:

• Integrity: any change to the message makes verification fail.
• Non-repudiation: only the private key holder could have signed, provided the key was protected.
• No confidentiality: the message itself is readable unless it is also encrypted.
• Trust in the public key still has to come from somewhere, which is the job of certificates.

A certificate chain links a server's certificate to a root authority that the client already trusts. Each certificate is signed by the one above it, so verifying every signature up the chain proves the server's public key is genuine.

flowchart LR
  A["Root authority in the trust store"] -->|signs| B["Intermediate authority"]
  B -->|signs| C["Server certificate"]
  C -->|presented to| D["Client"]
  D -->|checks each signature up to| A

1. Root: a self-signed certificate shipped in the operating system or browser trust store, and kept offline by its owner.
2. Intermediate: signed by the root and used for day-to-day issuing, so the root key is rarely exposed.
3. Leaf: the server's own certificate, signed by the intermediate and naming the domain.
4. Validation: the client checks signatures, validity dates, the hostname, permitted key usage and revocation status.

Common failures in practice:

• The server sends only its leaf certificate and omits the intermediate, so some clients cannot build the chain.
• The certificate expired because renewal was manual.
• The hostname does not match, such as a certificate for the bare domain served on a subdomain.

Interview tip: mention that the server must send the intermediate certificates; a missing intermediate is one of the most common real-world certificate errors.

A TLS 1.3 handshake agrees on keys and authenticates the server in one round trip. Both sides contribute an ephemeral key share, derive the same session keys, and the server proves it owns its certificate.

sequenceDiagram
  participant C as Client
  participant S as Server
  C->>S: ClientHello with cipher suites and key share
  S->>C: ServerHello with its key share
  S->>C: Certificate and CertificateVerify, encrypted
  S->>C: Finished
  C->>C: Validate certificate chain and hostname
  C->>S: Finished
  C->>S: Encrypted application data

1. ClientHello: the client lists supported cipher suites and sends an ephemeral key share.
2. ServerHello: the server picks a suite and sends its own key share. Both sides now derive the handshake keys, so everything after this is encrypted.
3. Authentication: the server sends its certificate and signs the handshake transcript with its private key.
4. Finished messages: each side confirms the whole handshake was not altered.

What changed from older versions:

• Only ephemeral key exchange is allowed, so every session has forward secrecy.
• Weak ciphers and modes were removed; only authenticated encryption remains.
• An optional zero round-trip resumption sends data immediately, but that early data can be replayed, so it must be limited to safe, repeatable requests.