Scenario-Based Networking Interview Questions (2026)

Layer-by-layer: (1) Layer 1: ping default gateway — if fails, check cable/link status. (2) Layer 2: arp -a to verify MAC of default gateway is learned. (3) Layer 3: ping default gateway works; ping 8.8.8.8 fails. Check routing table on PC + on default gateway. Trace route to 8.8.8.8. (4) DNS: nslookup google.com — if DNS fails but ping 8.8.8.8 works, DNS server issue. (5) Firewall: check ACLs / firewall rules at perimeter. (6) NAT: check NAT translation table (if private IP). Each layer eliminates a class of issues.

Detection: (1) anomaly detection on retrieved chunks (statistical outliers in token distribution); (2) semantic classifiers flagging adversarial intent in retrieved content; (3) output validation (does response match expected format/schema?); (4) provenance tracking (which document caused which response token?). Mitigation: (1) strict input/output schemas; (2) separate retrieval from generation context; (3) adversarial training with known prompt injection corpora; (4) human-in-the-loop for high-risk responses; (5) sanitise retrieved content before context injection.

Layered approach: (1) Pre-input PII redaction (Presidio, AWS Comprehend PII); (2) System prompt restrictions (explicit 'never repeat user data, system info'); (3) Output PII filters before return; (4) Training/fine-tuning data audit — remove PII before training; (5) RAG context filtering — strip PII from retrieved chunks; (6) Audit logs for prompt/response pairs (with PII redaction in logs); (7) Periodic data leakage testing using known sensitive prompts. No single layer is sufficient — defence in depth required.

Methodology: (1) Reconnaissance — identify model type, training data, features; (2) Black-box probing — submit transactions across normal/borderline/extreme ranges, observe decisions; (3) Membership inference — determine if specific training samples were used; (4) Model extraction — query repeatedly to clone decision boundary; (5) Adversarial example generation — craft transactions that bypass while remaining in 'plausible' range; (6) Evasion via feature engineering — modify behavioural patterns to avoid detection; (7) Report findings with severity ratings + mitigations. Tools: ART (Adversarial Robustness Toolbox), CleverHans, Counterfit.

Architecture layers: (1) Data ingestion — normalise logs from firewalls, endpoints, cloud (Splunk/Elastic). (2) Feature engineering — time windows, behavioural profiles per user/host, statistical aggregations. (3) Model layer — three approaches: (a) supervised classifiers for known attack patterns (XGBoost on labelled incidents), (b) unsupervised anomaly detection (isolation forest, autoencoders) for novel threats, (c) sequence models (LSTMs/transformers) for multi-stage attack detection. (4) Alert layer — confidence-scored alerts with explainability (SHAP values). (5) Feedback loop — analyst feedback retrains model, reduces false positives over time. Production tools: Splunk MLTK, Microsoft Sentinel UEBA, Darktrace, Vectra.

Threat: compromised pre-trained model from HuggingFace/PyPI introduces backdoor (e.g., specific input triggers malicious behaviour). Defence layers: (1) Model registry with signed checkpoints (Sigstore, AWS SageMaker Model Registry signed); (2) SBOM (Software Bill of Materials) for ML pipelines including model + framework + data sources; (3) Reproducible training (deterministic seeds, locked dependencies); (4) Model scanning tools (HiddenLayer Model Scanner, Protect AI ModelScan); (5) Behavioural testing on adversarial input batteries before production; (6) CI/CD integration scanning every model artifact pre-deploy. Real incidents: 2024 PyTorch supply chain attack via dependency hijacking — these are real, not theoretical.

5-phase methodology: (1) Reconnaissance — what's the system prompt? what's the model? what's the deployment context? (2) Bypass attempts — direct prompt injection, persona role-play, encoding tricks (base64, leet-speak), context overflow. (3) Information extraction — probe for system prompt leakage, training data extraction, customer data leaks. (4) Tool/agent abuse — if chatbot has plugins/tools, attempt to invoke unauthorised actions. (5) Reasoning manipulation — false premises, loaded contexts, multi-turn drift. Document each finding: attack chain, severity (CVSS-like), business impact, mitigation recommendation. Tools: Garak, PyRIT, custom LLM-driven attack generators. Time investment: typically 2-3 weeks for a meaningful red team engagement.

Multi-source approach: (1) Passive sources — amass enum -passive, subfinder, assetfinder. Pull from CT logs, DNS aggregators, search engines. (2) Active resolution — massdns to verify which subdomains have live IPs. (3) Permutation/wordlist — gobuster vhost mode + custom wordlists for missed subdomains. (4) JS file analysis — extract subdomain references from target's JavaScript with subjs + mantra. (5) Combine + dedupe → final subdomain list. Critical: assets like staging/dev/admin subdomains often have weaker security than primary domain.

(1) Identify vulnerable function (strcpy, gets, sprintf without bounds checking). (2) Send oversized input to crash binary (segfault). (3) Find offset — pattern_create.rb + pattern_offset.rb (Metasploit utilities) to find exact offset where RIP is overwritten. (4) Identify register state — RAX/RDI/RSI controlled, look for jump targets. (5) Find ROP gadgets with ROPgadget or Ropper — chain to call mprotect (make stack executable) or system('/bin/sh') directly. (6) Bypass ASLR via info leak (printf format string, libc address leak). (7) Bypass stack canaries via brute-force or info leak. Modern exploitation requires bypassing DEP, ASLR, canaries, CFI — pure stack overflow into shellcode is rarely viable on hardened targets.

(1) Static analysis — APKTool to decompile, jadx-gui to read decompiled Java/Kotlin. Search for hardcoded secrets, API endpoints, weak crypto. (2) Dynamic analysis with Frida — hook root detection, certificate pinning, encryption functions to bypass and observe. (3) MITM proxy — Burp Suite + bypass cert pinning (Frida hooks for SSLPinningChecker). (4) API security testing — once MITM established, fuzz APIs for OWASP API Top 10 (broken auth, BOLA/IDOR, mass assignment). (5) Local data — extract /data/data/com.bank.app/, look for unencrypted SharedPreferences, SQLite databases, cached files. (6) Insecure IPC — exposed Activities, Services, Content Providers. Banking apps have high bounty payouts ($10K-25K) — invest in mastering this niche.

(1) IAM enumeration — list users/roles, identify over-privileged service accounts. Tools: ScoutSuite, Prowler, pacu. (2) S3 bucket enumeration — public buckets, leaked AWS credentials in CI/CD logs. (3) EC2 metadata access — SSRF in deployed app → http://169.254.169.254/latest/meta-data/iam/security-credentials/ → temporary creds. (4) Lambda function review — environment variable secrets, IAM role misuse. (5) Cross-account assume-role abuse — chain accounts together. (6) GuardDuty / CloudTrail evasion — operate during quiet windows, use diverse user agents. Required cert: AWS Cloud Practitioner minimum, Solutions Architect Associate strongly recommended for context. Tools: pacu, ScoutSuite, Prowler, CloudGoat (vulnerable lab).

OWASP Testing Guide / PTES + custom adaptation: (1) Pre-engagement — scope, rules of engagement, emergency contacts, written authorisation. (2) Reconnaissance — passive then active. (3) Threat modelling — identify high-value assets, likely attack paths. (4) Vulnerability identification — automated (nmap NSE, nuclei) + manual (Burp Suite, custom testing). (5) Exploitation — controlled exploitation, evidence collection. (6) Post-exploitation — privilege escalation, lateral movement (where in scope). (7) Reporting — executive summary + technical findings + business impact + reproduction steps + recommendations. (8) Re-test after fixes. Time allocation: 30% recon, 40% exploitation, 30% reporting (reporting is the deliverable, don't shortcut it).

T1059 = adversary using Bash, PowerShell, cmd.exe, Python for execution. Investigation steps: (1) Get full command line from EDR/Sysmon Event 1; (2) Identify parent process (was PowerShell launched from Word? = malicious; from Sysmon Event 1 ParentImage); (3) Check for encoded commands (PowerShell -EncodedCommand → base64 decode); (4) Check network connections from process (Sysmon Event 3); (5) Check files written (Sysmon Event 11); (6) Hash + reputation check on any artifacts. Sub-techniques: T1059.001 PowerShell, T1059.003 Windows Command Shell, T1059.006 Python — investigation differs slightly per shell.

NIST IR lifecycle: (1) Preparation — done before incident: tools, runbooks, contacts, comms plan; (2) Detection + Analysis — confirm true positive, scope (1 host vs lateral spread), severity classification; (3) Containment — isolate affected host(s) via EDR, block C2 IPs at firewall, disable affected accounts; (4) Eradication — remove malware, patch initial entry vector; (5) Recovery — restore from clean backup, monitor for re-infection; (6) Lessons Learned — root cause analysis, runbook updates, detection rule additions. Time-criticality matters: aim for containment within 1 hour of confirmation for ransomware.

Multi-source investigation: (1) Active Directory — query event 4740 (account lockout) for source workstation/IP; (2) Filter logs from that workstation — what's authenticating? Could be: cached credentials on phone/Outlook/RDP after password change; service running with old credentials; brute-force attack from compromised host. (3) PowerShell Get-WinEvent or Splunk SPL: index=ad EventCode=4740 user=affected_user | stats count by Caller_Computer_Name. (4) On caller machine: check scheduled tasks, services, drive mappings using old creds. (5) Check for actual brute force: many failed authentications from external IP = compromised user, not just 'forgot password' lockout.

(1) Hypothesis: 'Adversary may be using PsExec or remote service creation for lateral movement'. (2) Data sources needed: Windows Event Logs (5145 Network Share, 7045 Service Install), Sysmon Event 1 (process creation with psexec.exe / cmd.exe with /sc command), authentication events (4624 logon type 3 from internal IPs). (3) Build SPL: index=win EventCode=7045 OR (EventCode=4624 LogonType=3 src_ip=internal_subnet) | stats count values(EventCode) by src_ip, dest_ip. (4) Identify outliers — workstations rarely host services, unusual lateral connections. (5) Pivot to confirmed positives — investigate full attack chain. (6) Document findings → create detection rule for repeat alerts.

Automotive cybersecurity interviews focus on ISO/SAE 21434 compliance, CAN bus security, V2X communication protocols, and OTA update integrity. Expect questions on intrusion detection for in-vehicle networks, secure boot mechanisms, and threat modeling for connected vehicles. Bangalore employers like Bosch, Continental, and Harman test knowledge of UNECE WP.29 regulations, automotive SIEM integration, and firmware signing. You'll face scenarios on ECU hardening, cryptographic key management for telematics, and incident response for fleet-wide attacks. Interview tip: Mention familiarity with tools like CANalyzer or Wireshark for CAN traffic analysis — automotive OEMs value hands-on protocol debugging experience.