Staff-Level Penetration Tester Interview Preparation Guide - Spotify

First, I’d validate the new priority with leadership so I understand what changed and why. Then I’d compare it against the current plan and identify which work still supports the new goal, which work should pause, and which work should stop entirely.

Next steps:

• Reframe the plan around the new business objective
• Call out schedule, scope, and staffing impacts clearly
• Align with managers and key partners before announcing broadly
• Communicate to the team in a direct but calm way

I’d be explicit that the change is a business decision, not a judgment on the team’s work. That helps protect morale. I’d also acknowledge the effort already invested and explain what is being preserved, so people don’t feel like their work was wasted.

Finally, I’d reset expectations with stakeholders and set a short checkpoint to reduce confusion. The main goal is to move quickly, but with enough context that the team can reorient without losing confidence.

Worked example
Say a team is three weeks into building an internal analytics dashboard when leadership announces the company is deprioritizing internal tooling in favor of a customer-facing reporting feature. I'd first confirm with the sponsor that the dashboard is genuinely deprioritized rather than just delayed, then compare the two plans: the dashboard's data-pipeline work turns out to be directly reusable for the new feature, so that portion continues, while the dashboard-specific UI work pauses. In the team update I'd say something like: "Leadership has shifted priority to the customer-facing reporting feature this quarter. The pipeline work you've already built carries over directly, so that effort isn't wasted, but we're pausing the dashboard UI until the new feature ships. This is a business-priority change, not a reflection on the work." That gives the team a concrete before-and-after instead of an abstract instruction to "reframe the plan."

Brief definitions

• Reverse shell: compromised host initiates an outbound connection to attacker listener; shell traffic runs over that session.
• Bind shell: compromised host opens/listens on a port and attacker connects in to issue commands.

How firewalls/NAT/egress filtering affect them

• Reverse shell: more likely to succeed across NAT/firewalls because most environments allow outbound TCP/UDP (HTTP/HTTPS). Egress filtering or strict proxying can block it or force use of allowed ports/protocols (e.g., 443 over TLS).
• Bind shell: blocked by host/network ingress restrictions, NAT without port forwarding makes direct inbound connections impossible; requires open ports or pivoting.

When to prefer each

• Reverse shell preferred: internal networks, machines behind NAT/firewalls, Windows endpoints with strict inbound rules — use when outbound is allowed. Example: using staged payload contacting attacker on 443/HTTPS.
• Bind shell practical: when you have direct network access (e.g., same LAN segment, cloud instance with public IP and misconfigured security group) and you want simpler setup without client-initiated callbacks.

Hardening & defensive signals

• Hardening: egress filtering, proxy enforcement, host-based firewall blocking unusual outbound ports, application allowlisting, and endpoint detection/response (EDR) rules.
• Detection signals: sudden outbound connections to rare IPs/ports, long-lived encrypted sessions from client to unfamiliar hosts, creation of listening processes on uncommon ports, new services, suspicious parent/child process chains (cmd/python spawning network sockets), abnormal netstat/tcpdump artifacts, IDS/IPS alerts for reverse-shell-like patterns.

I led assessments where reverse shells via HTTPS callbacks bypassed perimeter NAT; after remediation, egress proxying and EDR process lineage stopped those callbacks.

Direct answer

Security groups, network access control lists (NACLs), and host-based firewalls (iptables/firewalld/Windows Firewall) form a layered defense specifically because each one fails differently: a NACL is stateless and subnet-wide, a security group is stateful and per-instance, and a host-based firewall is the last line of defense running on the instance itself, so a misconfiguration in any one layer is still caught by the other two. The correct enforcement order, from the network edge inward, is NACL first, then security group, then host-based firewall, and each layer should carry a genuinely different kind of rule, not the same rule repeated three times.

Structured elaboration

Enforcement ordering and why it is stateless-to-stateful. Traffic entering a subnet is evaluated by the NACL first (stateless: it evaluates inbound and outbound independently, in numbered rule order, and does not track connection state, so a rule permitting an inbound request does not automatically permit its response; the response traffic needs its own explicit outbound rule, commonly on a high ephemeral port range such as 1024-65535 for the client's return traffic). Traffic that passes the NACL reaches the security group (stateful: an allowed inbound connection automatically permits its return traffic, no separate outbound rule needed for the response, and a security group supports allow-only rules, unlike a NACL, which supports both allow and deny). Traffic that reaches the actual instance is finally subject to the host-based firewall, evaluated by the operating system itself, entirely independent of the cloud provider's network layer.

What belongs at each layer, with concrete example rules.

Blast-radius framing. A NACL misconfiguration affects every instance in the subnet; a security-group misconfiguration affects only the instances attached to that specific group; a host-based firewall misconfiguration affects only that one host. This is precisely why the layered order matters for containment, not just for defense: the more likely a control is to be broadly misconfigured (a subnet-wide NACL change made carelessly), the more instances a mistake there exposes, so the security group and host firewall layers exist specifically to limit how far that mistake actually reaches.

Placement, scalability, and performance trade-offs. NACLs are cheap to evaluate (a small, ordered rule list per subnet) but coarse-grained, so they scale poorly as a tool for fine per-service rules; using them for anything beyond broad subnet-level allow/deny quickly becomes an unmanageable, hard-to-audit rule list. Security groups scale well for fine-grained, per-service rules (referencing another security group by ID rather than a CIDR, so the rule set does not need to change as instances scale up or down within that group) but do not, by themselves, protect against a misconfiguration inside the group's own membership. Host-based firewalls carry the most operational overhead per instance (configuration drift across a fleet is a real risk unless centrally managed via a configuration management tool) but are the only layer that survives a cloud-network-layer misconfiguration entirely.

Concrete lateral-movement example: application tier to database tier. A three-tier application's database should be reachable only from the application tier, never directly from the public internet or from the load balancer. At the NACL layer, the database subnet permits inbound only from the application subnet's CIDR range on the database port. At the security-group layer, the database's security group permits inbound only from the application tier's specific security group (by reference, not CIDR) on that same port, which is more precise than the NACL's subnet-wide rule and does not need updating as application instances scale. At the host-firewall layer, the database instance's own firewall additionally denies inbound from anything other than localhost and the expected application-tier IP range, so that even if the security group were ever mistakenly widened (an entirely plausible operational mistake), an attacker who compromised a different instance inside the same application subnet still cannot reach the database host directly without also passing the host's own firewall.

Route tables and ephemeral outbound ports. A subnet's route table determines whether traffic can reach a NACL boundary at all (a private subnet's route table, with no route to an internet gateway, is itself a control independent of the NACL and security group rules); this is why route-table review belongs alongside NACL and security-group review, not as a separate exercise, since a subnet with no route out cannot be exploited over that path regardless of what the NACL or security group technically permits. The ephemeral-port handling detail matters specifically for NACLs: because they are stateless, an inbound rule allowing a client's request on port 443 needs a corresponding outbound rule permitting the response traffic on the client's ephemeral port range, a detail security groups handle automatically through statefulness but NACLs do not.

Hub-and-spoke filtering scope. In a hub-and-spoke topology, this same three-layer model applies per spoke, but the NACL's subnet-wide scope becomes relevant at a larger granularity: a NACL misconfiguration in a spoke's subnet affects every instance in that one spoke, while a security-group misconfiguration remains scoped to the specific instances in that group regardless of which spoke they sit in; the hub's own centralized firewall or inspection appliance (if present) adds a fourth, topology-level layer above all three discussed here, filtering traffic between spokes before it ever reaches a specific spoke's own NACL.

Worked example

Applying all three layers to the application-to-database lateral-movement example above with concrete rule direction: the database subnet's NACL permits inbound TCP 5432 (PostgreSQL) from the application subnet's CIDR only, and permits outbound on the ephemeral port range 1024-65535 back to that same CIDR (the stateless return-traffic rule); the database's security group permits inbound TCP 5432 from the application tier's security group ID only, with no explicit outbound rule needed since the security group is stateful; the database instance's own host firewall (iptables) additionally denies all inbound except from localhost and the specific application-tier subnet CIDR on port 5432. An attacker who compromises an instance in an unrelated subnet within the same virtual private cloud (VPC) is blocked at the NACL layer (wrong subnet); an attacker who compromises an application-tier instance but is not a member of the expected security group (a misconfigured instance launched outside the intended group) is blocked at the security-group layer; and an attacker who somehow satisfies both prior layers (a genuine application-tier compromise) still faces the host firewall's own independent check before reaching the database process itself.

Trade-offs and pitfalls

• The most common misconfiguration that renders this layering ineffective is treating the security group as the only layer that matters and leaving the NACL at its default allow-all, or leaving the host firewall disabled entirely "because the security group already handles it." Each layer needs its own deliberate configuration; relying on only one, even a well-configured one, collapses the defense-in-depth benefit back down to a single point of failure.
• Forgetting the NACL's ephemeral-port return-traffic rule is a specific, common operational mistake that silently breaks legitimate traffic rather than creating a security gap, which is why it is frequently discovered during troubleshooting rather than security review; understanding NACL statelessness explicitly is what prevents both the security gap and this specific operational trap.
• Security-group rules referencing another security group by ID, rather than a CIDR, are more maintainable at scale but only within the same VPC (or specifically peered/shared VPCs); a design that assumes group-reference rules work across an unrelated VPC boundary will silently fail to provide the intended access, requiring a CIDR-based or transit-gateway-aware rule instead.
• Host-based firewall configuration drift across a large fleet is a genuine, easy-to-underestimate operational cost. Without centralized configuration management (enforcing the same host-firewall baseline across every instance via infrastructure-as-code or a configuration management tool), individual instances drift from the intended baseline over time, and the "last line of defense" layer quietly stops being reliable exactly where it would matter most.

Direct answer — when to build custom tooling
I build custom tooling or PoC code when existing tools can't safely and reliably demonstrate a vulnerability, when I need repeatable automation tied to test scope, or when I must prove a novel exploitation chain to developers or defenders.

Three realistic scenarios

• Target uses a bespoke protocol or proprietary API — I write a Python client to fuzz fields and prove broken auth because off‑the‑shelf scanners don’t speak the protocol.
• Time‑bound automation for large, authenticated stateful workflows — I implement a Go microtool to orchestrate login, CSRF token handling, and payload delivery across hundreds of endpoints.
• Proof of concept for a logic flaw or chained bug — I create a minimal, well‑documented exploit that reproduces impact without destructive payloads so stakeholders can patch confidently.

Three design considerations

• Safety: default to non‑destructive actions, include rate limits, explicit flags for destructive modes, and built‑in safeguards (input validation, kill switch).
• Maintainability: modular code, clear README, dependency pinning, tests for core flows, and use common languages (Python/Go) and packaging.
• Auditability: verbose, structured logging (timestamped, redacted sensitive data), reproducible runbooks, and code comments explaining attack steps and assumptions.

I’d mention the language choice (Python for rapid PoC, Go for cross‑compiled tooling) and always align tooling scope with the engagement rules of engagement.

Immediate notification order (first minutes)

1. Incident Response / SOC
2. On-call Engineering/Platform owner for affected service
3. Customer Success / Account owner (internal)
4. Product Security / AppSec
5. Threat Intelligence / IR tooling owner

First 30-minute messages (per audience)

• Incident Response / SOC: brief title, severity (Critical: RCE), affected service & environment (production), exploitability (authenticated/unauthenticated), immediate risk (full control), current containment actions taken, ask for IR lead and runbook invocation, contact channel (phone + secure Slack), timestamped evidence summary.
• Engineering/Platform owner: affected components, precise endpoint/URL, PoC summary, commands used, suggested immediate mitigation (eg. IP block, WAF rule, process isolate, feature toggle), request for rollback/kill-switch.
• Customer Success / Account owner: concise non-alarming statement — we discovered a critical vulnerability affecting [service], actively contained, we are coordinating incident response and will provide updates. No technical details.
• Product Security/AppSec: attack vector, exploitability, logs/PoC, recommended hotspots for patching, ask to triage priority.
• Threat Intelligence: IOCs, attacker feasibility, whether to engage external monitoring.

What to avoid in early messages

• No definitive root cause claims or timelines
• No speculative language about customer data exfiltration
• No public or customer-facing statements without Legal/Comms sign-off
• Avoid technical PoC distribution to wide audience

24-hour escalation plan

• 0–2h: IR lead assembles war room; I provide full exploit lab notes, logs, PoC, and suggested mitigations.
• 2–6h: If containment incomplete, escalate to CISO and Head of Engineering with impact assessment and remediation ETA.
• 6–12h: Engage Legal and Privacy if data exposure plausible; provide evidence packet and recommended notification triggers.
• 12–24h: Executive briefing: concise impact, containment status, remediation plan, customer notification plan, regulatory requirements, and next steps. Offer myself as technical liaison for follow-ups.

Approach (brief)
Use a single pass over findings, building tickets while deduplicating using a hash map: key by CVE when present, otherwise by title+asset_ip. Map severity strings to numeric priority. This is O(n) time and O(n) space.

Code implementation

def map_findings_to_tickets(findings):
    """
    findings: list of dicts with keys:
      scanner_id, title, description, severity, cve (or None), asset_ip, evidence
    returns: list of ticket dicts with fields:
      ticket_id, scanner_id, title, description, priority (int), cve, asset_ip, evidence_list
    """
    sev_map = {"critical": 1, "high": 2, "medium": 3, "low": 4}
    seen = {}  # dedupe map -> key : ticket_dict

    for f in findings:
        # normalize key for dedupe
        key = f.get("cve") or (f.get("title","").strip().lower() + "|" + f.get("asset_ip",""))
        if key in seen:
            # merge evidence and keep highest severity (lowest numeric)
            ticket = seen[key]
            if f.get("evidence"):
                ticket["evidence_list"].append(f["evidence"])
            # choose the more critical priority (min numeric)
            ticket["priority"] = min(ticket["priority"], sev_map.get(f.get("severity","low").lower(), 4))
        else:
            ticket = {
                "ticket_id": f"{f.get('scanner_id','')}-{len(seen)+1}",
                "scanner_id": f.get("scanner_id"),
                "title": f.get("title"),
                "description": f.get("description"),
                "priority": sev_map.get(f.get("severity","low").lower(), 4),
                "cve": f.get("cve"),
                "asset_ip": f.get("asset_ip"),
                "evidence_list": [f["evidence"]] if f.get("evidence") else []
            }
            seen[key] = ticket

    return list(seen.values())

Key concepts & complexity

• O(n) time: one pass + O(1) dict ops per finding
• O(n) space for dedupe map and output

Edge cases

• Missing severity default to low, missing evidence handled, CVE casing/whitespace should be normalized upstream if needed.

As a penetration tester I'd use this to collapse duplicate scanner noise into actionable tickets, preserving evidence and prioritizing the most severe observation.

Approach (brief)
I map pen-test TTPs to MITRE ATT&CK by: enumerate actions during an engagement, assign ATT&CK tactic/technique IDs, list telemetry that would observe each action, propose concrete detection logic, and surface likely gaps so defenders can prioritize coverage.

Example: Credential Dumping (T1003)

• Telemetry sources: Windows Security/ Sysmon (ProcessCreate, ImageLoaded), LSASS memory dumps, Endpoint EDR process artifacts, PowerShell logs, Network SMB auths.
• Detection logic: alert on suspicious tools (procdump, Mimikatz) spawning from uncommon parents; high-frequency read access to lsass.exe memory; exports of lsass dump to network shares; anomalous use of comsvcs.dll or sekurlsa hooks. Correlate with privileged logins and process hashes.
• Common gaps: lack of process-memory monitoring, disabled Sysmon/ETW, no baseline for administrative tool usage, missed obfuscated/custom loaders.

Example: Lateral Movement (T1021 / T1076)

• Telemetry sources: Windows Event Logs (4624/4648), SMB/Remote Service logs, RDP logs, EDR process creation, network flow logs.
• Detection logic: alert on credentialed remote logons from workstation-to-server; non-standard admin tools used remotely (psexec, wmiexec); one host authenticating to many endpoints in short window; new service creation + remote command execution.
• Common gaps: limited east-west network visibility, missing authentication telemetry from legacy devices, deferred logging, lack of identity-transaction correlation.

Prioritize closing gaps that expose high-impact techniques first (credential access, lateral movement) by enabling Sysmon/EDR, collecting process memory events, centralizing auth logs, and tuning baselines.

Direct answer

Mentoring is voluntary, growth-oriented influence without formal accountability. Managing includes formal accountability, resourcing decisions, and real consequences. The line moves the moment a mentee becomes a direct report, because feedback that used to be optional advice now carries formal weight, and the relationship gains structural power (comp, promotion, performance record) it didn't have before.

Where the line actually is

What changes when a mentee becomes a direct report

Private growth conversations now double as input to a formal review, whether that's said out loud or not. Advice that was previously optional is now, in practice, expected to be acted on for role reasons. The relationship carries real structural power (comp, promotion, PIP, short for performance improvement plan: the formal HR process for addressing underperformance) that it didn't have as informal mentoring. The hardest part is that "helping you grow" and "evaluating you" now happen with the same person, often in the same conversation, and separating those framings requires being deliberately transparent about which one is active at a given moment, rather than assuming the mentee can tell.

Worked example

A mentee who'd been mentored informally for a while later became a direct report after a reorg. The explicit adjustment made on day one: naming that some future 1:1 time would now include performance topics, not only growth topics, and being upfront about which kind of conversation was happening in the moment, rather than letting the mentee guess which hat was on.

Trade-offs and pitfalls

A common mistake is continuing to run the relationship exactly as before once it becomes formal, without naming the shift, which reads as inconsistent or even manipulative once the mentee realizes "informal advice" now affects their review. A stronger approach names the shift explicitly rather than letting the mentee discover it the hard way. Another pitfall is using "I'm just mentoring you" framing to soften what is actually a directive, formal expectation, which blurs accountability for both sides.

Overview (one line)
A typical vulnerability assessment lifecycle is a repeatable pipeline that moves from discovery to validation and continuous monitoring; penetration testers drive technical validation while SecOps and IT own remediation and long‑term tracking.

Phases, outputs, and owners

• Asset discovery

  • Output: inventory (hosts, services, apps), CMDB updates, scope lists
  • Owner: PenTest/Red Team + IT Asset Management

• Scanning (automated)

  • Output: raw scanner findings, vulnerability feeds, CSV exports
  • Owner: SecOps/Vulnerability Team; PenTest triggers scans for engagements

• Manual verification

  • Output: validated findings, PoC notes, exploitability rating
  • Owner: Penetration Tester / Red Team

• False‑positive reduction

  • Output: cleaned finding set, annotated evidence
  • Owner: PenTest + SecOps analyst

• Contextual analysis

  • Output: business/context tags (asset criticality, exposure, compensating controls)
  • Owner: SecOps, Risk/InfoSec, Application Owners

• Prioritization

  • Output: prioritized remediation list, SLA recommendations, risk scores/KPIs (e.g., time-to-remediate)
  • Owner: Risk Management + SecOps; PenTest advises technical priority

• Remediation validation

  • Output: retest reports, ticket closure evidence, regression PoCs
  • Owner: PenTest or SecOps validator; Dev/IT implements fixes

• Continuous monitoring

  • Output: dashboards, recurring scan schedules, trending KPIs (vuln count, MTTR)
  • Owner: SecOps/SRE + Vulnerability Management

Wrap these with clear SLAs, ticketing (JIRA/ServiceNow) and executive KPIs so technical findings translate into measurable remediation outcomes.

Direct answer

Testing cross-tenant access control means treating the tenant boundary as just another parameter to attack: authenticate as tenant A's admin, then systematically substitute tenant B's resource identifiers into every endpoint that is supposed to scope data by tenant, and check whether the response genuinely enforces the boundary or only hides it in the user interface. This is insecure direct object reference (IDOR), or broken object-level access control, at the tenant granularity rather than the individual-record granularity. The fix is the same principle applied consistently: every data access must load the resource and explicitly verify it belongs to the requester's own tenant, using data loaded from the database, never a client-supplied field, backed at the architecture level by a structural boundary that does not depend on every developer remembering the check.

Structured elaboration

Testing methodology

Enumerate every endpoint that operates on a tenant-scoped resource, list, get, update, delete, built from the API surface (an OpenAPI/GraphQL schema, or manual crawling), with particular attention to admin-facing endpoints, since "administrators manage users for their own tenant" describes exactly the elevated-privilege surface where a missing tenant check has outsized impact. Create two dedicated test tenants, never test cross-tenant access control against real customer tenants, and obtain an authenticated session in each.

The core test: as tenant A's admin, substitute a resource identifier known to belong to tenant B into the request, and classify the result. Rejected is correct. Succeeding and returning tenant B's data is broken authorization, a direct IDOR. Succeeding but silently returning tenant A's own data regardless of the supplied ID can look safe at a glance but often signals the scoping happens through a code path with a different, subtler bypass elsewhere, worth probing further rather than assuming it is safe.

Test both read and write operations separately: a read-only cross-tenant view and a cross-tenant write or delete are different severities and neither protection can be assumed to imply the other. Test identifier enumerability as a separate dimension from the access-control check itself: sequential or guessable IDs let an attacker run this attack at scale without any prior knowledge, while unguessable identifiers (UUIDs) still matter once an ID leaks through another channel, a shared support ticket, a URL captured in a log, so unguessability reduces but does not eliminate the risk. Finally, test any bulk or list-style endpoint separately from its single-object counterpart; a very common gap is a singular endpoint that correctly checks tenant ownership while the array/batch variant of the same operation skips the same check per item.

Fixes

Code-level: every handler that loads a tenant-scoped resource must, after loading it, explicitly compare the loaded resource's tenant_id against the authenticated requester's tenant_id, drawn from the session or token, and reject before returning or mutating anything on a mismatch. This check has to be present on every code path that touches the resource, list, get, update, delete, and any bulk variant, not applied once centrally and assumed to propagate. Prefer scoping the query itself by tenant rather than filtering after the fact, WHERE id = :id AND tenant_id = :requester_tenant_id as part of how the resource is found, not a separate check bolted onto an unscoped lookup. This closes the class of bug where a new query path is added later and the separate check is simply forgotten, because the tenant scope is baked into the lookup itself.

Architectural: back the code-level check with a structural boundary that does not rely on every developer remembering it, database-enforced row-level security (RLS) policies keyed on a tenant context set per connection or session, or per-tenant schema isolation where scale justifies it, so that even application code which forgot the tenant filter still cannot return cross-tenant rows, because the database itself will not return them. Add automated cross-tenant access-control tests as a required part of the review for any new tenant-scoped endpoint, since this class of bug reintroduces itself continuously as the API surface grows, not as a one-time audit finding to close and forget.

Worked example

Minimal reproduction of the vulnerable and fixed patterns:

def vulnerable_get_user(requesting_admin_tenant_id, target_user_id):
    return USERS_DB[target_user_id]  # looked up by ID alone; tenant never checked

def fixed_get_user(requesting_admin_tenant_id, target_user_id):
    user = USERS_DB[target_user_id]
    if user["tenant_id"] != requesting_admin_tenant_id:
        raise Forbidden(f"admin of {requesting_admin_tenant_id} may not access {target_user_id}")
    return user

Executed against two users in two different tenants (u-100 in tenant-A, u-200 in tenant-B): an admin from tenant-A requesting their own tenant's user succeeds on both versions, as expected. The same admin requesting u-200 (tenant-B's user) succeeds on vulnerable_get_user, genuinely returning {'id': 'u-200', 'tenant_id': 'tenant-B', 'name': 'Bob'}, confirming the cross-tenant leak actually occurs, not just that the code looks wrong on inspection. The identical request against fixed_get_user raises Forbidden, confirming the tenant check blocks it.

Trade-offs and pitfalls

• Application-level checks alone are correctness-dependent on every developer getting every new endpoint right, forever. Row-level security or per-tenant schema isolation trades additional setup complexity for closing the "forgot to check" class structurally, worth the investment once the number of tenant-scoped endpoints and contributing developers grows past what code review alone reliably catches.
• A common wrong turn is fixing only the specific endpoint a test found, without auditing the rest of the API for the same pattern; if one endpoint lacked the check because of a shared helper or code pattern, other endpoints built from the same pattern very likely share the bug.
• Unguessable identifiers are not a substitute for an access-control check. "They cannot guess the ID" is not authorization; treat ID unguessability as, at best, a minor layer of defense-in-depth, never the actual control.
• A tenant_id field accepted from the client request itself, rather than derived server-side from the authenticated session, reintroduces the identical vulnerability one layer up. Always derive the acting tenant from the authenticated session or token, never from a client-supplied field, even when that field is also present in the request body for other legitimate reasons.