A good cybersecurity interview is not a request for isolated definitions. The right question reveals how a person prioritises, how they communicate risk, what they do when data is missing, and whether they understand the operational consequences of their decisions. A certification can confirm training, but it does not on its own prove that somebody can contain a compromised account, reduce noise in a SOC, or explain to leadership why a control deserves budget.
The Spanish context makes that distinction especially important for anyone hiring here. INCIBE, the national cybersecurity institute, handled 122,223 incidents in 2025, 26% more than in 2024, and detected 237,028 notifiable vulnerable systems (INCIBE's cybersecurity review). The interview therefore has to check whether the candidate can work with real priorities, not whether they can recite vocabulary.
Use these 10 cybersecurity interview questions according to the role. For a SOC profile, dig into triage, telemetry and escalation. For cloud security, insist on architecture and identity control. In incident response, ask for a timeline and decisions. In pentesting, separate the technical finding from the ability to demonstrate impact without breaking production. In governance, assess risk, communication and accountability. In every answer, look for four signals: concrete context, their own actions, technical judgement, and the measures that stop the problem recurring.
1. Tell us about a security incident you handled. What went wrong, and how did you resolve it?
This question separates operational experience from memorised knowledge fast. A strong candidate does not open by listing tools. They explain what happened, how it was detected, which systems were affected, exactly what their responsibility was, and what decision they took first.
The answer should follow a recognisable sequence: alert validation, scoping, containment, eradication, recovery and post-incident review. A junior SOC analyst might describe enriching an alert, isolating an endpoint with Microsoft Defender, or escalating the case. A senior should explain why they chose to isolate a machine, block an account, or preserve evidence before acting.
Rule of thumb: an incident story with no personal decisions in it does not demonstrate experience. Always ask "what did you do?" and "what would you have done differently?".
The best answers acknowledge a mistake without turning it into a vague confession. A candidate might explain that a detection rule generated too much noise, that a service account carried excessive permissions, or that the escalation documentation was inadequate. What matters is connecting the failure to a concrete correction: tuning a rule in Splunk, hardening IAM, updating the playbook.
If they have limited professional experience, a lab, a security exercise or an authorised pentest will do. Do not penalise someone for never having lived through a serious breach. Assess whether they reason methodically, document assumptions and learn from the exercise.
The warning sign is a narrative full of product names with no timeline, impact or ownership. Someone who insists everything went perfectly is also a concern, because incident response demands acknowledging uncertainty and trade-offs.
2. How would you keep the cloud infrastructure secure at a startup going from 20 to 200 people in six months?
The right answer is not "I would buy a complete security platform". A fast-growing startup needs controls that travel with the business without turning every deployment into a manual approval. The candidate should sequence the work: asset inventory, identities, secrets, cloud configuration, endpoint protection, activity logging and response.
Ask them to compare priorities. In AWS, for example, they should talk about IAM, temporary roles, MFA, account separation, CloudTrail, security groups and secrets management with services like Secrets Manager. In Azure they might mention Entra ID, Defender for Cloud and Azure policies. In Google Cloud, IAM, Cloud Logging and Security Command Center. The brand matters far less than understanding which problem each control solves.
Scalability also shows in the relationship with engineering. A practical candidate integrates infrastructure-as-code scanning, secret detection and configuration validation into the pipeline. They do not impose indiscriminate blocks. They may propose documented exceptions, risk review, and fixes prioritised by exposure.
For a growing company it is worth checking the answer against a guide to hiring cybersecurity experts, particularly when assessing collaboration with developers and communication ability.
A weak answer treats cloud like a traditional data centre and forgets permissions, APIs, third-party providers or development accounts. Promising absolute security is another bad sign. A competent profile explains what they protect first, what they accept temporarily, and how they will revisit those decisions.
3. What does a well-designed IAM policy look like? Design one for a junior developer at a startup
A well-designed IAM policy grants enough access to do the work and little more. In an interview it is not enough for the candidate to define least privilege. Ask them to design access for someone who needs to read logs, deploy to a development environment and query specific resources — but not modify production or reach real customer data.
The answer should distinguish human identity, application role and service account. It should avoid static credentials, require MFA for interactive access, and separate development, staging and production. If they propose a JSON policy, check whether it restricts actions and resources rather than granting broad permissions with *.
An experienced candidate will explain how they would handle an exception. Perhaps the developer needs to run an urgent migration. The mature solution is not sharing an administrator account. It is temporary elevation, traceable approval, limited duration and subsequent review.
What the candidate has to justify
- Specific permissions: why the role can read a bucket or query a service, and why it cannot delete data.
- Access conditions: restrictions by environment, network, managed device or multi-factor authentication.
- Review: how they will detect stale permissions and revoke access when the function changes.
- Communication: explaining the restriction to the developer through workflow examples, not punitive language.
One warning sign is a policy that only works because it grants full administration. Another is treating IAM as an isolated security task. In practice, roles have to be coordinated with platform, development and data owners. For a junior profile, expect fundamentals and caution. For a senior, also demand process design, traceability and automation.
4. Explain the difference between authentication and authorisation, and how you would implement both in a REST API
The distinction is basic and still filters out weak answers. Authentication answers who the user is. Authorisation determines what they can do once identified. A candidate who confuses them can design a vulnerable API even while knowing modern frameworks.
Ask them to describe the journey of a request. The API receives a token, validates its signature, checks issuer, audience and expiry, identifies the principal, and applies authorisation to the requested resource. Authorisation must not stop at checking a role exists. It also has to verify that this user can access this specific object, to avoid one customer reaching another's resources.
A reasonable answer can include JWT, OAuth 2.0 or OpenID Connect, but the protocol name is no substitute for design. Ask where tokens are stored, how they are revoked, what happens when a refresh token is stolen, and how signing secrets are protected. The candidate should prefer short-lived access tokens and controlled refresh tokens over credentials valid for excessive periods.
To see whether they grasp the architectural consequences, test their explanation against the differences between REST and GraphQL. The point is not deciding which style is better, but watching whether they adapt controls to how the application exposes data.
The clearest warning sign is "if the user has a valid JWT, they get access". A competent profile talks about scopes, roles, ownership, input validation, rate limiting and auditing. A junior should explain the difference without errors. A senior should anticipate abuse, misconfiguration and the evolution of permissions.
5. How would you assess vulnerabilities in an application's dependencies? Which tools would you use?
A vulnerable dependency does not on its own prove the application is exposed. The answer should separate vulnerability, exposure and impact. A library can include the affected component without executing it, be isolated from the internet, or sit on a path that never processes sensitive data. The risk stays on the register; the priority changes.
Ask for a continuous process, not an isolated tool. They might combine Dependabot or Renovate for updates with Snyk, Trivy, OWASP Dependency-Check and the repository provider's scanners. They should also review container images, transitive dependencies, lock files and possible secrets. To validate automated findings, an ethical hacker can add manual testing, as this guide to hiring an ethical hacker explains.
Automation needs clear rules. Ask how they would handle false positives, abandoned packages and breaking updates. A competent profile separates detection from remediation, checks whether the vulnerable path is actually reachable, and documents each exception with an owner, a justification and a review date.
What demonstrates real experience
- Contextual prioritisation: relates severity to exposure, required privileges, affected data and ease of exploitation.
- CI/CD integration: uses early controls and different rules for pull requests, builds and deployments.
- Verifiable remediation: updates, tests, rescans and confirms the risk is gone.
- Exception governance: avoids using "false positive" as a permanent label for closing alerts.
Severity-based SLAs help order the work but do not prove maturity on their own. Ask who decides, what evidence they require, and what happens when a fix slips. A senior profile also anticipates that updating a dependency can change application behaviour, and therefore insists on testing before deployment. A junior should be able to explain the flow without confusing the presence of a package with a confirmed exploit.
6. What is the OWASP Top 10, and which risk is most critical for a SaaS startup?
The OWASP Top 10 is a reference for common web application risks. It is not a list to recite, nor a substitute for a specific analysis. A SaaS startup has to translate it to its own architecture: APIs, session management, tenant isolation, integrations, queues, storage and deployment processes.
Do not expect every candidate to pick the same risk. Expect them to justify the choice. A broken access control can be the priority if it lets one customer read another's data. Poor secrets management can be more urgent if it exposes production credentials. A vulnerable dependency can demand immediate attention if it is exposed and allows remote execution. The quality lies in connecting threat, exposure and impact.
A good answer also bounds the standard. The OWASP Top 10 helps with web applications, but it does not on its own cover the security of a SaaS platform, a mobile app or a cloud environment. The candidate should propose preventive and detective controls: authorisation review, API testing, SAST, DAST, input validation and manual analysis of sensitive flows.
Ask for an example. "I would test for IDOR" is not enough. Better: "I would create two test accounts, try to access another account's resource identifier, check the response, and verify the backend validates ownership rather than just the frontend". That level shows practical understanding.
The warning sign is ranking risks by a published list without reviewing the context. A junior should know the purpose of the standard. A mid-level should apply it to cases. A senior should turn it into requirements, controls, tests and product decisions.
7. How would you implement security logging and monitoring to detect attacks?
The objective is not storing every event. It is keeping the evidence needed to investigate, and generating alerts somebody can act on. A competent candidate starts from the sources: authentication, privilege changes, key creation, configuration changes, sensitive data access, administrative activity, relevant processes and anomalous traffic.
The architecture can vary. A small environment might centralise logs in cloud services and use OpenSearch, Wazuh, Elastic Security or a managed SIEM. A more complex one may need Splunk, Microsoft Sentinel or Google Chronicle. Do not judge the candidate on picking a specific platform. Check whether they can normalise events, synchronise time, control access to logs and protect them from tampering.
Detection needs context. An impossible login, a privilege escalation followed by a mass download, or a key created outside the usual pattern deserve more attention than an isolated authentication. Ask how they will reduce false positives, what data they will add to the alert, and when they will escalate to the on-call owner.
Signals worth looking for
- Coverage: identifies critical assets and missing sources instead of asking for "more logs".
- Quality: tells useful events from noise and defines consistent fields.
- Cost and retention: considers volume, storage, access and internal obligations without promising unlimited retention.
- Response: ties every alert to a playbook, an owner and a concrete action.
A SOC saturated by useless alerts loses the capacity to detect the important incidents. For a junior profile, expect disciplined investigation. For a senior, demand use-case design, operational metrics and continuous rule improvement.
8. Describe your process for a security-focused code review
A security code review is not hunting for a suspicious string and blocking the pull request. The candidate has to show they understand the data flow and the business logic. Ask how they would review authentication, authorisation, input validation, secrets management, serialisation, error handling, database queries and calls to external services.
Tools help, but they do not replace reasoning. Semgrep, SonarQube, CodeQL and other analysers can find known patterns. Manual analysis is still needed to check whether an API allows modifying somebody else's resources, whether a password recovery function leaks information, or whether an apparently small change breaks tenant isolation.
Ask for an example of insecure code and its fix. A useful answer explains why concatenating input into a query is dangerous and how to use parameterised queries. It can also show that hiding an error in the frontend is not enough, because the server has to apply the validation and the authorisation.
The best reviewer does not win arguments with developers. They make the defect easy to understand, easy to fix, and hard to repeat.
For DevSecOps profiles, assess how they would add controls without creating a manual gate on every release. They can combine automated rules, secure templates, reusable examples and human review for high-risk changes. They should also distinguish a blocking finding from a recommendation that can go to the backlog.
The warning sign is reviewing only style and dependencies, or claiming a tool "guarantees" secure code. A junior should identify common defects. A mid-level should explain impact and remediation. A senior should influence architectural patterns and training without turning security into a silo.
9. How would you handle sensitive data exposure discovered in production?
This question reveals maturity because it forces the candidate to coordinate engineering, leadership and compliance. They have to avoid two opposite mistakes: hiding the problem until every detail is known, or announcing it without verifying anything or protecting the investigation. The first action should be to confirm the finding, preserve evidence and assess whether the exposure is still live.
Then they should activate the response plan and escalate according to the organisation's structure. CTO, leadership, legal counsel, privacy owners, communications and system owners may each need different information. If regulated data or individuals could be affected, legal and compliance need to be involved early. The specific obligations depend on the case and the jurisdiction, so the candidate should not improvise legal deadlines.
Technically it may be necessary to revoke credentials, close a bucket, fix an access policy, isolate a service, invalidate sessions or shut down a vulnerable path. Each action should be documented with an owner and a timestamp. Containment does not end when access is closed. Logs have to be reviewed, the exposed data determined, potential accessors identified, and alternative copies or routes ruled out.
How to spot a mature answer
- Does not minimise: distinguishes a potential finding from a confirmed exposure without downplaying either.
- Escalates early: knows when to involve leadership, legal, privacy and communications.
- Communicates facts: separates what is confirmed, what is unknown, and what comes next.
- Learns: proposes fixing the cause, reviewing similar controls and updating the plan.
A serious warning sign is saying they would wait for absolute certainty before telling anyone. Another is promising identical technical communication for users, regulators and leadership. A senior profile protects both the system and the traceability of the decision.
10. What is Zero Trust architecture, and how would you implement it at a startup?
"Never trust, always verify" is not a complete architecture. If the candidate repeats the phrase but cannot translate it into controls, the answer is theoretical. Zero Trust requires explicitly verifying identity, device, context and authorisation, limiting access, and assuming an intrusion can happen.
At a startup, implementation has to be gradual. The first step can be centralising identities in a provider such as Entra ID, Okta or Google Cloud Identity, requiring MFA and retiring shared accounts. Then review service-to-service access, separate environments, use short-lived roles and protect communications with TLS. Segmentation, access proxies and endpoint telemetry complete the model, but they do not replace a clear policy.
Ask the candidate to solve a case: a developer's laptop is compromised and the account has access to repositories, cloud and internal systems. A strong answer limits sessions, revokes tokens, evaluates device posture, restricts access per application and reviews subsequent activity. It also recognises that introducing controls can affect productivity and that they should be tested with pilot teams.
The technical benefit is not an abstract promise. If an attacker obtains an identity, limited permissions and segmentation can reduce lateral movement. The architecture does not work, though, if the company keeps permanent administrators, ownerless exceptions, or logs nobody reviews.
For a junior profile, expect the principle and some controls. For a senior, demand a dependency map, phased migration, exception management and adoption metrics. The warning sign is selling Zero Trust as a single product.