APPSEC
INCIDENT RESPONSE

Security Engineer Interview Questions & Answers 2025

Master security engineer interviews with 15+ comprehensive questions covering application security, incident response, cloud security, and penetration testing. Practice with our AI-powered simulator for cybersecurity positions at top tech companies.

Security Engineer Interview Questions

1. Explain the OWASP Top 10. How do you prevent SQL injection and XSS attacks?
Arrow for FAQ top
Expert Answer: OWASP Top 10 identifies critical web application security risks: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Authentication Failures, Data Integrity Failures, Security Logging Failures, SSRF. **SQL Injection prevention**: (1) Use parameterized queries/prepared statements—never concatenate user input; (2) ORM frameworks with built-in protections; (3) Input validation with allowlists; (4) Least privilege database accounts; (5) WAF rules. Example: `SELECT * FROM users WHERE id = ?` with bound parameter. **XSS prevention**: (1) Output encoding—HTML entity encode `<` `>` `&`; (2) Content Security Policy headers; (3) HTTPOnly and Secure cookie flags; (4) Framework auto-escaping (React, Angular); (5) Input sanitization. Distinguish stored vs reflected vs DOM-based XSS.
2. How do you implement secure authentication and authorization in a web application?
Arrow for FAQ top
Expert Answer: **Authentication**: (1) Password storage—bcrypt/Argon2 with salt, never plaintext; (2) Multi-factor authentication (TOTP, SMS, hardware keys); (3) Session management—secure, httpOnly, SameSite cookies, session timeout; (4) JWT tokens—short expiration, refresh tokens, signature verification; (5) OAuth 2.0/OIDC for third-party auth; (6) Account lockout after failed attempts; (7) Password complexity requirements. **Authorization**: (1) Role-Based Access Control (RBAC) or Attribute-Based (ABAC); (2) Principle of least privilege; (3) Server-side enforcement—never trust client; (4) API gateway authorization; (5) Token-based authorization (JWT claims); (6) Regular access reviews. Common pitfalls: insecure direct object references, missing function-level access control, horizontal/vertical privilege escalation.
3. Explain CSRF attacks and CORS misconfiguration. How do you secure against them?
Arrow for FAQ top
Expert Answer: **CSRF (Cross-Site Request Forgery)**: Attacker tricks authenticated user into executing unwanted actions. Attack: user logged into bank.com, visits evil.com which submits form to bank.com/transfer using victim's session. **Prevention**: (1) CSRF tokens—unique, unpredictable token per session/request; (2) SameSite cookie attribute (Strict/Lax); (3) Double-submit cookie pattern; (4) Verify Origin/Referer headers; (5) Re-authentication for sensitive actions. **CORS misconfiguration**: Overly permissive Access-Control-Allow-Origin (wildcard with credentials, reflecting Origin header). **Secure CORS**: (1) Allowlist specific origins; (2) Never use wildcard with credentials; (3) Validate Origin header server-side; (4) Limit exposed headers; (5) Use credentials flag cautiously. Distinguish CORS from CSRF—CORS controls resource sharing, CSRF prevents unauthorized actions.
4. Walk me through your security code review process. What do you look for?
Arrow for FAQ top
Expert Answer: Security code review process: (1) **Automated scanning**—SAST tools (SonarQube, Checkmarx, Semgrep) for known patterns; (2) **Manual review**—focus on authentication, authorization, input validation, crypto usage; (3) **Data flow analysis**—trace user input to sensitive operations; (4) **Dependency review**—check for vulnerable libraries (SCA tools); (5) **Configuration review**—secrets, API keys, security headers. **Key areas**: Input validation (sanitization, encoding), authentication logic (password handling, session management), authorization checks (access control), cryptography (weak algorithms, hardcoded keys), SQL queries (injection), file operations (path traversal), API endpoints (rate limiting, authentication). Tools: IDE security plugins, git hooks for secrets scanning, peer review checklists. Output: findings with severity (Critical, High, Medium, Low), remediation guidance, retest verification.
5. How would you design a secure network architecture with DMZ for a web application?
Arrow for FAQ top
Expert Answer: **Three-tier architecture**: (1) **Internet-facing zone**—load balancer with WAF, DDoS protection, TLS termination; (2) **DMZ (Demilitarized Zone)**—web/application servers, reverse proxy, limited internet access, no direct database connection; (3) **Internal zone**—database servers, application logic, internal services, no internet access. **Security controls**: (1) Firewalls between each zone—stateful inspection, deny-by-default rules; (2) Web tier can reach DMZ on specific ports (80/443), DMZ can reach internal on specific ports (3306, 5432); (3) Network segmentation—separate VLANs/subnets; (4) Jump box/bastion host for admin access; (5) IDS/IPS monitoring; (6) VPN for remote access. **Cloud implementation**: AWS VPC with public/private subnets, security groups, NACLs, NAT gateway for outbound from private subnets. Benefits: limits blast radius, defense in depth, regulatory compliance.
6. Explain zero-trust network architecture. How would you implement it?
Arrow for FAQ top
Expert Answer: Zero-trust principle: "Never trust, always verify"—no implicit trust based on network location. Core concepts: (1) **Verify explicitly**—authenticate and authorize every access request using all available data (identity, device, location, behavior); (2) **Least privilege access**—just-in-time, just-enough-access (JIT/JEA); (3) **Assume breach**—minimize blast radius, segment access, verify end-to-end encryption. **Implementation**: (1) Identity as perimeter—strong authentication (MFA), identity provider (Okta, Azure AD); (2) Device trust—endpoint detection, compliance checking, device certificates; (3) Micro-segmentation—granular network policies, service-to-service authentication; (4) Software-Defined Perimeter (SDP) or ZTNA solutions; (5) Continuous monitoring—user behavior analytics, anomaly detection. Technologies: BeyondCorp, Zscaler, service mesh (Istio) with mTLS. Contrast with perimeter security model (castle-and-moat).
7. How do you protect against DDoS attacks at different layers?
Arrow for FAQ top
Expert Answer: DDoS protection by layer: **Network layer (L3/L4)**: (1) Cloud-based DDoS mitigation (Cloudflare, Akamai, AWS Shield)—absorb volumetric attacks; (2) Rate limiting at firewall; (3) SYN flood protection—SYN cookies; (4) IP reputation filtering; (5) Geo-blocking non-relevant traffic. **Application layer (L7)**: (1) WAF with rate limiting per endpoint; (2) CAPTCHA/JavaScript challenges; (3) Request validation (user-agent, headers); (4) Caching with CDN—reduce origin load; (5) Auto-scaling to absorb legitimate spikes. **DNS layer**: (1) Anycast DNS—distribute traffic globally; (2) DDoS-resistant DNS providers. **Prevention strategies**: (1) Architecture—eliminate single points of failure, over-provision capacity; (2) Monitoring—baseline traffic, anomaly detection, alerts; (3) Response plan—pre-configured mitigation, provider contacts, communication templates. Distinguish volumetric vs application vs protocol attacks.
8. How would you secure a Kubernetes cluster? What are the key security concerns?
Arrow for FAQ top
Expert Answer: Kubernetes security best practices: (1) **RBAC**—role-based access control, least privilege, avoid cluster-admin; (2) **Pod Security Standards**—restrict privileged containers, hostPath, hostNetwork, capabilities; (3) **Network policies**—default deny, explicit allow rules, micro-segmentation; (4) **Secrets management**—external secrets store (Vault, AWS Secrets Manager), encrypt at rest; (5) **Image security**—scan for vulnerabilities (Trivy, Clair), sign images (Cosign), use minimal base images; (6) **API server security**—TLS, authentication (OIDC), audit logging, disable anonymous auth; (7) **Runtime security**—Falco for anomaly detection, AppArmor/SELinux policies; (8) **Supply chain**—admission controllers (OPA, Kyverno), verify image provenance. Common misconfigurations: exposed dashboards, default service accounts, insecure ingress, privileged pods. Tools: kube-bench, kube-hunter for security assessments.
9. Explain AWS IAM best practices. How do you implement least privilege?
Arrow for FAQ top
Expert Answer: AWS IAM best practices: (1) **Least privilege**—grant minimum permissions needed, use IAM Access Analyzer to identify unused permissions; (2) **No root account usage**—enable MFA, use for account-level tasks only; (3) **IAM roles over access keys**—EC2 instance roles, Lambda execution roles, avoid hardcoded credentials; (4) **Service Control Policies (SCPs)**—organizational guardrails; (5) **Resource-based policies**—S3 bucket policies, combine with identity-based; (6) **Permission boundaries**—maximum permissions, delegation safety; (7) **Condition keys**—MFA required, source IP restrictions, time-based access; (8) **Regular audits**—IAM Access Advisor, CloudTrail logs, unused credentials. **Implementation**: Start with AWS managed policies, refine to custom policies with specific resources/actions, use policy variables for dynamic resources, test with IAM policy simulator. Security: rotate credentials, enforce password policy, monitor with GuardDuty, CloudTrail event analysis.
10. How do you manage secrets (API keys, passwords) in a cloud environment?
Arrow for FAQ top
Expert Answer: Secrets management best practices: (1) **Never hardcode**—no secrets in code, config files, or environment variables in Dockerfiles; (2) **Centralized secrets store**—HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager; (3) **Encryption**—at rest and in transit, use KMS for key management; (4) **Access control**—IAM policies, dynamic secrets with short TTL, audit logging; (5) **Rotation**—automated rotation for databases, API keys, regular schedule; (6) **Injection patterns**—(a) Environment variables injected at runtime, (b) Volume mounts (Kubernetes secrets), (c) API calls to fetch on demand. **Implementation**: Application authenticates (IAM role, service account), requests secret from vault, vault returns decrypted value, application uses in memory only. **Development**: Local secrets in .env (gitignored), different secrets per environment, secrets scanning in CI/CD (git-secrets, truffleHog). Avoid: committing to git, Slack/email sharing, storing in wikis.
11. Walk me through your incident response process. What are the NIST phases?
Arrow for FAQ top
Expert Answer: NIST incident response phases: (1) **Preparation**—incident response plan, team roles (IR lead, analysts, communications), tools (SIEM, EDR, forensics), playbooks, training; (2) **Detection & Analysis**—monitoring alerts (SIEM, IDS), log analysis, threat intelligence, triage severity, determine scope, indicators of compromise (IOCs); (3) **Containment**—short-term (isolate infected systems, block malicious IPs) and long-term (patch vulnerabilities, improve defenses), preserve evidence; (4) **Eradication**—remove malware, close backdoors, reset compromised credentials, vulnerability remediation; (5) **Recovery**—restore systems from clean backups, monitor for reinfection, gradual return to production; (6) **Post-Incident**—lessons learned meeting, update playbooks, implement improvements, compliance reporting. Timeline: document all actions with timestamps. Communication: internal stakeholders, executive updates, external (customers, regulators, law enforcement) as required.
12. How would you set up a Security Operations Center (SOC)? What tools and processes?
Arrow for FAQ top
Expert Answer: SOC setup components: (1) **Technology stack**: SIEM (Splunk, ELK, Sentinel)—log aggregation and correlation; EDR (CrowdStrike, Carbon Black)—endpoint protection; IDS/IPS; vulnerability scanners; threat intelligence feeds; SOAR platform—automated response workflows. (2) **People**: Tier 1 analysts—alert triage, initial investigation; Tier 2—deeper analysis, threat hunting; Tier 3—advanced forensics, malware analysis; SOC manager; threat intel analyst. (3) **Processes**: Alert triage workflow, escalation procedures, playbooks for common scenarios (phishing, malware, DDoS), shift handoffs, metrics (MTTD, MTTR, false positive rate), continuous improvement. (4) **Use cases**: Define detection rules for critical threats, tune to reduce noise, validate coverage. (5) **Integration**: Ticketing system, communication tools, asset inventory. Staffing models: 24/7 coverage (in-house, follow-the-sun, outsourced), on-call rotation. Metrics: alert volume, dwell time, incident trends.
13. Explain threat hunting. How is it different from traditional security monitoring?
Arrow for FAQ top
Expert Answer: **Threat hunting**: Proactive search for threats that evaded automated detections—assumes breach has occurred. Hypothesis-driven approach. **vs Traditional monitoring**: Reactive—wait for alerts from signatures/rules; known threats. **Hunting approach**: (1) **Hypothesis generation**—based on threat intel, TTPs (MITRE ATT&CK), environment knowledge; (2) **Investigation**—query logs (SIEM), analyze network traffic, inspect endpoints; (3) **Pattern discovery**—identify anomalies, lateral movement, data exfiltration; (4) **Response**—if threat found, trigger incident response; (5) **Improvement**—create new detection rules, update defenses. **Techniques**: Stack counting (rare occurrences), anomaly detection, behavior analysis. **Tools**: EDR query languages, threat hunting platforms (Carbon Black, Falcon), custom scripts. **Indicators**: Unusual outbound connections, privilege escalation, credential access, persistence mechanisms. Focus areas: crown jewel assets, recent vulnerabilities, adversary campaigns. Regular cadence: weekly hunts, dedicated time allocation.
14. How would you handle a ransomware incident? What are the key steps?
Arrow for FAQ top
Expert Answer: Ransomware response: (1) **Immediate containment**—isolate infected systems (disconnect network, disable WiFi), identify patient zero, prevent spread; (2) **Assessment**—determine ransomware variant, scope of encryption, backups status, ransom demand; (3) **Preserve evidence**—memory dumps, disk images, network captures for forensics/law enforcement; (4) **Eradication**—identify entry point (phishing, RDP, vulnerability), remove malware, check for backdoors, reset all credentials; (5) **Recovery decision**—(a) Restore from backups (preferred)—verify backup integrity, test for malware, restore in isolated environment first; (b) Decryption tools—check NoMoreRansom.org; (c) Pay ransom (last resort, no guarantee); (6) **Recovery**—rebuild systems from clean images, patch vulnerabilities, restore data, monitor for reinfection; (7) **Communication**—executive updates, customer notifications, law enforcement (FBI IC3), insurance. **Prevention**: Regular tested backups (offline/immutable), MFA, email filtering, patching, least privilege, EDR.
15. How do you design and implement a vulnerability management program?
Arrow for FAQ top
Expert Answer: Vulnerability management program: (1) **Asset inventory**—complete catalog of systems, applications, owners; (2) **Scanning**—automated vulnerability scanners (Qualys, Nessus, Rapid7), frequency based on asset criticality (critical weekly, others monthly), authenticated scans for better coverage; (3) **Assessment**—validate findings (eliminate false positives), prioritize based on CVSS score + exploitability + asset criticality + threat intelligence; (4) **Remediation**—SLA by severity (Critical 7 days, High 30 days, Medium 90 days), patch management, virtual patching (WAF rules) for temporary mitigation, compensating controls; (5) **Verification**—rescan to confirm remediation; (6) **Reporting**—dashboards for stakeholders, trend analysis, metrics (remediation time, vulnerability density). **Integration**: Ticketing system for tracking, risk register, compliance requirements (PCI-DSS, HIPAA). **Special cases**: Zero-days—emergency patching process, vendor communication, workarounds. Continuous improvement: penetration testing, bug bounty programs.

Related Interview Guides

DevOps Engineer

CI/CD, containerization, cloud infrastructure, and automation questions

Site Reliability Engineer

System reliability, monitoring, incident response, and SLO management

Software Engineer

Algorithms, data structures, system design, and coding interview preparation

Backend Developer

API design, databases, scalability, and backend architecture interview prep

View All Roles →