Cybersecurity Engineer Top 100 Interview Questions

Secure a public API by authenticating every caller, authorizing every object and field, validating every input against a schema, and limiting how much any one client can do.

• Authentication: use standard tokens, such as OAuth 2.0 access tokens with short lifetimes, and never put API keys or tokens in URLs, where they end up in logs.
• Object-level authorization: check on every endpoint that the caller may access this specific record, not just this endpoint.
• Property-level control: return only the fields the caller may see, and ignore or reject fields they may not set, which prevents mass assignment such as a user sending "role": "admin".
• Schema validation: enforce types, lengths and formats, and reject unknown fields.
• Rate limits and quotas per client, plus maximum page sizes, so scraping and abuse are bounded.
• Transport security: HTTPS only, with HSTS.
• Safe errors: consistent error formats without stack traces or internal details.
• Inventory: retire old API versions, because forgotten versions often lack newer protections.
• Logging and monitoring: record who accessed what, and alert on unusual patterns such as one token reading thousands of records.

Treat the API specification as a security contract, and test it automatically with authorization tests for every endpoint.

A race condition vulnerability occurs when the result depends on the timing of concurrent requests, so an attacker sending many requests at once can slip between a check and the action that relies on it. This is often called time-of-check to time-of-use.

Typical targets:

• Redeeming a gift card, coupon or referral bonus more than once.
• Withdrawing more money than an account holds.
• Exceeding limits such as "one vote per user" or a rate limit counted in application memory.

How to prevent it:

1. Make check and update atomic: a single conditional statement such as UPDATE cards SET balance = balance - 50 WHERE id = ? AND balance >= 50, then confirm one row was changed.
2. Lock the record for the duration of the operation, using a row lock inside a transaction.
3. Use unique constraints in the database for "only once" rules, so a second insert fails.
4. Use idempotency keys so a retried request returns the original result instead of repeating the action.
5. Test concurrency deliberately by sending dozens of identical requests in parallel against a test environment.

Checks done only in application memory break as soon as the service runs on more than one server.

They test different things at different stages. SAST reads source code, DAST attacks the running application from outside, IAST watches the application from inside while it runs, and software composition analysis checks third-party dependencies for known vulnerabilities.

How they fit together:

• Run composition analysis and secret scanning on every build; they are fast and catch common real-world causes of breaches.
• Run SAST on pull requests with rules tuned to keep noise low.
• Run DAST on staging builds and on a schedule.
• Use IAST where good automated tests exist.
• No tool finds business logic flaws such as broken authorization. Those still need threat modeling, code review and manual testing.

Add a security activity to every phase, automate the repeatable checks in the pipeline, and save expert manual effort for the riskiest changes.

flowchart LR
  A["Requirements: security and abuse cases"] --> B["Design: threat modeling"]
  B --> C["Build: secure coding and peer review"]
  C --> D["Pipeline: code, dependency and secret scans"]
  D --> E["Test: dynamic scans and pen tests for high risk"]
  E --> F["Release: signed artifacts, hardened configuration"]
  F --> G["Operate: monitoring and vulnerability management"]
  G -->|lessons and new risks| A

1. Requirements: add security requirements and abuse cases alongside user stories.
2. Design: threat model new features and architecture changes.
3. Build: use secure coding standards and libraries that make the safe way the easy way.
4. Pipeline: run fast automated checks on every change, and block only on high-confidence findings.
5. Test: add dynamic scanning, and manual penetration tests for high-risk releases.
6. Release and operate: sign artifacts, harden configuration, monitor and feed incidents back into requirements.

What makes it work: a security champion in each team, clear severity-based fix timelines, and metrics such as time to fix rather than raw finding counts. Security that slows every release gets bypassed, so keep gates fast and focused.

Work out quickly whether you are actually exposed, reduce the risk with the fastest safe fix, and check whether anyone exploited it before you patched.

1. Find every use: search the dependency inventory or software bill of materials for the library and its versions, including copies bundled inside other packages and container images.
2. Assess exposure: is the vulnerable function reachable, and can untrusted input reach it? Internet-facing services come first.
3. Mitigate fast: upgrade to the fixed version. If no fix exists, disable the feature, change configuration, or add a filtering rule as a temporary virtual patch.
4. Ship through the normal pipeline, fast-tracked but still tested, so the emergency change does not cause an outage.
5. Verify by rescanning and confirming the deployed versions.
6. Hunt for exploitation: search logs from before the patch for attack patterns and unusual outbound connections.
7. Communicate status to stakeholders and, where required, to customers.

flowchart TD
  A["Vulnerability announced"] --> B["Search inventory for the library"]
  B --> C{"Used and reachable?"}
  C -->|no| D["Record and keep watching"]
  C -->|yes| E{"Fixed version available?"}
  E -->|yes| F["Upgrade and deploy"]
  E -->|no| G["Disable feature or add virtual patch"]
  F --> H["Verify and hunt for past exploitation"]
  G --> H

Trade-off: an emergency upgrade can break behavior, so rely on automated tests; a temporary filter buys time but is bypassable and must not become permanent.

Prevent sensitive data reaching logs at the source, then add a redaction layer as a safety net, because logs are copied widely and kept far longer than the data's owners expect.

At the source:

• Log events, not objects: write explicit fields such as user ID and order ID instead of dumping whole requests, headers or database rows.
• Mark sensitive fields in data models so that serializers omit or mask them automatically.
• Never log credentials: passwords, session cookies, authorization headers, API keys and one-time codes.
• Keep secrets out of URLs, because web servers and proxies log full URLs by default.

As a safety net:

1. Apply redaction patterns in the logging pipeline for known shapes: tokens, password= parameters, card numbers and email addresses.
2. Scan stored logs regularly for leaked secrets, and rotate anything found.
3. Restrict and expire logs: limit who can read them, and keep them only as long as needed.

Pattern-based redaction will always miss some formats. That is why it backs up careful logging rather than replacing it.

There is no perfectly safe place for tokens in a browser, so the choice is about which attacks each option exposes. For high-value applications, the strongest pattern keeps tokens on the server and gives the browser only an HttpOnly session cookie.

Guidelines:

• Never keep long-lived refresh tokens in storage that scripts can read.
• Keep access tokens short-lived and limited in scope, so a stolen one expires quickly.
• With cookies, set HttpOnly, Secure and SameSite, and add anti-forgery tokens for state-changing requests.
• Whatever the storage, cross-site scripting remains the root problem, because injected script can act as the user even when it cannot read the token.

Start from what the change does and where untrusted data enters, then follow that data to every sensitive operation it reaches. A focused review of trust boundaries finds more than reading every line equally.

1. Understand the change: what feature it adds, who can reach it, and what data it touches.
2. Find the inputs: request parameters, headers, files, messages and data from other services.
3. Follow each input to sinks: database queries, shell commands, file paths, templates, redirects and outbound requests. Check that each sink uses a safe API.
4. Check authorization: every new endpoint and action must verify the caller's rights to the specific object.
5. Look for secrets and sensitive data: credentials in code or tests, personal data in logs, and verbose errors.
6. Review security-relevant configuration: cross-origin rules, cookie flags, headers, permissions and feature flags.
7. Check cryptography and randomness: standard libraries only, secure random for tokens and no home-made schemes.
8. Check new dependencies: maintenance status, known vulnerabilities and whether they are really needed.
9. Ask for tests of the security behavior, such as a test proving another user's record returns 404.

Reviewers show their value through clear, actionable comments that explain the risk and suggest the fix, not just "this is insecure".

Vulnerability management is a continuous cycle: know your assets, find their weaknesses, decide what matters most, fix it, prove it is fixed, and report on how well the cycle is working.

flowchart LR
  A["Asset inventory"] --> B["Discover vulnerabilities"]
  B --> C["Assess and prioritize"]
  C --> D["Remediate or mitigate"]
  D --> E["Verify the fix"]
  E --> F["Report and improve"]
  F --> A

1. Asset inventory: servers, endpoints, cloud resources, containers, applications and their owners. Unknown assets are never scanned.
2. Discovery: authenticated scans, agent-based checks, dependency scanning and external surface monitoring.
3. Assessment: combine severity with exploitability, exposure and asset importance.
4. Remediation: patch, upgrade or reconfigure; mitigate where a fix is not possible; formally accept the rest with an expiry date.
5. Verification: rescan to confirm the fix, rather than trusting a closed ticket.
6. Reporting: track time to remediate by severity, the share of assets scanned, and overdue findings per team.

Set fix deadlines by priority, such as days for actively exploited internet-facing flaws and weeks for lower risks. Hold teams to them through regular reports to leadership.

Rank findings by real-world risk, not by severity score alone: combine how severe the flaw is with how likely it is to be exploited, how exposed the asset is, and how much the asset matters.

Factors to combine:

• Severity: the standard 0 to 10 score describes the flaw in general, not in your environment.
• Exploitation: is it being exploited in the wild, is public exploit code available, or is it only theoretical?
• Exposure: internet-facing, reachable from user networks, or isolated.
• Asset criticality: holds sensitive data, supports key business processes, or is a disposable test system.
• Compensating controls: a filtering rule or disabled feature lowers the urgency.

Making it manageable:

1. Group by fix: one upgrade or base image update often closes hundreds of findings.
2. Fix by owner: route findings to the team that owns the asset, with deadlines tied to priority.
3. Automate the scoring so a new finding is ranked on arrival.

A simple multiplicative score, such as priority = severity × exploitation × exposure × criticality, makes the ranking explicit and explainable. The exact weights matter less than applying them consistently.

They answer different questions. Scanning asks which known weaknesses exist, penetration testing asks how far a skilled tester can get through them, and red teaming asks whether the organization detects and stops a realistic attacker.

When to use which:

• Scanning is the baseline for every organization.
• Penetration tests suit new applications, major changes and compliance needs.
• Red teaming pays off once basics are solid and a detection team exists to be tested; earlier, it mainly confirms gaps you already know about.
• Purple teaming runs attacks openly alongside defenders to improve detections step by step.

A penetration test moves from agreeing what may be tested, through finding and exploiting weaknesses, to a report that helps the organization fix them, with permission and scope governing every step.

flowchart LR
  A["Pre-engagement: scope and rules"] --> B["Reconnaissance"]
  B --> C["Scanning and enumeration"]
  C --> D["Exploitation"]
  D --> E["Post-exploitation"]
  E --> F["Reporting"]
  F --> G["Retest after fixes"]

1. Pre-engagement: agree on scope, timing, permitted techniques, contacts and written authorization.
2. Reconnaissance: gather public information about domains, staff, technologies and exposed services.
3. Scanning and enumeration: identify live hosts, open ports, service versions, user accounts and application endpoints.
4. Exploitation: use vulnerabilities to gain access, choosing safe techniques that avoid damaging production systems.
5. Post-exploitation: show impact by escalating privileges, moving laterally or reaching agreed target data, then clean up any test artifacts.
6. Reporting: an executive summary, then each finding with evidence, risk rating, reproduction steps and remediation advice.
7. Retest: confirm that the fixes work.

The report is the product. A brilliant attack chain is wasted if developers cannot reproduce and fix what was found.

Rules of engagement are the written agreement that makes a penetration test legal, safe and useful. They define exactly what may be tested, how, when, and what happens if something goes wrong.

• Written authorization from someone who has the authority to approve testing of each system, including permission from any hosting or cloud provider where their terms require it.
• Scope: the in-scope addresses, domains, applications and accounts, and an explicit list of what is out of scope.
• Timing: testing windows and blackout periods, such as month-end processing.
• Permitted techniques: whether social engineering, physical access, denial-of-service testing or production data changes are allowed.
• Data handling: how sensitive data found during testing is treated, stored and destroyed.
• Communication: named contacts on both sides, how to report a critical finding immediately, and an emergency stop procedure.
• Credentials and access: which test accounts are provided and what level of prior knowledge the testers get.
• Deliverables: report format, delivery date and retest terms.

Without signed authorization, testing someone's systems is an attack, regardless of intent. That is why testers verify scope and permission before sending a single packet.

Make it easy to report, respond quickly and respectfully, fix the issue, and publish the outcome together with the researcher. This is called coordinated disclosure.

1. Publish a reporting channel: a security contact address, a security.txt file on the website and a disclosure policy that says what is in scope.
2. Acknowledge quickly, within a few working days, and assign a case owner.
3. Triage: reproduce the issue, rate its severity and identify affected versions and customers.
4. Agree a timeline: many programs work to about 90 days for a fix and public disclosure, shortened when the flaw is being exploited.
5. Fix and verify, and where possible let the researcher confirm the fix.
6. Disclose: publish an advisory, notify affected customers and credit the researcher if they want credit.
7. Offer safe harbor: state that good-faith research within the policy will not face legal action.

What not to do: ignore the report, threaten the researcher, or quietly fix it without telling affected users. Each pushes researchers toward public disclosure without warning, which is worse for everyone.

Interview tip: mention safe harbor and a published contact; they show you see researchers as allies who find flaws before criminals do.

Social engineering manipulates people into giving access, information or money, exploiting trust, urgency, fear and helpfulness instead of technical flaws. It is a leading cause of breaches because a convincing message can bypass many technical controls.

Defenses:

• Phishing-resistant multi-factor authentication, which removes the value of stolen passwords.
• Verification procedures using a known channel for payment changes and password resets.
• Regular, realistic training that rewards reporting, plus a one-click report button.
• Email authentication, link scanning and external-sender warnings.
• A culture where questioning an unusual request from a senior person is expected, not punished.

A security operations center monitors an organization's systems around the clock, investigates suspicious activity and coordinates the response to incidents. Its work is usually split into tiers, so routine alerts are handled quickly and experts focus on the hardest cases.

What makes a center effective:

• Playbooks for common alert types, so triage is consistent across shifts.
• Automation for enrichment and simple responses, such as disabling an account or isolating a host.
• Feedback loops: every false positive is a tuning task, and every incident becomes a new or better detection.
• Metrics such as time to detect, time to respond and the false positive rate per rule.

Many organizations outsource part of this work to a managed service, but they still need people in-house who understand the business and can make containment decisions.

A security information and event management system collects logs from across the organization, normalizes them into common fields, correlates events, raises alerts and keeps a searchable history for investigations. Its value depends almost entirely on which logs feed it and how well its rules are tuned.

Practical points:

• Start with identity, endpoint and cloud audit logs; most investigations need them first.
• Volume costs money, so filter noisy, low-value logs at the source rather than storing everything.
• Keep enough history: many intrusions are found weeks or months later, so retention must cover that period.
• Check log health: a source that silently stops sending is a blind spot, so alert on missing data too.

Tune detections with data: measure each rule's precision, add context that separates benign from malicious activity, and check that the tuned rule still catches known attacks before deploying it.

1. Measure per rule: how many alerts it raises, how many were true incidents, and how long each takes to triage.
2. Find the benign pattern: a backup job, a scanner or an admin tool that explains most false alerts.
3. Narrow precisely: exclude that specific account, host and command, not a whole category of activity.
4. Add context: combine signals, such as "rare process and outbound connection and new for this host".
5. Replay known attacks: run the tuned rule against past incidents and attack simulations to confirm it still fires.
6. Review exclusions regularly, because attackers deliberately hide inside allowlisted tools and accounts.

Useful measures:

• precision = true alerts / all alerts
• Analyst hours per week a rule consumes.
• Detection coverage: the share of simulated attack techniques that at least one rule catches.

Lowering a rule's sensitivity is the last resort, not the first. It cuts noise and real detections together.

Indicators of compromise are artifacts left by a known attack, such as a malicious file hash or command server address. Indicators of attack describe behavior that shows an attack is under way, whatever tools are used, such as a document spawning a command shell.

When to use which:

• Use compromise indicators to sweep the environment quickly after an incident or a threat report, and to block known-bad infrastructure.
• Build most detections on attack behavior, because changing a file hash costs an attacker seconds, while changing how they steal credentials costs weeks.
• Combine both: behavior-based alerts find the intrusion, and the indicators collected from it let you scope it across every host.

Most intrusions follow a recognizable sequence: the attacker learns about the target, gets in, establishes a foothold, expands access, and then achieves the goal, such as stealing data or encrypting systems. Defenders who map their detections to these stages can stop an attack at several points.

flowchart LR
  A["Reconnaissance"] --> B["Initial access"]
  B --> C["Execution and persistence"]
  C --> D["Privilege escalation"]
  D --> E["Credential access"]
  E --> F["Lateral movement"]
  F --> G["Collection"]
  G --> H["Exfiltration or impact"]

1. Reconnaissance: public information about staff, domains and exposed services.
2. Initial access: phishing, stolen credentials or an exploited internet-facing system.
3. Execution and persistence: running tools and making sure access survives a reboot.
4. Privilege escalation and credential access: gaining admin rights and harvesting more passwords and tokens.
5. Lateral movement: using those credentials to reach other systems.
6. Collection, exfiltration or impact: gathering data, sending it out, or encrypting and destroying systems.

Why it is useful: an attacker must succeed at every stage, while defenders need to catch only one. Detections in the middle stages, such as credential theft and lateral movement, often give the best chance, because they happen inside your own environment where you have the most visibility.