Cybersecurity interview questions, and what they're really testing.

What they're testing: Whether you can connect theory to real events, not just recite three words.

• Confidentiality: only authorized people see data. Attack: a phishing-stolen password used to read email.
• Integrity: data isn't altered without authorization. Attack: an attacker changing payment details on an invoice.
• Availability: systems are up when needed. Attack: ransomware or a DDoS taking services offline.
• Bonus: mention that controls often trade these off (e.g. strict lockouts help confidentiality but can hurt availability).

Red flag: Listing the three words with no examples.

What they're testing: Precise vocabulary. GRC and SOC roles both use these words daily.

• Vulnerability: a weakness (an unpatched VPN appliance).
• Threat: something that could exploit it (a ransomware group scanning for that VPN).
• Risk: the likelihood and impact of the threat exploiting the vulnerability, which is what the business actually cares about.
• Tie it together: 'Patching reduces the vulnerability, which lowers the risk even though the threat still exists.'

What they're testing: Networking breadth and whether you can explain a process in order.

• DNS resolution: browser cache → OS → resolver → recursive lookup returns an IP.
• TCP three-way handshake (SYN, SYN-ACK, ACK) to port 443.
• TLS handshake: certificate validation, key exchange, encrypted session.
• HTTP request/response; the browser renders HTML and fetches more resources.
• Security angle: where things can go wrong (DNS spoofing, invalid certificates, phishing look-alike domains).

What they're testing: A frequent trick question. Many candidates mix these up.

• Encryption is reversible with a key; hashing is one-way.
• Passwords are hashed so that even the system can't recover them; you compare hashes at login.
• Good practice: a slow, salted algorithm (bcrypt, scrypt, Argon2), not plain MD5/SHA-1.
• Hashes are also used for integrity, e.g. comparing file hashes to known malware.

Red flag: Saying 'hashing is a type of encryption.'

What they're testing: Whether your knowledge is current. Interviewers love this one.

• Factors: something you know, have, or are. MFA combines two or more different categories.
• Not equal: SMS codes can be SIM-swapped; push notifications can be abused with 'MFA fatigue' spam; phishing-resistant methods (FIDO2 security keys, passkeys) are strongest.
• Mention that attackers increasingly steal session tokens after login, so MFA isn't the end of the story.

What they're testing: Curiosity and habits. It's asked in nearly every interview.

• Name 2–3 specific sources you actually use (e.g. CISA advisories and the KEV catalog, a podcast, a newsletter, vendor threat reports).
• Mention something recent you read and what you learned from it.
• Mention hands-on practice (labs, CTFs, your own projects).

Red flag: A vague 'I read articles' with no names or examples.

What they're testing: Whether you understand the job you're applying for.

• Monitor and triage alerts in a SIEM/EDR; decide true vs false positive.
• Investigate suspicious activity: phishing reports, unusual logins, malware detections.
• Document findings clearly and escalate per playbook; tune noisy detections.
• Mention shift handovers and writing tickets that the next person can act on.

What they're testing: Your process, the most important thing in a SOC interview.

• Understand the alert: what rule fired, on which host/user, and when.
• Gather context: is this user/host normal for this? Recent related alerts? Asset criticality?
• Validate: look at raw logs/evidence. Is it a true positive, benign true positive, or false positive?
• Scope: anything else affected? Act or escalate per playbook. Document everything.

Red flag: Jumping straight to 'I'd block the IP' with no investigation.

What they're testing: Phishing analysis, the most common SOC task.

• Get the original email as an attachment (with headers), not a forward.
• Analyze headers (sender, reply-to, SPF/DKIM/DMARC results), links (detonate safely or use reputation tools), attachments (hash + sandbox).
• Check if others received it; check if anyone clicked or entered credentials (proxy/sign-in logs).
• Contain: purge from mailboxes, block sender/URL, reset credentials if needed. Thank the reporter.

What they're testing: Investigation reasoning with ambiguity.

• Could be brute force / password spraying, or a user who forgot their password.
• Check: source IP and geolocation, time pattern (machine-fast?), other accounts targeted from the same source, MFA result, what happened after login.
• If suspicious: disable/reset the account, revoke sessions, block the source, scope other accounts.

What they're testing: Whether you understand the function.

• Governance: direction and accountability (policies, roles, oversight).
• Risk management: identifying, assessing and treating risks.
• Compliance: meeting legal, regulatory and contractual requirements, and proving it.
• They connect: governance sets risk appetite; risk drives controls; compliance proves controls work.

What they're testing: Framework literacy, and honesty about depth.

• NIST CSF 2.0: outcome-based, six functions (Govern, Identify, Protect, Detect, Respond, Recover). Widely used, not certifiable.
• ISO/IEC 27001: certifiable information security management system standard; Annex A controls.
• SOC 2: an attestation report (by a CPA firm) against the Trust Services Criteria, common for SaaS vendors.
• Sector-specific: HIPAA (health), PCI DSS (payment cards). Say which you've actually worked with.

What they're testing: Your method, the core of the job.

• Scope: system/process, assets, stakeholders.
• Identify threats and vulnerabilities; consider existing controls.
• Rate likelihood and impact → inherent and residual risk.
• Recommend treatment: mitigate, transfer, accept, avoid. Assign owners and dates; document in a risk register.

What they're testing: Third-party risk basics.

• An independent auditor's report on a service organization's controls against Trust Services Criteria (security plus optional availability, confidentiality, processing integrity, privacy).
• Type I: design at a point in time; Type II: operating effectiveness over a period.
• Read the scope, exceptions found, and complementary user entity controls (what you must do yourself).

What they're testing: The core IAM lifecycle.

• Joiner: provision access based on role on day one.
• Mover: adjust access when someone changes roles. Remove old access, not just add new.
• Leaver: disable promptly at departure; revoke sessions, tokens, and shared credentials.
• Most real breaches tied to IAM come from mover/leaver failures.

What they're testing: Protocol awareness.

• SSO: log in once, access many apps. Federation: trust between identity providers and apps/organizations.
• SAML 2.0 (XML, common in enterprise SSO), OpenID Connect (authentication on top of OAuth 2.0), OAuth 2.0 (authorization/delegated access).
• Benefit: central control and MFA; risk: the identity provider becomes a high-value target.

What they're testing: Practical governance.

• Pull current access per application; send to the right reviewers (usually managers or app owners).
• Reviewers certify or revoke; track completion; remove revoked access and verify it's gone.
• Watch for rubber-stamping; prioritize privileged and sensitive access.

What they're testing: Practical help-desk-to-IAM skills.

• Verify identity first (social engineering risk!).
• Check: account status (locked/disabled/expired), password expiry, MFA registration, conditional access blocks, group membership, sign-in logs for the exact error.
• Fix and document; if many users are affected, consider a broader outage.

Red flag: Resetting the password before verifying who's asking.

What they're testing: The single most-asked cloud security question.

• The provider secures the cloud (physical data centers, hardware, core infrastructure); the customer secures what they put in it.
• The split shifts by service model: IaaS (customer manages OS, apps, data), PaaS (less), SaaS (mostly data and access).
• Customers are always responsible for their data, identities and access configuration.

What they're testing: Realism about real-world risk.

• Misconfiguration (public storage buckets, open security groups).
• Identity problems: over-permissive roles, leaked access keys, no MFA on root/admin.
• Lack of logging/visibility; vulnerable exposed workloads.

What they're testing: Incident response in the cloud.

• Treat it as compromised: deactivate/rotate the key immediately (deleting the commit is not enough).
• Review logs for any use of the key since exposure; check for new resources/users created.
• Contain anything found; add secret scanning and pre-commit hooks to prevent recurrence.

Red flag: 'Delete the commit and we're fine.'

What they're testing: Risk-based thinking, the key question for this role.

• CVSS shows technical severity, but not the whole story.
• Add: is it actively exploited (CISA KEV catalog)? Likelihood of exploitation (EPSS)? Is the asset internet-facing or critical? Are there compensating controls?
• Result: an exploited medium on an internet-facing server can outrank a theoretical critical on an isolated test box.

Red flag: 'Always fix criticals first' with no context.

What they're testing: Vocabulary precision.

• CVE: a unique identifier for a publicly known vulnerability (e.g. CVE-2021-44228, Log4Shell).
• CVSS: a scoring system (0–10) for the severity of a vulnerability.

What they're testing: Practical judgment under overwhelm.

• Don't panic about the number. Deduplicate and group by root cause (often one missing patch = hundreds of findings).
• Prioritize exploited/internet-facing/critical-asset issues; find quick wins (one patch fixes many hosts).
• Work with asset owners on SLAs; track trend over time, not just the count.

What they're testing: The defining AI security concept.

• Crafted input that makes an LLM ignore its instructions or do something unintended.
• Direct (the user types it) vs indirect (hidden in content the model reads: a web page, document or email).
• Hard because models don't reliably separate instructions from data. So defenses limit impact: least-privilege tools, human confirmation for actions, output handling, monitoring.

What they're testing: Framework awareness.

• The 2025 list includes Prompt Injection, Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, Misinformation, and Unbounded Consumption.
• Explain one with an example, e.g. excessive agency: a chatbot that can send emails or issue refunds without human approval.

What they're testing: Understanding modern AI architecture.

• Retrieval-Augmented Generation: the app retrieves relevant documents and adds them to the prompt so the model can answer from company data.
• Risks: retrieval ignoring the user's permissions (data leakage), poisoned documents carrying indirect prompt injection, sensitive data sent to a third-party model.

What they're testing: AI governance basics.

• A voluntary framework to manage AI risks, built around four functions: Govern, Map, Measure, Manage.
• Defines characteristics of trustworthy AI (valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair with harmful bias managed).
• NIST also published a Generative AI Profile (NIST AI 600-1).

What they're testing: Prioritization, containment instinct and communication under pressure.

• Confirm quickly: look at the alert evidence (mass file renames, shadow copy deletion, ransom note).
• Contain: network-isolate the host via EDR immediately; disable the user's account sessions if credentials may be involved.
• Scope: check for the same behavior on other hosts and file shares; identify patient zero and initial access.
• Escalate per IR plan: notify the IR lead and management; preserve evidence; don't power off unless instructed (memory evidence).
• Communicate: short factual updates on a set schedule.

What they're testing: Credential compromise response.

• Reset the password and revoke active sessions/tokens; check MFA registration for newly added methods.
• Review sign-in logs for logins from the attacker; check mailbox rules (forwarding rules are a classic persistence trick) and sent items.
• Search for other recipients/clickers; block the URL/domain; educate the user without blame.

What they're testing: Applying IR to AI systems.

• Contain: disable the feature or remove the source documents from the index.
• Investigate: logs of the session, which document was retrieved, whether permissions were enforced at retrieval; search for similar retrievals.
• Involve privacy/HR/legal; fix permission-aware retrieval; re-test before re-enabling; update the threat model.

What they're testing: Your story in 60–90 seconds, and whether it points at this job.

• Present → past → future: what you do now, the relevant experience that led you here, why this role is the next logical step.
• Include one proof point (a project, a result).
• Career changers: frame your previous field as an asset ('In audit, I tested controls every day; now I want to do that for security controls').

Red flag: Reciting your whole resume chronologically.

What they're testing: Motivation and whether you researched the role.

• A genuine moment or reason (not just salary or 'it's in demand').
• Evidence you've pursued it: projects, study, labs.
• Something specific about this role or company (their industry, a tool they use, their mission).

What they're testing: Whether you can turn the gap into a case.

• Acknowledge it plainly, then pivot to evidence: projects, labs, certifications, transferable experience.
• Highlight traits that matter more at entry level: learning speed, reliability, communication, curiosity.
• Offer specifics: 'Here's the investigation I documented; I can walk you through it.'