Security Engineer Interview Prep
Defend systems from attacks. Mix of detection, response, prevention.
General tips for this role
- Mindset matters: 'assume breach, design for failure'. Show it.
- Know the regulatory landscape: GDPR (EU/UK), HIPAA (US health), PCI-DSS (payments), SOC 2.
- Be technical AND business-minded. Security is about risk, and risk is a business decision.
- Mention blameless culture — security engineers who blame engineers cause more breaches.
- Know one detection tool deeply (Sentinel, Splunk, or open source ELK + Wazuh).
Explain Zero Trust in plain English.
Show model answer
Never trust by default, always verify. Old model: anyone inside the network is trusted. New model: every request, even from inside, must prove who it is and what it's allowed to do. Three principles: (1) Verify explicitly (identity, device, location). (2) Use least privilege (just enough access). (3) Assume breach (design assuming attackers are already inside).
What is the OWASP Top 10 and name three items.
Show model answer
The most critical web app security risks, updated periodically by OWASP. 2021 list includes: Broken Access Control (#1), Cryptographic Failures, Injection (SQL, command), Insecure Design, Security Misconfiguration, Vulnerable Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, Server-Side Request Forgery.
How does SQL injection work and how do you prevent it?
Show model answer
Attacker injects SQL into a vulnerable input field. Example: login form takes `username` and builds `SELECT * FROM users WHERE name = '$username'`. Attacker enters `' OR 1=1 --` and the query becomes always-true. Prevention: parameterised queries / prepared statements. NEVER concatenate user input into SQL. Use an ORM. Validate input. Apply least-privilege DB permissions.
What is the difference between authentication and authorisation?
Show model answer
Authentication (AuthN): proving who you are. Username + password, MFA, biometrics. Authorisation (AuthZ): what you are allowed to do. Role-based access control (RBAC), policy-based. You authenticate FIRST, then the system authorises each request. Common mistake: assuming a logged-in user can do anything. Always check authorisation per action.
Walk me through how you'd respond to a ransomware incident.
Show model answer
(1) Detect and confirm. (2) Contain: isolate infected machines from the network immediately. (3) Communicate: incident commander assigned, stakeholders informed, legal/PR ready. (4) Identify scope: what is encrypted, what was exfiltrated, how attackers got in. (5) Eradicate: remove malware, close the entry point. (6) Recover: restore from backups (verified clean). (7) Post-incident: blameless postmortem, harden against repeat. (8) Notify regulators and customers if data was breached (GDPR 72hr rule).
What is a SIEM and what would you do with one?
Show model answer
Security Information and Event Management. Collects logs from across the organisation (firewalls, servers, apps, identity providers). Correlates events to detect threats. Examples: Microsoft Sentinel, Splunk, IBM QRadar, ELK Stack. You'd use it to: build detection rules (e.g. alert if 5 failed logins from same IP in 1 minute), investigate incidents, hunt for threats, generate compliance reports.
How would you secure a Kubernetes cluster?
Show model answer
(1) Use namespaces to segregate workloads. (2) RBAC with least privilege — no cluster-admin for apps. (3) Network policies — default deny, allow only required traffic. (4) Pod security policies/admission — no privileged pods, no host network. (5) Secrets in a secret store (sealed-secrets, external-secrets), never in env vars in YAML. (6) Image scanning at build and runtime (Trivy, Snyk). (7) Audit logs to a SIEM. (8) Regular updates of K8s and base images. (9) Use a service mesh (Istio) for mTLS between services.
Tell me about a security finding you discovered.
Show model answer
STAR. Show: how you found it, severity, your investigation, the fix, what changed afterwards. Bonus: did you write a postmortem or add detection to prevent recurrence?
Even small wins count: 'I noticed our S3 bucket was public, fixed it, then added a Config rule to alert on any public bucket org-wide.'
An engineer pushes API keys to a public GitHub repo. What do you do?
Show model answer
Immediate: (1) Rotate the leaked keys NOW. Assume they are compromised. (2) Force-push to remove from history (or rewrite history with BFG/git filter-repo). (3) Notify the engineer (with kindness — they didn't do it on purpose). (4) Search audit logs for unauthorised use of those keys. Long-term: (5) Add pre-commit hooks (e.g. detect-secrets, git-secrets). (6) Enable GitHub secret scanning (now free). (7) Train the team. (8) Move secrets to a vault (AWS Secrets Manager, HashiCorp Vault).
Mention the human side — security people who shame engineers create a culture of hiding mistakes.