Scenario-Based Cyber Security Interview Questions

A zero-day is a flaw that the vendor does not know about or has not yet patched, so defenders have had zero days to fix it. Exploits for zero-days are valuable and often used in targeted attacks. Since patches are unavailable, defence relies on layered controls: EDR behaviour detection, network segmentation, least privilege, virtual patching with WAF or IPS rules, and fast patching once a fix is released.

I would explain that antivirus mainly blocks known malicious files, while most modern attacks use stolen credentials, phishing links, living-off-the-land tools like PowerShell, or cloud misconfigurations that antivirus never sees. I would map our top risks to missing controls, such as MFA, EDR, logging and backups, and use a recent real incident pattern to show business impact in downtime and regulatory reporting cost.

First, isolate the device from the network, ideally through EDR network containment, without powering it off so memory evidence is kept. Inform the incident lead and start a timeline. Check for the same indicators on other hosts, disable the user's sessions and reset credentials if needed, and identify the ransomware family from the note. Then confirm backups are intact and offline before any recovery begins.

Treat the secret as compromised immediately, even if the commit is removed, because public repos are scraped within minutes. Rotate the password and any related keys, check database logs for unknown logins since the commit time, and remove the secret from git history. Then fix the root cause by moving secrets to a vault or cloud secret manager and adding secret scanning to pre-commit hooks and the CI pipeline.

I would support the goal but plan the rollout to avoid breaking business work. First, find who genuinely needs USB, such as field engineers, using endpoint logs. Then apply a device control policy through EDR or Intune that blocks mass storage by default, allows approved encrypted devices by serial number, and logs exceptions. Communicate the change, pilot it with one department, then enforce company wide.

CVSS alone is not enough. I combine severity with exploitability and exposure: check the CISA Known Exploited Vulnerabilities list and EPSS score, whether the asset is internet facing, and how critical the business data on it is. Internet-facing systems with known exploited flaws are fixed first, often within days. Internal low-severity findings go into normal patch cycles. Group fixes by patch to reduce effort.

Key DNS attacks are cache poisoning, which inserts false records; DNS tunnelling, which hides data or command traffic inside queries; domain hijacking through registrar account takeover; and DNS amplification DDoS. Defences include DNSSEC to sign records, protective DNS resolvers that block malicious domains, monitoring for long or high-entropy subdomains, registrar lock with MFA, and rate limiting open resolvers.

ARP has no authentication, so an attacker on the same LAN can send fake ARP replies linking their MAC address to the gateway's IP. Victims then send traffic through the attacker, enabling man-in-the-middle interception. Defences include Dynamic ARP Inspection with DHCP snooping on switches, port security, network access control, and encrypting traffic end to end with TLS so intercepted data is useless.

Egress filtering controls outbound traffic, allowing only needed destinations and ports. It blocks malware call-backs, data exfiltration and servers reaching the internet directly. Many networks allow all outbound traffic because it is easier and legacy apps have undocumented dependencies. A practical approach is forcing web traffic through a proxy, blocking direct outbound from servers, and allowing exceptions only with business justification.

Database servers rarely need internet access, so this is suspicious. I would check the destination's reputation and WHOIS, look at flow data for volume and duration, and identify the process making the connection using EDR. Then I review recent logins, scheduled tasks and new binaries on the server. If data volume is large or the process is unknown, I contain the host and escalate as a possible exfiltration.

First check the firewall logs for denied traffic from the affected users or servers around the change time. Compare the change ticket with actual app requirements, since apps often use extra ports or dependencies. Use packet capture or a test connection to confirm. Then add a narrow rule for the real need, not an any-any rule, and update documentation so the next change does not repeat the problem.

Unused rules expand attack surface and slow audits. I would export rule hit counts, confirm no seasonal apps like year-end batch jobs depend on them, and contact rule owners listed in tickets. Rules with no owner are disabled first, not deleted, and monitored for a month. After that they are removed. I would also add rule expiry dates and quarterly reviews to the change process.

Confirm it is an attack and not a traffic spike by checking request patterns, user agents and source spread. Enable or tighten the CDN or WAF bot protection and rate limits on targeted URLs, add challenge pages for suspicious clients, and cache heavy pages. Inform the ISP or DDoS provider and management. After the attack, review logs, tune rules and update the runbook.

I would start by inventorying applications and who uses them, then pick a low-risk app group for a pilot with an identity-aware proxy or ZTNA service. Integrate it with the identity provider, enforce MFA and device posture checks, and monitor access logs. Expand app by app, keep the VPN for legacy needs during transition, and retire it once every app is covered and tested.

Guest traffic is not properly isolated, likely because the guest SSID shares a VLAN with internal devices or the firewall allows inter-VLAN routing. Fix by placing guests on a separate VLAN with internet-only access, applying ACLs that deny all RFC 1918 internal ranges, and enabling client isolation on the wireless controller. Then test from a guest device and document the design.

Large quantum computers could break RSA and elliptic curve cryptography using Shor's algorithm. NIST published post-quantum standards in 2024: ML-KEM for key exchange, and ML-DSA and SLH-DSA for signatures. Attackers can harvest encrypted traffic now and decrypt it later, so long-lived sensitive data is at risk. Organisations should inventory cryptography, prefer crypto agility, and test hybrid key exchange that browsers already support.

First renew and deploy the certificate to restore service. For prevention, build a certificate inventory from scanning and CT logs, automate issuance and renewal with ACME where possible, and set alerts at 30, 14 and 7 days before expiry to a team mailbox, not an individual. Assign an owner per certificate and add expiry checks to monitoring dashboards, since shorter lifetimes are coming.

MD5 is fast and broken, so these hashes can be cracked quickly if leaked. Recommend Argon2id or bcrypt with proper cost settings. To migrate without forcing resets, wrap existing hashes: compute Argon2id over the MD5 value now, and on next login replace it with a direct Argon2id hash of the password. Also check whether the database was ever exposed, and enforce MFA.

I would advise against it. Custom cryptography almost always has flaws that experts would find, and it fails audits. Instead, use well-reviewed libraries such as libsodium, platform crypto APIs, or the cloud KMS with AES-GCM and envelope encryption. I would offer to help choose the right library and key management design, and include a security review in the feature's pull request.

Treat it as compromised. Revoke the certificate with the CA, issue a new one with the key generated and stored in an HSM or cloud key service, and restrict signing to the build pipeline. Search for any binaries signed with the old key after the exposure time and investigate them. Remove the file, check drive access logs to see who opened it, and update the key handling policy.

This pattern suggests brute force or password spraying that succeeded. Check source IPs, location and logon type, and whether MFA was used for the success. Review what the account did after login, such as mailbox rules, file access or new tokens. If suspicious, disable the account or revoke sessions, reset the password, block source IPs and check whether the same IPs targeted other accounts.

Office apps rarely start PowerShell, so this usually means a malicious macro or document exploit. Decode the Base64 command to see what it does, check the process tree and any network connections for downloads, and find the source email. Isolate the host through EDR, block the sender and URLs, search for the same email in other mailboxes and hunt for the same command line elsewhere.

Analyse alert data to find the top noisy rules, which usually create most of the volume. Tune them with context and allowlists, or turn low-value ones into dashboards. Add enrichment and automated closure for known benign patterns using SOAR, group related alerts into incidents and add risk-based alerting that scores entities. Track false positive rate per rule weekly and require testing for new rules.

This is an impossible travel alert. First rule out benign causes like corporate VPN, cloud proxy egress or mobile networks. Check device IDs, user agents and MFA results for both logins. If the second login is from an unknown device without MFA, or followed by mailbox rule creation or data download, revoke sessions, reset credentials, review MFA methods and contact the user through a separate channel.

Silent log gaps create blind spots where attacks go undetected, and they can also break compliance. Raise it as a priority issue, check the forwarder or agent health, network path, licence limits and parsing errors, and restore ingestion. Check whether the gap overlapped any suspicious activity. Then add log source health monitoring that alerts when expected volume drops, so gaps are found in hours, not days.

Legal advises on regulatory notification, such as CERT-In within six hours and the Data Protection Board and affected people under the DPDP Act, contractual duties to clients, evidence handling and privilege. Communications manage messaging to customers, staff, media and investors so statements are accurate and consistent. Technical teams should involve them early, because poor communication can cause more damage than the incident itself.

Activate the incident plan and set up a war room with a separate communication channel. Contain by isolating affected segments, disabling compromised accounts, and blocking known command and control. Preserve evidence from a few hosts. Identify initial access and scope, including data theft. Verify offline backups, rebuild from clean images, and restore by business priority. Report to CERT-In within six hours and involve legal before any ransom discussion.

Contact the bank immediately to try to stop or recall the transfer; speed matters most. Report to the cybercrime portal and police. Investigate the email: was the CEO mailbox compromised or spoofed? Check sign-in logs, forwarding rules and other targeted staff. Reset credentials, enforce MFA and DMARC, and add a call-back rule for payment changes. Include legal and management throughout.

Do not just delete it. Capture the file, web logs and a memory image if possible, then identify when it was created and which request uploaded it. Search logs for commands executed through it and lateral movement from the server. Contain by isolating the server or blocking the path at the WAF, then patch the vulnerable application, rebuild from a clean image and rotate any credentials stored on it.

Treat it as a potential insider incident and involve HR and legal before contacting the employee. Preserve evidence such as DLP alerts, proxy logs, endpoint file activity and cloud app logs, and document what data was involved and its sensitivity. Restrict the user's access as advised. Legal decides on next steps, such as requesting deletion with an undertaking. Then improve DLP and offboarding controls.

Search the hash, file name and parent process across all endpoints, and look for related indicators like network destinations and persistence mechanisms. Build a timeline to find patient zero and the delivery method, for example an email attachment or a compromised software update. Group affected hosts by criticality, isolate them, and check whether any credentials were stolen to plan resets broadly.

Deactivate the key immediately and check who owns it. Review cloud audit logs for every action taken with it, such as new instances, users, roles or policy changes, because attackers often create persistence. Terminate unauthorised resources, delete created users and keys, and check billing impact. Then find how it leaked, move workloads to roles with short-lived credentials and enable budget and anomaly alerts.

Service accounts and API keys often have broad privileges, never expire, are shared among teams and are excluded from MFA. Machine identities now outnumber human ones in cloud environments. Risks include hardcoded secrets and silent abuse. Controls are an inventory with owners, least privilege, managed identities or workload identity federation instead of static keys, secret rotation, and monitoring for interactive logins.

This is MFA fatigue. Enable number matching and show app and location context in push requests, limit the number of prompts, and alert on repeated denials. Move high-risk users and admins to phishing-resistant methods such as FIDO2 keys or passkeys. Train users to report unexpected prompts. Also revoke the attacker's sessions and review what they accessed.

Disable the accounts immediately after confirming with HR, then check each for recent logins, since any use after the exit date is a potential incident. Find the root cause, usually manual offboarding or apps not connected to SSO. Integrate the HR system with the identity platform for automatic disabling, connect apps to SSO and SCIM provisioning, and run monthly orphan account reports.

Shared accounts break accountability and are hard to rotate. Give each person an individual named account with least privilege, and provide admin access through PAM with just-in-time approval and session recording. Store the remaining break-glass credential in the vault with alerts on use. Use read-only roles for daily troubleshooting. Roll out with the team so it does not slow urgent fixes.

Review the details: unfamiliar location, anonymous IP, leaked credentials or impossible travel. Check what happened after sign-in, such as MFA method registration, mailbox rules or data downloads. If compromise is likely, revoke sessions, reset the password, remove unknown MFA methods and contact the user out of band. Then confirm policies require MFA or block high-risk sign-ins automatically.

Start with assessment: their AD health, privileged accounts, trust relationships, MFA coverage and any signs of compromise. Avoid creating a full two-way forest trust early, as it can import their risks. Prefer bringing users into your cloud identity provider with B2B access or migration, with conditional access. Reset privileged credentials, apply your tiering model, and migrate application by application.

Cloud VMs can query a local metadata endpoint at 169.254.169.254 to get instance details and temporary role credentials. If an application has a server-side request forgery flaw, an attacker can make it fetch these credentials. AWS IMDSv2 requires a session token obtained with a PUT request and limits hops, which blocks most SSRF abuse. Enforce IMDSv2 and give instance roles minimal permissions.

Block public access on the bucket immediately and confirm with the owner whether any public access was intended. Check access logs and CloudTrail data events, if enabled, to see who downloaded files and when. If personal data was accessed, start the incident and breach notification process with legal. Then enable account-level block public access, add a preventive guardrail and alert on policy changes.

Give them freedom inside guardrails. Provide sandbox accounts where they have broad rights, but production changes go through IaC pipelines with scanning and review. Use permission boundaries and SCPs to block dangerous actions like disabling logging or making resources public. Offer pre-approved modules for common patterns. This keeps speed high while preventing the riskiest mistakes.

Isolate the instance by changing its security group to a quarantine group with no traffic, and snapshot its volumes for analysis. Check how it was compromised: exposed SSH, vulnerable app or leaked key. Review CloudTrail for actions by its instance role. Terminate and rebuild from a clean image, rotate secrets the instance could access, and fix the root cause, such as closing public ports.

I would require a landing zone with separate accounts, Indian region hosting for data residency, private networking with no public database endpoints, WAF and DDoS protection, customer managed KMS keys, PAM for admin access, central immutable logging to the SIEM, CSPM against CIS benchmarks, vulnerability scanning in CI, and a tested backup and disaster recovery plan. All mapped to RBI and audit requirements.

Capture the pod spec, image digest, logs and runtime alerts before deleting anything. Check how it got in: a vulnerable app, a compromised image in the registry or an exposed dashboard or kubelet. Review Kubernetes audit logs for who created the workload and what service account it used. Cordon affected nodes, rotate service account tokens and secrets, patch the entry point and enforce image signing.

SOC 2 is an attestation report by an independent auditor on a service organisation's controls against the AICPA Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. A Type I report checks control design at a point in time; a Type II checks operating effectiveness over a period, typically 6 to 12 months. Indian SaaS companies selling to US customers commonly need SOC 2 Type II.

Get leadership sponsorship and define the ISMS scope. Run a gap assessment against clauses and Annex A, then do the risk assessment and build the risk treatment plan and Statement of Applicability. Write core policies, implement missing controls, and train staff. Collect evidence for a few months, run an internal audit and management review, fix findings, then book stage 1 and stage 2 audits.

Risk acceptance is a business decision, but it must be informed. I would document the risk, likely impact, cost of fixing and compensating controls, and confirm it exceeds or meets risk appetite. If it is high, escalate to the right authority, such as the CISO or risk committee, for formal sign-off with an expiry date. I record it in the risk register and review it on schedule.

Acknowledge the finding and agree a remediation plan. Immediately run the overdue reviews for in-scope systems, prioritising privileged access, and revoke unneeded access. Find the cause, such as no owner or a manual process, and fix it by assigning owners, automating campaigns in the IGA tool and adding reminders and escalations. Provide evidence of completed reviews to close the finding.

Classify the vendor as high risk. Review their security questionnaire, ISO 27001 certificate or SOC 2 Type II report, data location, subprocessors, encryption, access controls and incident response capability. Under the DPDP Act, we remain responsible as data fiduciary, so the contract needs data processing terms, breach notification timelines, deletion on exit and audit rights. Track any gaps with deadlines.

I would avoid a single score and present risk in business terms: the top five cyber risks, such as ransomware and third-party breach, with likelihood, impact and trend. Show maturity against NIST CSF 2.0 with current and target levels, key metrics like MFA coverage, patch timeliness and incident response times, and the investments needed to close gaps. Keep it to a few slides.