Walk me through how you would threat-model a new payments service.

Threat-modelling is where senior cyber offers are won. Strong candidates pick a method (STRIDE most commonly in UK 2026, also LINDDUN for privacy-heavy systems) and apply it concretely: identify assets (customer card data, payment instructions, audit logs), identify trust boundaries (client-to-API, API-to-DB, internal-to-third-party), enumerate threats per boundary, score them (DREAD or just likelihood/impact), and produce mitigations mapped to specific controls. Mention real-world threats (BOLA, IDOR, race conditions in idempotency keys) not just textbook ones. Weak candidates list OWASP Top 10 in alphabetical order. The kill-shot is recommending controls without identifying assets first. UK fintech panels test this question end-to-end.

Tell me how you would investigate a potential data breach in a Postgres database.

Incident-response method, scored on discipline. Strong answers go: contain first (revoke compromised credentials, isolate the host network), preserve evidence (snapshot, do not log into the host before snapshotting, capture pg_stat_activity), determine scope (which queries ran, which rows were touched, who has admin access), notify (legal/DPO, ICO within 72 hours if personal data confirmed at risk under UK GDPR), then remediate. Mention chain-of-custody and that you would not delete or modify anything during initial triage. Weak candidates jump to 'change all passwords'. The kill-shot is forgetting the 72-hour ICO notification clock. UK panels at regulated companies test this flow specifically because they live it.

How do you secure an AWS account at production scale?

Cloud-security depth is non-negotiable for senior UK cyber roles in 2026. Strong answers cover: SCPs at the org level for guardrails, IAM Identity Center for human access (no long-lived IAM users), least-privilege roles with permission boundaries, GuardDuty + Security Hub + Macie enabled, CloudTrail to a centralised logging account with object-lock S3, VPC flow logs, EventBridge rules for high-severity findings, and infrastructure-as-code (Terraform with policy-as-code, OPA or Checkov in CI). Mention AWS Config for compliance baseline. Weak candidates name-drop services without architecture. The kill-shot is recommending a single AWS account for production and dev. UK fintech and AI-infra panels expect multi-account org-level hygiene.

Walk me through how you would harden a Kubernetes cluster.

Container security tests breadth and depth. Strong answers cover: Pod Security Standards at restricted (no root, no privileged, no host namespace), network policies (default-deny then explicit allow), service mesh for mTLS (Istio or Linkerd), image scanning in CI and at admission (Trivy, Grype, Cosign for signing), secrets via External Secrets Operator + cloud KMS not Kubernetes secrets, OIDC federation for ServiceAccount tokens, audit logging to a SIEM, and RBAC reviewed quarterly. Mention CIS Kubernetes Benchmark and that you would test it with tools like kube-bench. Weak candidates say 'we use Pod Security Policies' (deprecated). The kill-shot is leaving the kube-apiserver internet-facing. UK panels in regulated sectors dig deep here.

How do you approach SAST, DAST and SCA in a CI/CD pipeline?

AppSec process, scored on practicality. Strong answers cover: SCA first (npm audit, Snyk, Dependabot for dependency vulnerabilities), SAST in CI on PRs (Semgrep with custom rules tuned for false-positive control, CodeQL for deeper analysis), DAST against staging post-deploy (ZAP, Burp Pro), SBOM generation per build (CycloneDX or SPDX), gating policy (block CI on critical, ticket on high, ignore on low). Mention developer experience (do not break the build for noisy false positives). Weak candidates describe security tooling as a magic gate. The kill-shot is gating CI on every CVE without triage; you will lose developer trust within a week. UK panels test the developer-experience instinct.

Tell me about a time you had to push back on a feature for security reasons.

Behavioural with stakeholder-management focus. Strong answers describe a specific feature, the threat you identified, how you communicated risk in product/business language (not jargon), what mitigation you proposed instead, and the outcome. Mention how you preserved the relationship — security engineers who say 'no' without an alternative get reassigned. Weak answers describe security wins where you blocked everything. The kill-shot is bad-mouthing the product team. Senior cyber engineers in 2026 are stakeholder partners; the question filters for whether you understand that. UK panels at scale-ups especially weight this — the cyber team that does not influence product gets bypassed.

Walk me through how you would investigate a suspected ransomware incident.

Incident response, scored on discipline and pragmatism. Strong answers go: confirm the indicators (encrypted files, ransom note, suspicious processes), isolate the affected systems (network-level not just shutdown — preserve memory for forensics), assemble the response team (security, legal, comms, exec), preserve forensic evidence per chain-of-custody, identify the entry vector (phishing, RDP, exposed service, supply chain), assess scope (what is encrypted, what is exfiltrated), make the restore-vs-pay decision (UK guidance is do not pay; check NCSC and ICO guidance), restore from clean backups verified offline. Mention that paying the ransom does not guarantee decryption and may breach OFAC sanctions. Weak candidates jump to 'isolate and restore'. The kill-shot is forgetting the legal and regulatory obligations.

How do you handle secrets management at production scale?

Practical question; UK panels test it constantly. Strong answers: never in source, never in environment-variable text files, never in long-lived k8s secrets. Use cloud-native KMS (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) or dedicated tooling (HashiCorp Vault) with dynamic short-lived credentials, OIDC federation for workload identity, secret rotation automated, audit logging on every access. Mention that developers should not see production secrets at all in 2026. Weak candidates describe storing secrets in CI/CD environment variables. The kill-shot is recommending Kubernetes secrets unencrypted. UK fintech panels disqualify on this question alone.

How do you approach security for an AI-powered feature?

AI security is a new but rapidly maturing topic in UK 2026. Strong answers cover: prompt-injection defence (system-prompt isolation, user-input sanitisation, output filtering), training-data exfiltration risk, model-inversion attacks, data poisoning in RAG corpus, PII handling in prompts (never log raw user prompts containing PII without redaction), API-key abuse rate limiting, and the OWASP LLM Top 10 framework. Mention model-output filtering for hallucination of credentials or internal data. Weak candidates describe AI security as 'the same as web security'. The kill-shot is not knowing what prompt injection is. AI-feature security is now a regular topic in UK senior cyber interviews.

Tell me about a time you investigated a false-positive alert and what you learned.

This filters out cyber engineers who never tune. Strong answers describe a specific noisy alert, the investigation method (look at base rate, look at the rule logic, look at the asset context), the tuning decision (suppress, refine, raise threshold, or accept the noise), and how you measured improvement. Mention that under-tuning causes alert fatigue and missed real incidents — the bigger risk. Weak answers describe never seeing false positives. The kill-shot is admitting you ignore noisy alerts. UK SOC panels test this question to filter for engineers who care about signal-to-noise as a discipline, not a one-off project.

How do you stay current on threats and vulnerabilities?

Process question; reveals seniority. Strong answers describe a real intake: NCSC bulletins, CISA KEV catalogue, vendor security advisories (Microsoft Patch Tuesday, AWS, Azure), threat-intel feeds (paid or open-source), specific researchers and accounts on Mastodon/X, and a personal lab where you reproduce exploits. Mention that you triage by exploitability and your environment, not CVSS alone. Weak candidates say 'I follow the news'. The kill-shot is admitting you do not know what KEV is. UK senior cyber engineers in 2026 are expected to have a structured threat-intelligence intake; the question screens for that.

Why are you leaving your current role?

Standard closer, weighted heavily for cyber roles where retention is a major spend line. Strong answers are forward-looking: you want bigger scope, you want to work in a regulated environment if you currently are not, you want hands-on threat hunting if your current role is policy-heavy, you want to lead a function. Weak answers attack your current employer or describe burnout. The kill-shot is criticising your current SOC manager by name. UK cyber is a small community in London, Manchester, Bristol and Cheltenham; everyone interviewing you knows the manager you are complaining about. Stay forward-looking. The panel wants reassurance you will not have the same complaint about them in 18 months.

Interview Q's · Tech · UK 2026

Cybersecurity Engineer Interview Questions UK

Cybersecurity Engineer interviews in UK 2026 are tough, and the salaries reflect it — senior cyber engineers in London earn £95-130k base, more at fintech and US tech London offices. Panels test threat-model thinking, hands-on attack-and-defence depth, cloud-security fluency (especially AWS/Azure/GCP at production scale), incident-response discipline and regulatory literacy (UK GDPR, FCA expectations, NIS Regulations). The 12 questions below are the ones I see in real loops at UK fintech, AI infrastructure, defence and critical-national-infrastructure clients. I have written each answer from the recruiter's side: what the panel is testing for, what a strong response looks like, and what mistake immediately ends the conversation.

By Alex · 12-year UK recruiter · 12 questions + recruiter answers

Question 1

Walk me through how you would threat-model a new payments service.

Threat-modelling is where senior cyber offers are won. Strong candidates pick a method (STRIDE most commonly in UK 2026, also LINDDUN for privacy-heavy systems) and apply it concretely: identify assets (customer card data, payment instructions, audit logs), identify trust boundaries (client-to-API, API-to-DB, internal-to-third-party), enumerate threats per boundary, score them (DREAD or just likelihood/impact), and produce mitigations mapped to specific controls. Mention real-world threats (BOLA, IDOR, race conditions in idempotency keys) not just textbook ones. Weak candidates list OWASP Top 10 in alphabetical order. The kill-shot is recommending controls without identifying assets first. UK fintech panels test this question end-to-end.
Question 2

Tell me how you would investigate a potential data breach in a Postgres database.

Incident-response method, scored on discipline. Strong answers go: contain first (revoke compromised credentials, isolate the host network), preserve evidence (snapshot, do not log into the host before snapshotting, capture pg_stat_activity), determine scope (which queries ran, which rows were touched, who has admin access), notify (legal/DPO, ICO within 72 hours if personal data confirmed at risk under UK GDPR), then remediate. Mention chain-of-custody and that you would not delete or modify anything during initial triage. Weak candidates jump to 'change all passwords'. The kill-shot is forgetting the 72-hour ICO notification clock. UK panels at regulated companies test this flow specifically because they live it.
Question 3

How do you secure an AWS account at production scale?

Cloud-security depth is non-negotiable for senior UK cyber roles in 2026. Strong answers cover: SCPs at the org level for guardrails, IAM Identity Center for human access (no long-lived IAM users), least-privilege roles with permission boundaries, GuardDuty + Security Hub + Macie enabled, CloudTrail to a centralised logging account with object-lock S3, VPC flow logs, EventBridge rules for high-severity findings, and infrastructure-as-code (Terraform with policy-as-code, OPA or Checkov in CI). Mention AWS Config for compliance baseline. Weak candidates name-drop services without architecture. The kill-shot is recommending a single AWS account for production and dev. UK fintech and AI-infra panels expect multi-account org-level hygiene.
Question 4

Walk me through how you would harden a Kubernetes cluster.

Container security tests breadth and depth. Strong answers cover: Pod Security Standards at restricted (no root, no privileged, no host namespace), network policies (default-deny then explicit allow), service mesh for mTLS (Istio or Linkerd), image scanning in CI and at admission (Trivy, Grype, Cosign for signing), secrets via External Secrets Operator + cloud KMS not Kubernetes secrets, OIDC federation for ServiceAccount tokens, audit logging to a SIEM, and RBAC reviewed quarterly. Mention CIS Kubernetes Benchmark and that you would test it with tools like kube-bench. Weak candidates say 'we use Pod Security Policies' (deprecated). The kill-shot is leaving the kube-apiserver internet-facing. UK panels in regulated sectors dig deep here.
Question 5

How do you approach SAST, DAST and SCA in a CI/CD pipeline?

AppSec process, scored on practicality. Strong answers cover: SCA first (npm audit, Snyk, Dependabot for dependency vulnerabilities), SAST in CI on PRs (Semgrep with custom rules tuned for false-positive control, CodeQL for deeper analysis), DAST against staging post-deploy (ZAP, Burp Pro), SBOM generation per build (CycloneDX or SPDX), gating policy (block CI on critical, ticket on high, ignore on low). Mention developer experience (do not break the build for noisy false positives). Weak candidates describe security tooling as a magic gate. The kill-shot is gating CI on every CVE without triage; you will lose developer trust within a week. UK panels test the developer-experience instinct.
Question 6

Tell me about a time you had to push back on a feature for security reasons.

Behavioural with stakeholder-management focus. Strong answers describe a specific feature, the threat you identified, how you communicated risk in product/business language (not jargon), what mitigation you proposed instead, and the outcome. Mention how you preserved the relationship — security engineers who say 'no' without an alternative get reassigned. Weak answers describe security wins where you blocked everything. The kill-shot is bad-mouthing the product team. Senior cyber engineers in 2026 are stakeholder partners; the question filters for whether you understand that. UK panels at scale-ups especially weight this — the cyber team that does not influence product gets bypassed.
Question 7

Walk me through how you would investigate a suspected ransomware incident.

Incident response, scored on discipline and pragmatism. Strong answers go: confirm the indicators (encrypted files, ransom note, suspicious processes), isolate the affected systems (network-level not just shutdown — preserve memory for forensics), assemble the response team (security, legal, comms, exec), preserve forensic evidence per chain-of-custody, identify the entry vector (phishing, RDP, exposed service, supply chain), assess scope (what is encrypted, what is exfiltrated), make the restore-vs-pay decision (UK guidance is do not pay; check NCSC and ICO guidance), restore from clean backups verified offline. Mention that paying the ransom does not guarantee decryption and may breach OFAC sanctions. Weak candidates jump to 'isolate and restore'. The kill-shot is forgetting the legal and regulatory obligations.
Question 8

How do you handle secrets management at production scale?

Practical question; UK panels test it constantly. Strong answers: never in source, never in environment-variable text files, never in long-lived k8s secrets. Use cloud-native KMS (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) or dedicated tooling (HashiCorp Vault) with dynamic short-lived credentials, OIDC federation for workload identity, secret rotation automated, audit logging on every access. Mention that developers should not see production secrets at all in 2026. Weak candidates describe storing secrets in CI/CD environment variables. The kill-shot is recommending Kubernetes secrets unencrypted. UK fintech panels disqualify on this question alone.
Question 9

How do you approach security for an AI-powered feature?

AI security is a new but rapidly maturing topic in UK 2026. Strong answers cover: prompt-injection defence (system-prompt isolation, user-input sanitisation, output filtering), training-data exfiltration risk, model-inversion attacks, data poisoning in RAG corpus, PII handling in prompts (never log raw user prompts containing PII without redaction), API-key abuse rate limiting, and the OWASP LLM Top 10 framework. Mention model-output filtering for hallucination of credentials or internal data. Weak candidates describe AI security as 'the same as web security'. The kill-shot is not knowing what prompt injection is. AI-feature security is now a regular topic in UK senior cyber interviews.
Question 10

Tell me about a time you investigated a false-positive alert and what you learned.

This filters out cyber engineers who never tune. Strong answers describe a specific noisy alert, the investigation method (look at base rate, look at the rule logic, look at the asset context), the tuning decision (suppress, refine, raise threshold, or accept the noise), and how you measured improvement. Mention that under-tuning causes alert fatigue and missed real incidents — the bigger risk. Weak answers describe never seeing false positives. The kill-shot is admitting you ignore noisy alerts. UK SOC panels test this question to filter for engineers who care about signal-to-noise as a discipline, not a one-off project.
Question 11

How do you stay current on threats and vulnerabilities?

Process question; reveals seniority. Strong answers describe a real intake: NCSC bulletins, CISA KEV catalogue, vendor security advisories (Microsoft Patch Tuesday, AWS, Azure), threat-intel feeds (paid or open-source), specific researchers and accounts on Mastodon/X, and a personal lab where you reproduce exploits. Mention that you triage by exploitability and your environment, not CVSS alone. Weak candidates say 'I follow the news'. The kill-shot is admitting you do not know what KEV is. UK senior cyber engineers in 2026 are expected to have a structured threat-intelligence intake; the question screens for that.
Question 12

Why are you leaving your current role?

Standard closer, weighted heavily for cyber roles where retention is a major spend line. Strong answers are forward-looking: you want bigger scope, you want to work in a regulated environment if you currently are not, you want hands-on threat hunting if your current role is policy-heavy, you want to lead a function. Weak answers attack your current employer or describe burnout. The kill-shot is criticising your current SOC manager by name. UK cyber is a small community in London, Manchester, Bristol and Cheltenham; everyone interviewing you knows the manager you are complaining about. Stay forward-looking. The panel wants reassurance you will not have the same complaint about them in 18 months.

How to use these answers

Cybersecurity Engineer interviews in UK 2026 reward depth across three axes: hands-on attack-and-defence skill (you have actually exploited and patched things), cloud-security fluency at production scale (multi-account, IaC, policy-as-code), and stakeholder-management instinct (you can say no without losing influence). The single biggest mistake I see is candidates over-indexing on certifications without practical depth; UK panels test for hands-on judgement first, certifications second. Prep with three real incident-response or threat-modelling stories you can talk through end-to-end (the indicators, the method, the decisions, the lessons). Practise the cloud-security architecture round on real environments you have built. UK senior cyber hires get the salary premium because they earn it on judgement under pressure as much as technical skill.

Related across UK Rights & Guides

Keep reading

Browse all 215+ UK guides across 20 clusters →

Pillars + free tools

Related job-search guides + calculators

Pillars

→ UK Career Change start-here pillar — sector-switch playbook
→ UK CV anchor pillar — CV format + ATS-safe AI prompts
→ UK Interview Prep anchor pillar — STAR + 4-stage UK process
→ UK Cover Letter anchor guide — five UK opening patterns

Free recruiter-built tools