Entry-Level Cybersecurity Engineer Interview Preparation Guide for Airbnb
Cybersecurity Engineer
Airbnb
entry
6 rounds
Updated 6/14/2026
Airbnb's interview process for entry-level technical roles follows a structured approach beginning with recruiter screening, followed by technical phone interviews, and culminating in a comprehensive onsite round with multiple interviewers evaluating technical skills, problem-solving ability, security fundamentals, and cultural fit. The process emphasizes hands-on technical assessment, real-world security scenarios, and alignment with Airbnb's values of innovation and collaboration.
Interview Rounds
1
Recruiter Screening
30 min4 focus topicsbehavioral
What to Expect
Initial conversation with an Airbnb recruiter to assess your background, understanding of the role, career goals, and basic fit with Airbnb's culture and values. The recruiter will verify your eligibility to work in the United States and discuss your experience with security fundamentals. This is a conversational round focused on your motivation for joining Airbnb's security team and assessing communication skills.
Tips & Advice
Research Airbnb's mission and security culture before the call. Be prepared to discuss why you're interested in cybersecurity and what excites you about Airbnb specifically. Have a clear, concise explanation of your background and any security projects or coursework. Ask thoughtful questions about the role and team. Confirm your ability to work remotely from a state where Airbnb has a registered entity. Verify state work eligibility requirements.
Focus Topics
Communication and Collaboration Skills
Your ability to explain technical concepts clearly and work effectively with team members
Practice Interview
Study Questions
Learning Ability and Growth Mindset
Demonstrated history of learning new technologies, frameworks, and solving unfamiliar problems independently
Practice Interview
Study Questions
Why Airbnb and Why Security
Your motivation for joining Airbnb's security team and interest in cybersecurity as a career
Practice Interview
Study Questions
Security Fundamentals Knowledge
Understanding of basic security concepts like encryption, authentication, threat models, and common vulnerabilities
Practice Interview
Study Questions
2
Technical Phone Screen
60 min5 focus topicstechnical
What to Expect
A 60-minute technical interview conducted via phone with a security engineer or technical interviewer from Airbnb. This round focuses on assessing your coding fundamentals, understanding of security principles, and ability to solve security-related problems. You may be asked to write code to implement basic security controls, analyze vulnerabilities, or design simple security solutions. The interviewer will evaluate problem-solving approach, coding quality, and communication of your thinking.
Tips & Advice
Practice coding in at least one language (Python or Go preferred for security work). Be ready to solve problems using a shared coding environment. Focus on writing clean, readable code with error handling. Explain your approach before coding and walk through your logic. For security-specific problems, demonstrate understanding of why certain practices matter. If stuck, think out loud and ask clarifying questions. Prepare examples of security vulnerabilities you understand (OWASP Top 10) and basic mitigation strategies.
Focus Topics
Web Application Security Vulnerabilities
Knowledge of common OWASP Top 10 vulnerabilities: SQL injection, XSS, CSRF, authentication bypass, and basic mitigation approaches
Practice Interview
Study Questions
Authentication and Authorization
Understanding of OAuth, JWT, multi-factor authentication, and basic access control models
Practice Interview
Study Questions
Security Problem-Solving Approach
Ability to analyze a security problem, ask clarifying questions, and propose reasonable solutions with trade-off awareness
Practice Interview
Study Questions
Coding Fundamentals in Python or Go
Proficiency in basic data structures, algorithms, string manipulation, and file I/O operations
Practice Interview
Study Questions
Cryptography Basics
Understanding of symmetric encryption, asymmetric encryption, hashing, and when to use each
First onsite interview focusing on your understanding of security architecture principles and threat modeling methodologies. You will be presented with a simplified system architecture and asked to identify potential security threats, design protections, and explain your reasoning. This round assesses your ability to think about systems holistically from a security perspective and understand how different components interact. Expect questions about attack vectors, defense-in-depth, and practical mitigation strategies.
Tips & Advice
Review threat modeling frameworks like STRIDE and basic security architecture patterns. Come prepared with a structured approach to analyzing threats. When presented a system, identify data flows, trust boundaries, and external dependencies. Think about both preventive controls (preventing attacks) and detective controls (identifying attacks). For entry-level, focus on understanding the framework and applying it logically rather than identifying every possible threat. Ask clarifying questions about the system's requirements and constraints.
Focus Topics
Security Control Classification
Understanding preventive controls (preventing attacks), detective controls (identifying attacks), and responsive controls (responding to incidents)
Practice Interview
Study Questions
Defense-in-Depth Principle
Understanding of layered security controls and how multiple defenses work together to protect systems
Practice Interview
Study Questions
Trust Boundaries and Data Flow Diagrams
Ability to identify system components, data flows between them, and trust boundaries where security controls are needed
Practice Interview
Study Questions
Common Attack Vectors
Understanding of network-layer attacks, application-layer attacks, insider threats, and social engineering approaches
Practice Interview
Study Questions
STRIDE Threat Modeling Framework
Systematic methodology for identifying threats: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
Practice Interview
Study Questions
4
Onsite Round 2: Secure Coding & Code Review
50 min5 focus topicstechnical
What to Expect
Technical interview assessing your understanding of secure coding practices and ability to review code for vulnerabilities. You will review sample code snippets containing security flaws and identify vulnerabilities, explain their impact, and suggest fixes. You may also write secure code examples demonstrating proper handling of sensitive data, input validation, and error handling. This round evaluates your practical understanding of how security is implemented in real code.
Tips & Advice
Study common vulnerability patterns in code including input validation flaws, hardcoded credentials, improper error handling, and insecure data handling. Practice code review by examining real vulnerabilities in databases like CWE. Be prepared to explain WHY something is a vulnerability and what the impact could be. Focus on practical, realistic fixes rather than theoretical solutions. For entry-level, demonstrating understanding of fundamental secure coding principles is more important than catching every possible flaw.
Focus Topics
Secure Logging Practices
Understanding what to log, what not to log (avoiding sensitive data in logs), and audit trail requirements
Practice Interview
Study Questions
Error Handling and Information Disclosure
Understanding how error messages can leak sensitive information and techniques for secure error handling
Practice Interview
Study Questions
Code Review Methodology
Systematic approach to reviewing code for security vulnerabilities including architecture review, logic analysis, and vulnerability pattern matching
Practice Interview
Study Questions
Sensitive Data Handling
Secure handling of passwords, API keys, cryptographic material, and personally identifiable information (PII)
Practice Interview
Study Questions
Input Validation and Sanitization
Techniques for validating and sanitizing user input to prevent injection attacks and ensure data integrity
Technical interview focused on implementing security controls and understanding how to integrate security into systems. You may be asked to design and implement authentication mechanisms, encryption implementations, or security monitoring capabilities. This round evaluates your ability to translate security requirements into working code or technical implementations. Expect practical questions about implementing security features at Airbnb scale, working with existing frameworks, and ensuring security controls are effective.
Tips & Advice
Be prepared to implement or discuss implementation of security controls using common libraries and frameworks. Understand how to use cryptographic libraries safely without implementing crypto from scratch. Discuss your approach before diving into implementation. For entry-level, showing understanding of security control principles and ability to use appropriate libraries correctly is more important than building everything from scratch. Be ready to discuss testing and validation of security controls.
Focus Topics
Secure Configuration and Hardening
Understanding secure defaults, configuration best practices, and hardening of systems against known attack vectors
Practice Interview
Study Questions
Authentication Mechanisms
Implementation of authentication systems including session management, token-based authentication, and multi-factor authentication
Practice Interview
Study Questions
Security Testing and Validation
Approaches to testing security controls including unit testing, integration testing, and security-specific testing techniques
Practice Interview
Study Questions
API Security
Security considerations for APIs including rate limiting, authentication, authorization, input validation, and logging
Practice Interview
Study Questions
Cryptographic Libraries and Safe Usage
Proper use of cryptographic libraries for encryption, hashing, and key management without implementing algorithms from scratch
Practice Interview
Study Questions
6
Onsite Round 4: Behavioral & Cultural Fit
45 min5 focus topicsbehavioral
What to Expect
Final onsite round evaluating cultural alignment with Airbnb's values and your ability to work effectively in a team environment. The interviewer will explore your past experiences, how you handle challenges, collaborate with others, and approach problem-solving. This round assesses your growth mindset, communication skills, and ability to work in Airbnb's collaborative, fast-paced environment. You'll discuss specific examples from your background that demonstrate these qualities.
Tips & Advice
Prepare 3-5 STAR (Situation, Task, Action, Result) examples from your background demonstrating: solving a security or technical problem, overcoming a challenge, working effectively in a team, learning something new, and handling disagreement. Be specific with details and quantifiable results where possible. Research Airbnb's core values (belonging, innovation, integrity, respect) and be ready to discuss how your values align. As an entry-level candidate, focus on demonstrating eagerness to learn, collaboration, and ability to take direction. Be authentic and honest about gaps in your experience while showing determination to grow.
Focus Topics
Communication and Clarity
Ability to explain complex concepts clearly, listen actively to others, and adapt communication style to audience
Practice Interview
Study Questions
Teamwork and Collaboration
Ability to work effectively with diverse team members, share knowledge, and support colleagues in achieving shared goals
Practice Interview
Study Questions
Problem-Solving Approach and Resilience
How you approach unfamiliar problems, persist through difficulties, and seek help when needed
Practice Interview
Study Questions
Learning and Growth Mindset
Examples of taking on new challenges, learning new technologies, and growing from failures
Practice Interview
Study Questions
Airbnb Core Values Alignment
Demonstration of how your values align with Airbnb's core values: Belonging, Innovation, Integrity, and Respect
You are responsible for scaling threat modeling across an enterprise with hundreds of microservices. Propose a program that covers: standard threat-model templates, ownership model (who owns and reviews models), automation tooling, continuous discovery of new services, integration with architecture review boards, and metrics for adoption. Explain how to keep models current and avoid stale artifacts.
Sample Answer
**Overview (one-line)** Run a scalable, automated threat-modeling program using standard templates, clear ownership, continuous discovery, CI/CD automation, ARB gating, and adoption metrics — with processes to prevent stale artifacts.**Standard templates & artifacts**- Provide two templates: lightweight STRIDE-based service template (data flows, trust boundaries, assets, mitigations) and a deeper PASTA/attack-tree template for high-risk services.- Machine-readable canonical format (YAML/JSON) plus generated diagrams (C4/Diagrams-as-Code) to drive automation and scanning.**Ownership model**- Service Owner (Dev/Product): creates and updates model; ownership tracked in service metadata.- Security Engineering: reviews, certifies risk classification, and publishes required controls.- ARB / Risk Committee: approves high-risk models and exceptions.**Automation & tooling**- Integrate with Git/GitOps: models live in repos; PR templates enforce model updates.- Use tooling: IriusRisk/OWASP Threat Dragon + custom parsers for YAML models; generate tickets in Jira for missing controls.- CI checks: fail build if model missing for governed services or if critical threats unresolved.**Continuous discovery**- Source-of-truth integrations: Kubernetes API, service registry (Consul), API gateway, IaC (Terraform) to detect new services and auto-create model skeletons assigned to owners.**ARB integration**- ARB dashboard shows certified models; ARB gate enforced in CI/CD for production promotion for services above a risk threshold.**Metrics for adoption**- % services with current model, time-to-first-model, time-to-risk-mitigation, age distribution of models, number of critical findings triaged.- Track trending: reductions in recurring threat categories.**Keeping models current / avoiding staleness**- Model TTL (e.g., 90 days) and auto-reminders; require model update on any IaC/architecture change via pre-merge CI hooks.- Scheduled scans comparing deployed topology vs model; if delta detected, create owner ticket.- Automate evidence collection (control status) and surface stale flag in dashboards; escalate unaddressed staleness to engineering leadership.This program balances developer ownership, centralized security oversight, and automation to scale threat modeling across hundreds of microservices while keeping artifacts fresh and actionable.
Security Architecture Principles and FundamentalsEasyTechnical
95 practiced
Explain the fundamental components of a secrets management solution. Describe how you would securely store, distribute, and rotate secrets (API keys, database passwords) for a fleet of stateless containers running in Kubernetes, and name technologies you would consider using.
Sample Answer
**Definition / Fundamental components**- Secret storage (encrypted at rest), access control (authn/authz), secret distribution, rotation/credential lifecycle, audit & monitoring, key management (KMS/HSM).**How to securely store**- Use a centralized secrets engine (e.g., HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) with envelope encryption via KMS/HSM.- Enable strong RBAC and policy-based access (least privilege) and enable audit logging.- Ensure secrets at rest are encrypted and transit is TLS-only.**How to distribute to stateless Kubernetes containers**- Prefer short-lived, dynamic secrets (DB creds, cloud tokens) minted on demand rather than static keys.- Authenticate pods via Kubernetes ServiceAccount -> OIDC or Kubernetes auth method (Vault Kubernetes auth).- Deliver secrets via CSI Secrets Store or Vault Agent/sidecar that writes into memory or tmpfs; avoid mounting plaintext files in images.- Use External Secrets Operator or HashiCorp Vault + injector for seamless sync while keeping control in central store.**How to rotate**- Use dynamic secret backends (Vault Database/Cloud) to auto-generate and revoke DB credentials with TTLs.- Automate rotation: set TTL/lease, renew before expiry or create new credentials and update consumers via rolling restart or hot-reload (signal-based).- Integrate rotation into CI/CD for any long-lived keys; use monitoring/alerts on rotation failures.**Controls & monitoring**- Enforce MFA for high-privilege ops, enable audit logs, monitor secret access patterns, regularly scan for leaked secrets.- Use KMS/HSM for root keys, periodic key rotation, and disaster recovery policies.**Technologies to consider**- HashiCorp Vault (Kubernetes auth, DB dynamic secrets, Agent, Vault CSI)- Kubernetes Secrets CSI Driver, External Secrets Operator, Sealed Secrets (sealed by KMS)- Cloud providers: AWS Secrets Manager + KMS, GCP Secret Manager + KMS- HSM/Cloud KMS (AWS KMS, Google Cloud KMS, Azure Key Vault)
Learning Agility and Growth MindsetHardTechnical
45 practiced
Design a 'knowledge-as-code' system where postmortems, playbooks, runbooks, and learning artifacts are versioned, reviewed, tested, and deployed like software. Describe architecture (repo layout, CI/CD, unit testing for playbooks, search/indexing, RBAC), review process, and safeguards to prevent leaking sensitive incident details.
Sample Answer
**High-level approach**I’d treat knowledge artifacts as software: Git-centric repos, automated CI/CD, testing, RBAC, and privacy-first publishing. I’d design controls to ensure security posture and prevent leaking sensitive incident data.**Repo layout**- monorepo or per-team repos with stable layout: - /playbooks/{service}/{playbook}.yaml - /runbooks/{service}/{runbook}.md - /postmortems/{YYYY-MM-DD}-{id}.md.gpg - /tests/{playbooks}_unit_test.py - /templates/, /schemas/, /ci/, /docs/- enforce schemas (JSON Schema/OpenAPI) for machine-parseable artifacts**CI/CD pipeline**- Pre-merge checks: schema validation, linting, secrets scan (GitLeaks), PII/Regex detectors, dependency checks- Unit tests: execute playbooks against mock environments or emulator (see below)- Integration: runbooks compiled into docs site in staging, signed artifacts- Deploy: gated promotion to production docs via signed CI job, artifact provenance recorded**Unit testing for playbooks**- Use a playbook runner in containerized test harness that: - loads playbook - injects mocked endpoints and twin telemetry - asserts expected steps, idempotency, and safety guards (no destructive ops)- Example: pytest fixtures that simulate incident signals and assert task ordering and fallbacks**Search & indexing**- Index only sanitized/approved fields into enterprise search (Elasticsearch/Opensearch)- Store original encrypted artifacts; search index contains pointers + metadata, not raw sensitive text- Add field-level tagging: sensitivity, scope, redaction state**RBAC & review process**- Protect branches with required reviewers: security reviewer + service owner- Role-based permissions via Git server (OIDC/SAML) and CI tokens with least privilege- Mandatory reviewers for high-sensitivity tags; use signed commits and verified CI artifacts- Approval matrix: draft -> redacted review -> security review -> release**Safeguards for sensitive data**- Mandatory encryption at rest (GPG or KMS) for postmortems; automated redaction tools as pre-commit hook- Automated DLP: block PRs containing IPs, credentials, or raw stack traces unless marked and encrypted- Staging-only previews: full content only accessible in ephemeral, audited environments- Audit logging: all accesses, decrypts, and CI actions logged to SIEM; retention and alerting on unusual access- Secrets/Tokens: never in repo; use Vault for runtime secrets in test harnesses**Trade-offs / rationale**- Balances developer ergonomics with strict security: machine-readable artifacts enable automated testing while encryption + DLP preserve confidentiality. Auditability and signed pipelines provide non-repudiation for incident records.
Authentication and Access ControlEasyTechnical
61 practiced
List and explain the security-related HTTP cookie attributes and flags you would use to protect session cookies for a modern web application: Secure, HttpOnly, SameSite (Lax/Strict/None), Path, Domain, and expiry. For each attribute, state which attack classes it mitigates (e.g., XSS, CSRF, session hijacking) and recommended default values for modern browsers across first-party and third-party contexts.
Sample Answer
**Brief summary**As a cybersecurity engineer I treat session cookies as high-value tokens and apply layered attributes to reduce XSS, CSRF, session fixation/hijacking, and cross-site tracking risk.**Attributes, mitigation, recommended defaults**- Secure - Mitigates: network eavesdropping / session hijacking (MITM). - Default: Secure = true for all session cookies; require HTTPS-only.- HttpOnly - Mitigates: JavaScript-based XSS cookie theft. - Default: HttpOnly = true for session cookies (first- and third-party where JS access not required).- SameSite (Lax / Strict / None) - Mitigates: CSRF, cross-site request abuse. - Default: First-party session: SameSite=Lax (allows top-level GET navigation flows). For high-security flows use Strict. Third-party (if required for embedding): SameSite=None; Secure must be true. If not needed, avoid third-party cookies.- Path - Mitigates: scope reduction / misuse across app paths. - Default: Path = specific application path (e.g., /app) not “/”, to limit exposure.- Domain - Mitigates: cross-subdomain cookie leakage / misuse. - Default: Domain = exact host (omit Domain attribute so cookie is host-only) or minimal parent domain if intentional subdomain sharing needed.- Expiry / Max-Age - Mitigates: long-lived token replay / persistent session hijack. - Default: Use short-lived cookies (session cookies without persistent expiry) or reasonable Max-Age (minutes–hours) plus rotating refresh tokens; require re-auth for sensitive operations.**Notes / best practices**- Combine attributes: HttpOnly + Secure + SameSite=Lax + host-only + short lifetime as baseline. - Use additional controls: TLS, CSP to reduce XSS, anti-CSRF tokens/Double Submit (as defense-in-depth), token binding or client certificates for high assurance, and monitoring for anomalous sessions.
Attack Vectors and Threat LandscapeMediumTechnical
37 practiced
Design monitoring, alerting, and investigative controls to detect an insider exfiltrating sensitive data by uploading it to a personal cloud storage account. Include DLP rules, user and entity behavior analytics (UEBA) thresholds, playbooks for investigation, and privacy/legal considerations when involving HR and law enforcement.
Sample Answer
**Situation & goal**Design layered controls to detect insiders uploading sensitive data to personal cloud storage (e.g., Google Drive, Dropbox), then investigate while preserving privacy and legal chain-of-custody.**DLP rules**- Content-based: block/alert on documents matching sensitive regexes (SSN, credit card, PII) and high-confidence fingerprint matches to classified data sets.- Context-based: alert when transfer destination is known consumer cloud domain OR when MIME type is archive (zip/tar) + sensitive content.- Volume/time heuristics: alert when >100MB or >50 files to personal cloud in 24h, or first-time upload of classified doc by low-privilege user.- Enforcement: quarantine, block upload via proxy, notify security team.**UEBA thresholds**- Baseline per-user upload rate, device usage, working hours.- Thresholds: >3x baseline upload volume to cloud in 24h; new cloud endpoint access + use of removable creds; access to sensitive repo not typical for role.- Risk scoring: combine DLP hits, anomalous endpoints, privilege escalation, and failed/successful data-access spikes. Score >70 triggers high-priority incident.**Investigation playbook**1. Triage: ingest alert, validate DLP fingerprint and destination.2. Enrichment: pull logs (proxy, CASB, endpoint EDR), identify device, IP, process, timestamps, file hashes.3. Containment: revoke session tokens, block cloud domain at proxy/CASB, isolate endpoint if active exfil in progress.4. Forensics: preserve EDR snapshot, collect cloud transfer logs via CASB API, export file hashes and metadata, build timeline.5. Attribution: correlate UEBA history, VPN/geolocation, USB activity, and employee role.6. Remediation & reporting: restore systems, rotate credentials, update DLP/UEBA rules.7. Close: document findings, lessons learned, apply proactive controls.**Privacy / legal considerations**- Escalate to HR/legal before intrusive steps (endpoint image, microphone, keystroke logs) unless immediate risk.- Follow least-privilege for investigators and log access to investigative artifacts.- Preserve chain-of-custody for evidence; use WORM storage for exports.- Engage law enforcement only with legal counsel and clear probable cause; comply with data protection laws (GDPR/CCPA): minimize personal data reviewed, redaction where possible, document lawful basis.Rationale: layered detection (content + context + behavior) reduces false positives; playbook ensures fast containment and compliant investigation while protecting employee privacy and legal defensibility.
Secure Coding and Code ReviewEasyTechnical
54 practiced
Explain secure error handling and logging practices in application code. Describe what information should never be logged (plaintext secrets, full raw tokens, raw PII), how to sanitize or redact sensitive fields, how to format logs for secure consumption, and how to design user-facing error messages that are actionable for support while not leaking sensitive implementation details to an attacker.
Sample Answer
**Approach — why this matters**Secure error handling and logging prevents sensitive data leakage, aids incident response, and preserves developer productivity without increasing attacker reconnaissance.**What never to log**- Plaintext secrets (passwords, API keys)- Full raw tokens/JWTs, session IDs- Raw PII (SSNs, credit cards, DOB, medical data)- Cryptographic private material and full stack traces in prod**Sanitize / redact before logging**- Apply allowlists: only log known safe fields- Mask/highlight partial values: e.g., credit card => **** **** **** 1234; token => first 4 + "..."+ last 4- Hash or HMAC sensitive values with per-service salt for correlation: store HMAC(value)||meta- Centralize sanitization library used by all services and middleware (input validators, logging wrappers)**Log format & secure consumption**- Use structured logs (JSON) with fixed schema: timestamp, level, service, correlation_id, event, sanitized_payload- Include correlation_id for tracing, but never embed secrets- Enforce RBAC on log storage, encrypt logs at rest, use TLS in transit- Implement retention, immutable append-only audit for security-relevant events- Monitor and alert on anomalous log patterns and high-volume error spikes**User-facing error messages**- Show simple, actionable messages: “We couldn’t process your payment. Try again or contact support with error code E12345.”- Surface a short error code and correlation_id that maps to full sanitized server log for support- Avoid implementation details, stack traces, SQL errors, or file paths**Example patterns**- Logged JSON: { "ts":"...", "lvl":"ERROR", "svc":"orders", "cid":"abc-123", "msg":"payment failed", "card_last4":"1234", "err_code":"PAY-402" }- Server saves HMAC(card_number) for correlation, not the number itself**Operational controls**- Logging policy, automated tests to detect secret leaks, periodic audits, and incident playbooks tying error codes to remediation steps.
STRIDE Threat Modeling FrameworkEasyTechnical
57 practiced
As a cybersecurity engineer embedded within an agile team, propose a lightweight process to integrate STRIDE threat modeling into a two-week sprint cadence. Specify who participates, when modeling activities occur during the sprint, the minimal artifacts to produce, acceptance criteria for security, and how findings are tracked and remediated without blocking developer velocity.
Sample Answer
Situation: As the embedded security engineer, I propose a lightweight STRIDE process that fits a two-week sprint without slowing dev velocity.Who participates- Me (embedded cybersecurity engineer)- Product owner or feature lead- 1–2 devs implementing the feature- QA/automation engineer (optional)- Architect or tech lead for complex featuresWhen during the sprint- Sprint Planning (30 min): identify new feature scope and flag modeling candidate- Day 2 of sprint (45–60 min): quick STRIDE session + lightweight DFD sketch- Mid-sprint check-in (15 min): validate mitigations are being implemented- Sprint Review/Retro: summarize findings and lessonsMinimal artifacts- One-page Data Flow Diagram (DFD) for the feature- Short threat register (Threat, STRIDE category, risk rating, proposed mitigation)- One-line decision log (accepted residual risks)- Backlog tickets for each mitigation (severity tag + estimate)Acceptance criteria for security (must be met before feature Done)- No Critical (red) threats with “no mitigation” status- All High threats either mitigated, accepted with documented compensating controls, or scheduled as P0 backlog items with owner and SLA- Automated tests or static checks added when applicable- Threats and mitigations captured as acceptance criteria on the feature ticketTracking & remediation without blocking velocity- Triage: classify findings into Blocker (must fix), High (ship-blocking unless compensating control accepted), Medium/Low (scheduled)- Only Blocker stops merge; High requires either mitigation, short compensating control, or documented PO acceptance with SLA- Create JIRA tickets with labels (security:severity) and SLA (e.g., Fix P1 within 1 sprint)- Use sprint board swimlanes or a lightweight security Kanban for visibility- Automate checks where possible (SAST, infra-as-code scanning) to catch regressions early- Weekly 15-min security sync to clear questions and keep momentumWhy this works- Minimal overhead (one short session + artifacts) keeps cadence- Clear risk classification and PO-driven acceptance prevents unnecessary blocking- Tickets + SLA + automation ensure remediation is tracked and enforced while developers move fast.
Security Architecture Principles and FundamentalsMediumTechnical
139 practiced
How would you implement least privilege for both service accounts and human operators in a Kubernetes cluster that hosts multiple teams and namespaces? Describe RBAC design patterns, recommended admission controllers (e.g., OPA/Gatekeeper), network policies, default-deny baselines, and automation you would use to enforce and audit least privilege across clusters.
Sample Answer
**Approach summary**Implement least privilege via layered controls: principled RBAC, admission policies (OPA/Gatekeeper, PodSecurity), network segmentation, default-deny baselines, and automation for drift detection and audit.**RBAC design patterns**- Namespace-per-team + role-per-purpose: create ClusterRoles for common read-only/admin tasks, RoleBindings scoped per namespace.- Least-privilege Roles: one permission = one Role. Use verbs narrowly (get/list/watch vs create/patch).- Service account per workload, not per namespace; map CI/CD to ephemeral SA with minimal scopes.- Use RoleAggregation and permission-reviews to avoid role sprawl.Example Role (least-privilege read pods):
**Admission controllers**- OPA/Gatekeeper: enforce conventions (disallow hostPath, restrict images, require SA annotations), implement ConstraintTemplates for deny/allow.- PodSecurityAdmission (enforce baseline/restricted).- CRD/ValidatingAdmission for custom checks (resource limits, seccomp, read-only FS).**Network policies & default-deny**- Apply default-deny NetworkPolicy in every namespace; require explicit allow egress/ingress per workload.- Use label-based policies (app + role labels) and a deny-by-default CNI (Calico, Cilium) for enforcement.**Automation & audit**- GitOps for policy and RBAC (Flux/Argo) — policy-as-code reviewable in PRs.- CI checks: validate Gatekeeper constraints, kube-linter, conftest.- Continuous audit: Kubernetes audit logs → aggregator (Fluentd → Elastic/Datadog) + alerting for privilege escalations, new ClusterRoleBindings.- Periodic access reviews: run automated queries (kube-psp, rbac-lookup) to map human/SAs to permissions; revoke unused bindings.- Short-lived credentials: integrate OIDC + IAM roles and kubectl plugin to request elevation for just-in-time (JIT) access; record ephemeral tokens.**Trade-offs & monitoring**- Balance strictness vs developer velocity using exception workflows (automated approvals, time-limited overrides).- Monitor policy violations, failed Gatekeeper denials, and network policy hits to iterate policies.
Learning Agility and Growth MindsetHardTechnical
50 practiced
You're asked to learn a new cryptographic primitive (e.g., a new AEAD, lattice-based primitive, or signature scheme) and then influence product teams to adopt it safely within a quarter. Explain your self-study plan, how you'd produce a risk assessment, a migration strategy, test vectors, a security review checklist, and a training plan for engineers.
Sample Answer
**Situation & Objective**I’m given a new primitive (e.g., lattice-based KEM or AEAD) and must enable safe adoption across product teams within a quarter. My plan covers self-study, risk assessment, migration, test vectors, security checklist, and training.**1) Self-study plan (2 weeks)**- Read IETF/CRYPTO papers, RFCs, reference impls, NIST PQC submissions.- Implement minimal reference usage in a sandboxed repo; run existing test vectors.- Threat-model primitive-specific attacks (side-channels, misuse, parameter choices).**2) Risk assessment (1 week)**- Document attacker models, known weaknesses, maturity (standardization status), interoperability risks.- Rate risks (Impact x Likelihood) and mitigations: fallback algorithms, strict parameter validation, side-channel hardening, crypto agility requirements.- Deliverable: risk matrix + decision memo for leadership.**3) Migration strategy (4–6 weeks)**- Phased rollout: Canary libs → opt-in product features → dual-run (hybrid mode) → default.- Requirements: API compatibility layer, timeouts, telemetry for failures, rollback plan.- Define compatibility gates and release criteria.**4) Test vectors & CI (concurrent)**- Generate canonical test vectors (KATs) from reference impl; include edge cases and malformed inputs.- Add property tests: determinism where applicable, key-rotation, concurrency stress.- Integrate into CI: fuzz harness, deterministic replay, side-channel regression benchmarks.**5) Security review checklist**- Correct parameter sets? RNG and entropy sources validated?- Side-channel resistance and constant-time considerations?- Error handling leaks? Safe defaults and misuse resistance?- Backward/forward secrecy, key management, hardware token compatibility?- Compliance, export control, and logging/privacy concerns.**6) Training & adoption (ongoing)**- 2-hour hands-on workshop + code labs showing library usage, pitfalls, and migration recipes.- Quick reference docs, API examples, and “how to rollback” playbook.- Office hours and dedicated Slack channel; pair-program with first adopters.**Metrics & Governance**- Success: number of services in hybrid mode, failure rates, security incidents (target: zero), and completion of checklist items per service.- Quarterly review to reassess based on field data and new crypto guidance.This plan balances rapid learning with measurable, risk-informed rollout and developer enablement.
Authentication and Access ControlHardSystem Design
59 practiced
Design a delegated authorization system for third-party applications (OAuth2) that supports fine-grained scopes, incremental authorization, clear consent UX, scope revocation, and resource-server enforcement of least privilege. Discuss scope naming conventions, how tokens should represent scopes, consent lifetime/options, and how resource servers map scopes to actual permissions.
Sample Answer
**Clarify requirements & threats**- Support fine-grained scopes, incremental auth, clear consent UX, revocation, and resource-server least-privilege enforcement while resisting token misuse, replay, and scope escalation.**High-level design**- Authorization Server (AS): issues tokens, hosts consent UI, maintains scope catalog, revocation API, audit logs.- Resource Servers (RS): enforce scope -> permission mapping, validate tokens (introspection or JWT verification), consult local PDP for fine-grained checks.- Clients (3rd-party apps): request scopes incrementally; use PKCE and confidential clients use mTLS or client_secret_jwt.**Scope naming & taxonomy**- Hierarchical, rest-like, human- and machine-friendly: - Format: resource:action:resource-instance? e.g. calendar:read, calendar:write:events, user:profile:email:read - Use fine-grain atoms (resource, verb, qualifier). Include versioning suffix when schema changes: calendar:read:v2- Define scope families and defaults; mark sensitive scopes (PII, financial) for explicit high-risk consent.**Tokens & scope representation**- Use short-lived access tokens (JWT or opaque reference tokens) and long-lived refresh tokens (rotating).- JWT claim example: - "scp": ["calendar:read","contacts:link:write"] - "aud": ["calendar-api.v1"], "cid": client_id, "cnf": {thumbprint} for MTLS- Prefer opaque reference tokens for highly sensitive scopes to force introspection (AS can enforce revocation immediately).- Token binding: certificate thumbprints or DPoP to prevent replay.**Incremental authorization & consent UX**- Start with minimal scopes; allow requesting additional scopes using separate incremental consent flows.- Consent UI shows grouped permissions, real-world examples, last access timestamp, and consent lifetime options: - Session-only, 30-day, until-revoked. For high-risk scopes require re-auth every N days and force Just-In-Time (JIT) verification.- Explicit consent for scope families; show scope dependencies and explain least-privilege.**Revocation & lifecycle**- Immediate revocation via AS revocation endpoint and revocation events pushed to RS (webhooks) and cache invalidation (pub/sub).- Use short access token TTL (minutes) + refresh token rotation to limit window.- Maintain revocation list and token-introspection endpoint; RS should check cache and fall back to introspection for sensitive scopes.**Resource-server enforcement & mapping**- RS maintains a mapping table: scope -> internal permission set (APIs, DB access, fields). Example: - calendar:read -> {GET /events, view_event_fields: [title,start,end,location]} - calendar:write -> {POST /events, edit_event_fields}- Enforce field-level and action-level checks (not just endpoint path). Implement PDP that evaluates: - token.scp includes required scope - token.aud matches RS - contextual attributes (user, time, device, risk score)- Support ABAC for fine-grained rules: scope + resource owner + purpose claim -> permit/deny.**Audit, telemetry & risk controls**- Log: token issuance, consent changes, token introspection, revocation, and resource access with scope used.- Risk engine: on suspicious behavior (anomalous IP, rapid scope usage), revoke tokens or require re-consent.**Trade-offs**- JWTs = stateless and fast, but require short TTL and revocation complexity. Opaque tokens = immediate revocation at cost of introspection latency.- Fine-grained scopes increase UX complexity; mitigate via grouping and default safe minimal scopes.This design enforces least-privilege by combining fine-grained, versioned scopes, token binding/short TTLs, immediate revocation paths, and resource-server PDP/ABAC mapping to translate scopes into concrete, auditable permissions.
