All levels · fresher-friendly · 43 questions with answers
These are the questions that actually come up in Indian cyber security screening rounds — at service companies, product firms and SOC providers. Each answer is written the way you should say it out loud: short, concrete, and with the trade-off named. Work through them, then practise speaking them against an AI interviewer.
You'll answer these out loud, under time pressure, with an interviewer asking follow-ups. Do a free 5-question AI mock interview and get scored feedback in minutes — no card needed.
Start free mock interviewAlmost every interview opens here. Get these crisp and you buy goodwill for the harder rounds.
Confidentiality, Integrity and Availability — the three properties every security control protects. Encryption protects confidentiality, hashing and signing protect integrity, and redundancy or DDoS protection protects availability. A good follow-up answer names the tension: adding strict confidentiality controls often costs availability, so you pick based on what the business loses most from.
A vulnerability is a weakness (unpatched Apache). A threat is an actor or event that could exploit it (a ransomware crew scanning the internet). Risk is the combination plus impact — the chance that this threat hits this vulnerability and what it costs you. Risk is what management funds; the other two are technical facts.
Symmetric uses one shared key (AES) and is fast, so it encrypts the actual data. Asymmetric uses a key pair (RSA, ECC) and is slow, so it's used to exchange the symmetric key and to sign. TLS uses both: asymmetric for the handshake, symmetric for the session.
Hashing is one-way — you cannot recover the input. It's used for password storage and integrity checks. Encryption is reversible with a key. For passwords you don't just hash: you use a slow, salted algorithm like bcrypt or Argon2 so that a leaked database can't be brute-forced cheaply.
A salt is a random value stored with each password hash. It makes identical passwords hash differently, which kills rainbow-table attacks and stops an attacker from spotting that 400 users share the same password.
Authentication proves who you are (password, MFA, certificate). Authorisation decides what you're allowed to do once you're in (RBAC, policies). Most real breaches escalate because authorisation was too broad, not because authentication failed.
Layering controls so no single failure is fatal: perimeter filtering, network segmentation, endpoint protection, least privilege, logging and backups. The test question behind it is whether you assume any one control will eventually fail — you should.
Every user, service and process gets only the access it needs, for only as long as it needs it. In practice that means role-based access, just-in-time admin elevation, and periodic access reviews to remove privilege that people accumulated when they changed teams.
Never trust based on network location. Every request is authenticated, authorised and encrypted, whether it comes from the office LAN or a café. Practically: strong identity, device posture checks, micro-segmentation and continuous verification rather than a single VPN gate.
An alert that flags benign activity as malicious. They matter because analyst time is the scarcest resource in a SOC — a noisy rule burns hours and trains people to ignore the console, which is how real alerts get missed.
DNS resolution, TCP handshake, TLS handshake, HTTP request, response, render. The security version names what can go wrong at each step: DNS spoofing, SYN floods, certificate mis-issuance or downgrade, injection and XSS in the response. Interviewers use this to see how deep your mental model goes.
TCP is connection-oriented with a handshake and ordering; UDP is fire-and-forget. UDP's lack of handshake makes it trivially spoofable, which is why DNS and NTP amplification DDoS attacks use it. TCP has its own abuse — SYN floods exhaust the connection table.
A traditional firewall filters on IP, port and protocol. An NGFW adds application awareness, user identity, TLS inspection and integrated IPS, so it can allow "Salesforce" rather than "443 to this range".
An IDS detects and alerts, sitting out of band. An IPS sits inline and can drop the traffic. IPS is stronger but riskier — a false positive becomes an outage, so tuning matters more.
Splitting the network into zones with controlled traffic between them. When an attacker lands on a user laptop, segmentation means they cannot reach the database subnet without crossing a policy point that logs and can block them. It converts a breach into an incident.
The attacker relays traffic between two parties while reading or modifying it. TLS defeats it with certificate validation — the server proves it owns the domain through a CA-signed certificate — plus integrity checks on every record. It fails when clients skip validation or trust a rogue CA.
It encrypts traffic between the client and a gateway. It does not protect you from malware on the endpoint, phishing, a compromised destination server, or an attacker who already has valid credentials — a common follow-up trap.
3389 (RDP), 445 (SMB), 22 with password auth, 23 (Telnet), 1433/3306/5432 (databases), 5900 (VNC), 6379 (Redis, often unauthenticated). Say why: these are directly authenticating services with a long history of brute force and pre-auth RCE.
User input is concatenated into a query so the attacker changes its meaning and reads or writes data they shouldn't. Prevention is parameterised queries or prepared statements — not input sanitisation, which is a fragile second line. Add least-privilege database accounts so injection doesn't hand over the whole schema.
Cross-site scripting runs attacker JavaScript in another user's browser. Stored XSS is persisted server-side, reflected XSS comes back in the response to a crafted link, and DOM-based XSS never touches the server — the client writes untrusted data into the DOM. Fix with context-aware output encoding plus a Content Security Policy.
CSRF makes a logged-in user's browser send an unwanted request using their cookies; the attacker never reads the response. XSS runs code in the victim's page and can read everything. Defend CSRF with anti-forgery tokens and SameSite cookies.
A community list of the most critical web application risks. Broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, identification and authentication failures. Broken access control has been number one because it's logic, not a library you can patch.
Server-side request forgery — the application fetches a URL you control, so you make it call internal services like cloud metadata endpoints. It's severe in cloud environments because the metadata service can hand over credentials. Defend with allow-lists, blocking link-local ranges, and IMDSv2.
Argon2id or bcrypt with a per-user salt and a work factor tuned to your hardware. Never MD5 or SHA-256 alone — they're fast, which is exactly wrong for passwords. Add MFA so a leak isn't game over.
Building security into each stage instead of testing at the end: threat modelling in design, SAST and dependency scanning in CI, DAST in staging, secrets scanning on commit, and a defined process for triaging what those tools find. The last part is where most programmes fail.
Preparation, identification, containment, eradication, recovery, lessons learned. Say what makes each real: preparation is playbooks and access you already have; containment is often isolating a host before you fully understand the malware; lessons learned is the step everyone skips and the one that actually reduces repeat incidents.
Preserve the original with headers, extract indicators (sender, URLs, attachment hashes), check whether anyone clicked or entered credentials by searching mail and proxy logs, block the sender and URLs, reset affected credentials and revoke sessions, then send an awareness note. Report scope before you report opinions.
It centralises logs from endpoints, network devices, cloud and applications, normalises them, and runs correlation rules to raise alerts. Its value is correlation across sources — a failed VPN login is nothing, a failed VPN login from a new country followed by a successful one and a mailbox rule creation is an incident.
Enrich before you judge: who is the user, is the asset expected to do this, what happened immediately before and after, does the destination have reputation history. Then compare against a known-good baseline. Document the reasoning either way so the rule can be tuned.
Proactively searching for adversary activity that existing detections missed, driven by a hypothesis — for example "if an attacker used this technique, I'd see this parent-child process pair". The output is either a finding or a new detection rule.
Indicators of compromise — hashes, IPs, domains, registry keys. You sweep your estate for them after intelligence lands, and you extract them from your own incidents to detect repeat activity. They're brittle on their own, which is why behaviour-based detection sits alongside them.
A knowledge base of adversary tactics and techniques. Teams use it to map detection coverage, describe incidents in a shared vocabulary, and prioritise what to build next. Even as a fresher, saying you mapped your home-lab detections to ATT&CK techniques lands well.
You'll answer these out loud, under time pressure, with an interviewer asking follow-ups. Do a free 5-question AI mock interview and get scored feedback in minutes — no card needed.
Start free mock interviewThe cloud provider secures the infrastructure; you secure your configuration, identity, data and code. The exact line moves with the service — with IaaS you patch the OS, with a managed database you don't. Most cloud breaches are on the customer side of the line: public buckets and over-permissive IAM.
Block public access at the account level, enforce encryption at rest, use bucket policies scoped to specific principals, enable versioning and access logging, and use pre-signed URLs instead of making objects public. Then monitor for policy changes.
No wildcard actions, no long-lived access keys where a role will do, permission boundaries on developer roles, and regular review of unused permissions using access analyzers. Attach policies to roles and groups, not individual users.
The attacker has valid credentials and spams push notifications until the user accepts one. Defend with number matching, push rate limiting, and phishing-resistant factors like FIDO2 security keys or passkeys.
One identity provider authenticates the user across many applications, which improves control and user experience. The risk is concentration — if the IdP account is compromised, everything downstream is. That's why IdP admin accounts need the strongest controls in the organisation.
This round decides as many outcomes as the technical one, and it's where most freshers lose the offer.
Give a specific origin, not a slogan. Something you actually did — a CTF you got stuck on for two days, a phishing mail you analysed for a family member, a lab you built — then connect it to the role. Avoid "because it's a growing field"; every candidate says it.
Use context, action, result. What was the goal, what did you personally build or find, what changed because of it. If it's a home lab, treat it as a real project: what you deployed, what attack you simulated, what detection caught it, what you'd do differently.
Name real sources you actually follow and one thing you learned recently that you can discuss for two minutes. A specific recent CVE or incident, with your take on why it mattered, beats a list of newsletter names.
Be concrete and role-adjacent: strong in detection engineering, or moving from SOC L1 to threat hunting, plus the certification or skill path that gets you there. Ambition that stays inside the function reassures the interviewer you won't leave in six months.
Bring evidence, not opinion. State what you observed, ask what they saw that you didn't, escalate through the documented process if it's high impact, and accept the decision once it's made. Interviewers are checking that you can push back without being difficult.
Always yes. Ask about the detection stack, how alerts get tuned, what the on-call rotation looks like, and how a new joiner is ramped in the first 90 days. These signal that you're thinking about doing the job, not just getting it.
A screening round is usually 8–12 questions in 30 minutes. Technical rounds go deeper on 4–6 areas with follow-ups, and the HR round adds another 5–8 behavioural questions.
Networking fundamentals, the CIA triad and OWASP Top 10, basic Linux and Windows logging, and one hands-on project you can talk about for five minutes. Depth in a small area beats shallow coverage of everything.
Yes — they're the patterns used in Indian service-company screening rounds, product-company technical rounds and managed SOC hiring, which is where most entry-level cyber security hiring in India happens.
You'll answer these out loud, under time pressure, with an interviewer asking follow-ups. Do a free 5-question AI mock interview and get scored feedback in minutes — no card needed.
Start free mock interview