Cybersecurity Engineer Top 100 Interview Questions

Traditional antivirus mainly blocks known malicious files by matching signatures. Endpoint detection and response records detailed activity on each device, detects suspicious behavior, and gives responders tools to investigate and act remotely.

When each fits:

• Antivirus is still a useful baseline layer that stops known commodity malware cheaply.
• Detection and response tools are expected wherever a security team investigates incidents, because they answer "what happened on this machine?" in minutes.
• Their value depends on people and process: unmonitored alerts protect nothing, so many smaller organizations use a managed detection service.

Malware is classified by how it spreads and what it does once installed. Real samples often combine several types, such as a trojan that installs ransomware.

Defensive takeaways:

• Behavior-based endpoint detection matters because file signatures miss fileless and newly changed samples.
• Information stealers are now a common first step: stolen session cookies can bypass multi-factor authentication, so short session lifetimes and device binding matter.
• Patch quickly to stop worms, and restrict who can install software to stop trojans.
• Back up data to immutable storage, so ransomware cannot also destroy the way back.

Check who really sent it, where its links and attachments lead, and whether anyone else received or clicked it, without opening anything on your own workstation.

1. Read the headers: compare the visible sender with the actual sending domain and the Reply-To address, and trace the receiving servers.
2. Check authentication results: SPF says whether the sending server was allowed to send for the domain, DKIM proves the message was signed by the domain, and DMARC says whether those match the visible From domain.
3. Inspect links without clicking: look at the real destination behind each link, the domain's age and reputation, and any redirects. Open it only in an isolated sandbox.
4. Inspect attachments safely: get the file hash, check reputation, and run it in a sandbox. HTML attachments, archives and documents with macros are red flags.
5. Judge the content: urgency, payment changes, credential requests and unusual tone.
6. Scope: search the mail system for other recipients, and the proxy logs for anyone who visited the link.
7. Respond: remove the message from all mailboxes, block the sender and domains, and reset credentials for anyone who submitted them.

Passing SPF, DKIM and DMARC proves only that the email came from the domain it claims. Attackers register look-alike domains and authenticate them perfectly.

Lateral movement uses valid credentials and built-in admin tools, so it is detected by unusual relationships, such as who logs in where, from where and how, rather than by malware signatures.

What makes detection possible:

• Baselines of normal authentication paths per account and host group.
• Rich telemetry: authentication logs from servers and the directory, plus process and network data from endpoints.
• Deception: decoy accounts and credentials planted on hosts that should never be used. Any use of them is a high-confidence alert.

Prevention reduces the noise too. If admin accounts can log in only from dedicated admin workstations, any other source stands out immediately.

Parse each log line into a timestamp, outcome, user and source address, keep a sliding time window of failures per source, and alert when a source crosses a threshold. Also flag a success that follows several failures, which may mean the attacker got in.

Key points:

• Use a time window, not a total count: 5 failures in a minute is suspicious, 5 in a month is not.
• Count distinct usernames per source to tell password spraying, which tries many accounts, from someone mistyping their own password.
• Alert on success after failures, the most important outcome to catch.
• Parse strictly with a regular expression and skip lines that do not match, rather than guessing at fields.
• Process in time order; logs merged from several servers may arrive out of order.
• Slow attacks that stay under the threshold need a second, longer window, such as failures per source per day.

In production, the same logic usually runs as a rule in the log platform. Writing it once by hand shows exactly what the rule must do.

Threat hunting is a proactive search for attackers who have not triggered any alert, starting from a hypothesis about how they might operate. Alert-driven monitoring waits for rules to fire; hunting assumes some attacks slip past those rules.

A good hunt cycle:

1. Form a hypothesis from intelligence or a known gap, such as "attackers use scheduled tasks for persistence".
2. Gather the data needed to test it, over a meaningful period.
3. Analyze by grouping and stacking: rare values across the fleet are more interesting than common ones.
4. Investigate the outliers until each is explained.
5. Turn results into automation: every successful hunt should leave behind a new or improved detection rule.

Hunting also reveals missing logs. Finding that you cannot test a hypothesis is itself a valuable result.

Start from a specific attacker behavior, confirm you have the data to see it, write the rule, then test it against both malicious and normal activity before it reaches analysts.

flowchart LR
  A["Pick a behavior to detect"] --> B["Confirm the logs exist"]
  B --> C["Write the rule"]
  C --> D["Test on simulated attacks"]
  D --> E["Test on historical normal data"]
  E --> F{"Precise enough?"}
  F -->|no| C
  F -->|yes| G["Deploy with a triage playbook"]
  G --> H["Track alert outcomes"]

1. Define the behavior precisely, such as "a user granted admin rights outside an approved change".
2. Check data availability: which log records it, with which fields, and how quickly it arrives.
3. Write the rule with clear logic and comments explaining why it exists.
4. Test true positives by simulating the behavior in a test environment.
5. Test against history, running the rule over weeks of past data to estimate alert volume.
6. Write unit tests with sample events, so future changes cannot silently break the rule.
7. Ship it with a playbook that tells the analyst what to check and what to do.

Store rules in version control with reviews, like code. Detection rules break when log formats change, and tests catch that.

Threat intelligence is usually split into four types by its time horizon and audience: from long-term trends for leaders to machine-readable indicators for blocking tools.

What makes intelligence useful:

• Relevant: it concerns attackers who actually target your sector, regions and technologies.
• Timely: technical indicators lose value within days or weeks as attackers change infrastructure.
• Actionable: each report should lead to a decision, a detection, a hunt or a block.

Feeding thousands of generic indicators into a firewall creates false positives without much protection. Tactical intelligence about techniques usually improves detection more than raw indicator lists do.

Incident response follows a cycle: prepare before anything happens, detect and analyze, contain the damage, remove the cause, recover, and learn. Containment, eradication and recovery often repeat as the investigation finds more.

flowchart LR
  A["Preparation"] --> B["Detection and analysis"]
  B --> C["Containment"]
  C --> D["Eradication"]
  D --> E["Recovery"]
  E --> F["Post-incident review"]
  C -->|new findings| B
  F -->|improvements| A

1. Preparation: plans, playbooks, contacts, logging, tools, trained people and practice exercises.
2. Detection and analysis: confirm the incident, judge its severity, and work out scope and timeline.
3. Containment: stop the spread by isolating hosts, disabling accounts and blocking indicators, while preserving evidence.
4. Eradication: remove malware, persistence and attacker access, and fix the vulnerability that let them in.
5. Recovery: restore systems from clean sources, monitor closely, and return to normal operations in stages.
6. Post-incident review: a blameless review of what happened, what worked, and the improvements to make.

Running it well: name one incident lead, keep a timestamped log of actions, communicate on a regular schedule, and involve legal and communications early when data or customers are affected.

Interview tip: stress that preparation is a phase; most response failures trace back to missing logs, unclear authority or untested backups, all of which are fixed before an incident.

Contain ransomware by cutting its paths to spread, protecting backups and identity systems first, and preserving evidence, all while the scope is still being worked out.

1. Isolate affected hosts with endpoint tools or network controls. Keep them powered on if possible, since memory may hold keys and evidence.
2. Protect the backups: disconnect or lock backup systems and confirm that immutable copies are intact.
3. Stop lateral movement: block remote administration protocols between workstations, and segment critical servers.
4. Contain identity: reset passwords of compromised accounts, especially admins and service accounts. Invalidate sessions and tokens too, since attackers often hold them.
5. Block attacker infrastructure: command servers, file-sharing sites and tools seen in the attack.
6. Find the scope and entry point: which accounts and hosts were used, and whether data was stolen before encryption.
7. Engage the right people: leadership, legal, insurers, and law enforcement where appropriate. Use an out-of-band channel if email or chat may be compromised.

Containment is a trade-off between speed and disruption. Pulling the internet connection stops the spread quickly but also stops the business, so decide in advance who has the authority to do it.

The order of volatility tells investigators to collect the most short-lived evidence first, because it disappears soonest. Memory and network state vanish on reboot, while disks and backups last much longer.

Practical consequences:

• Do not switch off a compromised machine by reflex. Capture memory first when the incident justifies it, because fileless malware and encryption keys may exist only there.
• Record everything you do, since every action on a live system changes it a little.
• Image disks with write protection and hash the images, then analyze copies, never the originals.
• Secure remote logs early; attackers often delete local logs, and retention limits erase central ones over time.

Chain of custody is the documented record of who collected each piece of evidence, how, when, where it was stored and everyone who handled it afterwards. It proves the evidence presented later is exactly what was collected and has not been altered.

What a good chain of custody includes:

• Identification: what the item is, such as a laptop serial number or a disk image file name.
• Collection details: who collected it, when, where and with which tool.
• Integrity proof: a cryptographic hash taken at collection and checked again at every transfer.
• Secure storage: sealed, labeled evidence bags for devices, and access-controlled storage for images.
• A transfer log: every hand-off, signed and timestamped, with the reason.
• Working copies: analysis is done on verified copies; the original stays untouched.

Why it matters:

• Evidence with gaps in its record may be rejected in court or in disciplinary hearings.
• Insurers, regulators and law enforcement may rely on the findings.
• It protects investigators from claims that they planted or changed evidence.

Treat any serious incident as if it could end up in court. Adding a proper chain of custody afterwards is impossible.

Assume the attacker has already used them: lock the account down, remove every session and access path the attacker may have created, then check what they did with it.

1. Reset the password and require re-enrollment of multi-factor authentication if the method may have been captured.
2. Revoke all sessions and tokens, including refresh tokens and app passwords; a password reset alone does not end an existing session.
3. Look for persistence: new multi-factor devices, mailbox forwarding rules, app consents, API keys and recovery addresses added by the attacker.
4. Review activity since the phishing time: sign-ins, locations, file downloads, emails sent and admin actions.
5. Scope the campaign: find other recipients, block the phishing domain, and check proxy logs for other users who submitted credentials.
6. Contain onward abuse: if the account sent phishing internally or to customers, warn them and remove those messages.
7. Learn: move the user, and ideally everyone, to phishing-resistant authentication.

flowchart TD
  A["Credential phish reported"] --> B["Reset password and revoke sessions"]
  B --> C["Remove attacker persistence"]
  C --> D["Review account activity"]
  D --> E{"Signs of misuse?"}
  E -->|no| F["Close with user follow-up"]
  E -->|yes| G["Escalate to full incident response"]
  G --> H["Notify affected parties"]

Ransomware groups deliberately find and destroy backups before encrypting anything else. Backups must therefore be isolated from the production environment, impossible to change for a set period, and proven to restore quickly.

• Keep multiple copies: at least three copies of data, on two kinds of storage, with one off-site. Make at least one copy immutable or offline.
• Make them immutable: object locking or write-once storage that even an administrator cannot delete before the retention period ends.
• Separate identity: backup systems use their own accounts and multi-factor authentication, not the main directory, so stolen domain admin credentials cannot reach them.
• Retain long enough: attackers often wait weeks before encrypting, so keep restore points older than the likely dwell time.
• Protect the backup configuration itself, and alert on retention changes and mass deletions.
• Test restores regularly, including a full rebuild of a critical system, and measure how long it takes.
• Back up what recovery needs: identity services, configuration and infrastructure code, not only data.

A backup that has never been restored is a hope, not a plan.

Measure outcomes and speed, not activity: how quickly threats are found and fixed, how much of the environment is covered, and whether risk is going down over time. A count of blocked attacks or completed trainings says little on its own.

How to use metrics well:

• Track trends over quarters rather than single values.
• Use medians for time-based measures, since one long incident distorts an average.
• Tie metrics to risk: a quarterly report should show which top risks were reduced, not only which numbers moved.
• Beware incentives: if teams are judged on ticket counts, they will close tickets rather than fix problems.

Prevent public exposure with account-wide guardrails and secure defaults, then detect the remaining mistakes quickly with continuous configuration checks and access monitoring.

Prevention:

1. Block public access at the account or organization level, so a single bucket policy cannot make data public by accident.
2. Deploy storage through infrastructure code with policy checks in the pipeline that reject public or unencrypted configurations.
3. Use least-privilege access policies tied to roles, and avoid long-lived share links and wildcard principals.
4. Encrypt by default and turn on versioning and access logging for sensitive buckets.
5. Tag data with its classification, so stricter rules apply to sensitive stores automatically.

Detection:

• Posture management scans that flag public, unencrypted or unlogged storage within minutes.
• Alerts on policy changes, especially a change to public access or cross-account sharing.
• Access log analysis for unusual readers, large downloads or anonymous requests.
• External checks that look for your storage from the internet, as an attacker would.

When exposure is found, remove the public access first, then use the access logs to see whether anyone read the data, which decides whether it is a breach.

Hardening reduces a server to what it needs, secures what remains, and makes sure you will see what happens on it. Build the hardened state into an image and configuration code, so every server starts secure rather than being fixed by hand.

1. Start minimal: a minimal operating system install, with unused packages, services and features removed.
2. Patch fully before exposure, and enroll the server in automated patching.
3. Secure access: key-based remote login only, no direct root or administrator login, multi-factor authentication through a bastion or access proxy, and no shared accounts.
4. Remove defaults: default accounts, passwords, sample applications and verbose banners.
5. Restrict the network: a host firewall that allows only required ports and sources.
6. Run services with least privilege, each under its own account with only the file access it needs.
7. Apply a configuration baseline from a recognized hardening benchmark, and scan against it.
8. Enable logging and monitoring: send logs to the central platform, install the endpoint detection agent and sync time so timelines line up.
9. Encrypt disks and protect secrets with a secrets manager, never in local files.
10. Verify before go-live with a vulnerability scan and a configuration compliance check.

Immutable servers go further: they are never changed in place but replaced with a new hardened image. Configuration drift then has nowhere to accumulate.

Design it as layers around the data: protected entry points, strong identity, an application that enforces authorization on every request, private and encrypted data stores, and monitoring across all of them.

flowchart LR
  A["Users"] --> B["Edge: content delivery, web firewall, denial-of-service protection"]
  B --> C["Load balancer with TLS"]
  C --> D["Web and API tier in private subnets"]
  D --> E["Database, encrypted and private"]
  D --> F["Secrets manager"]
  G["Identity provider with multi-factor authentication"] --> D
  D --> H["Central logging and alerting"]
  I["Pipeline with code, dependency and secret scans"] --> D

Key decisions:

• Identity: a standard sign-in protocol with an identity provider, multi-factor authentication, secure session cookies and protected account recovery.
• Authorization: checks on every request against the object being accessed, enforced in a shared component.
• Input and output: schema validation on input, parameterized queries and context-aware output encoding.
• Data protection: TLS everywhere, encryption at rest with managed keys, and minimal collection of personal data.
• Network: only the edge is public; application and data tiers live on private networks with strict rules.
• Secrets: fetched at runtime from a secrets manager by workload identity, never stored in code.
• Operations: central logs, alerts on authentication and data access anomalies, and a tested incident plan.

Trade-offs: stricter controls add latency and development effort, so put the strongest controls around the most sensitive data and actions.

Tell it as a short story with a clear structure: the risk, what you did and why, what changed, and what you learned. Make your own contribution clear, and give numbers wherever you can.

1. Context: the system, the business, and the risk or incident that started the project.
2. Your role: what you personally owned, as distinct from the team's work.
3. The problem: what made it hard, such as legacy systems, conflicting priorities or limited budget.
4. Your decisions: the options you considered, the trade-offs, and why you chose your approach.
5. The result: measurable outcomes, such as "phishing-related account takeovers fell from six a quarter to zero" or "critical patch time dropped from 30 days to 5".
6. Lessons: what you would do differently, and what the team does differently now.

What the interviewer is listening for:

• Whether you understand why the work mattered to the business, not just which tools you used.
• Whether you can weigh security against usability, cost and delivery.
• Honesty about mistakes and limits, which signals maturity.
• Whether you can explain technical points simply.

Prepare two or three stories in advance, such as an incident, a hardening or detection project, and a time you influenced other teams. Practise telling each in about three minutes.

Make sure the owner truly understands the risk in business terms, offer practical options that reduce it, and if they still accept it, document the decision properly rather than blocking or quietly giving up.

1. Understand their goal: what deadline, revenue or customer need is driving the decision.
2. Explain the risk in their language: likely scenarios, impact on customers and revenue, and regulatory exposure, rather than technical severity scores.
3. Offer options, not a veto: a compensating control, a phased fix, a smaller launch, or extra monitoring until the fix ships.
4. Agree on facts: where you disagree, test assumptions together, such as whether the system really is unreachable from the internet.
5. Escalate through governance if the risk exceeds what this owner may accept, rather than going around them.
6. Document the acceptance: the named owner, the reasoning, conditions and an expiry date for review.
7. Follow up: check that the agreed controls are delivered, and revisit when the date arrives.

What the interviewer is listening for:

• That you see security as enabling the business, and the risk decision as belonging to the business owner.
• Influence without authority, and calm communication under pressure.
• That you hold firm on facts and process, not on personal preference.