17 cyber security interview questions for freshers

Give a short connection between your current background, your genuine learning activities and the role you want. Explain what you understand or have practised, distinguishing completed work from plans. If you have not built a lab, say so and discuss a concept you can explain accurately instead. This structure helps the interviewer identify relevant follow-up areas without requiring an invented achievement. The trade-off is breadth versus depth: covering every course leaves little room to demonstrate understanding. Select one relevant topic, explain your interest in the role, and invite a question about evidence you can actually discuss.

Worked example: A truthful structure is: current education or work, one topic genuinely studied, one limitation still being addressed, and the role sought. Replace each part with your own facts rather than borrowing a fictional lab story.

Common mistake: Reciting a fictional project or an entire educational history makes follow-up questions harder and obscures the experience you genuinely have.

Follow-up: Which statement in your introduction could you support with an actual explanation, note or artefact today?

Explain what genuinely interests you about protecting systems, investigating evidence or managing risk, without treating development as an inferior career. Security and development overlap: understanding software behaviour helps identify defects and build safer applications. You do not need a dramatic origin story; a real learning experience or a thoughtfully explained interest is sufficient. Connect that interest to the work of the role rather than to excitement about hacking. The trade-off is specialisation versus breadth: you may prefer investigation while still needing programming fundamentals. Describe what you want to learn next without presenting that future learning as completed experience.

Worked example: If your interest is investigation, explain why comparing evidence and testing alternative explanations appeals to you. Acknowledge that reading code remains useful, even when your preferred role is not primarily software development.

Common mistake: Claiming unauthorised testing of a college portal as initiative confuses curiosity with permission and may expose poor professional judgement.

Follow-up: Which everyday security task interests you, and which less exciting responsibility would you still need to learn?

Acknowledge your experience level directly and describe the contribution you can support with evidence. This could be clear technical reasoning, careful documentation or relevant coursework; it need not be a sophisticated project. Explain how you would work safely under supervision, ask focused questions and escalate decisions beyond your authority. Employers must balance a beginner's potential against onboarding effort, so avoid promising immediate independence. Instead, identify a realistic early responsibility and the guidance it would require. If you have practice artefacts, discuss their limitations as well as their results. Never imply that laboratory practice equals operating a production environment.

Worked example: An applicant without a lab can offer to explain authentication fundamentals and show genuine study notes. They can also acknowledge needing supervision before interpreting production alerts or making changes to customer systems.

Common mistake: Promising to secure production systems immediately substitutes confidence for evidence and ignores the supervision and access boundaries beginners need.

Follow-up: What useful first-month task could you perform with supervision, and what decisions would you escalate?

Choose a strength that affects how you work and support it with a genuine example from study, employment or another relevant setting. Then identify a real development area, the action you are taking and how you check improvement. You do not need to disclose private personal information or invent a security incident. Explain the trade-off behind the behaviour: detailed checking can improve accuracy but delay completion if it lacks a stopping rule. Improvement should be observable, such as clearer notes or better prioritisation, rather than an unsupported claim that the weakness has disappeared. Keep both parts relevant to the role.

Worked example: If your genuine weakness is lengthy explanations, describe practising a definition followed by one example and one limitation. Compare recordings for clarity rather than claiming that an invented manager praised your progress.

Common mistake: Calling perfectionism your only weakness without a real consequence or improvement method gives the interviewer little meaningful evidence to assess.

Follow-up: What observable change would show that your improvement method is working?

The CIA triad describes confidentiality, integrity and availability. Confidentiality limits information disclosure to authorised parties; integrity protects against improper changes; availability keeps information and services accessible when needed. Encryption can support confidentiality, but key exposure defeats that protection. A hash helps detect changes only when compared with a trusted reference; an attacker who replaces both data and its reference can conceal tampering. Redundancy supports availability but can replicate corruption. Priorities depend on the specific service and its risks, not simply its industry. Strong controls can also introduce friction, so access restrictions, recovery needs and operational usability must be balanced.

Worked example: For a synthetic student-results service, restricted access protects confidentiality, approved change records support integrity, and tested recovery supports availability. A read-only backup is useful only if restoration and access controls actually work.

Common mistake: Assigning one permanent CIA priority to every bank or retailer ignores the different risks of individual services and workflows.

Follow-up: Why is a file hash insufficient to prove integrity when its reference value is stored beside the file?

• NIST Cybersecurity Framework 2.0Final · February 2024

An intrusion detection system identifies suspicious activity and produces alerts; a network IDS commonly observes copied traffic rather than controlling its delivery. An intrusion prevention system can enforce decisions, commonly by inspecting traffic inline and dropping matching packets or connections. Both may use signatures, protocol checks or behavioural analysis. Detection quality depends on visibility, rule quality and context; encrypted payloads may be unavailable without an approved inspection design. The main trade-off is prevention versus disruption: a false positive can interrupt legitimate service. Test proposed rules against representative traffic and document exceptions before enabling blocking within authorised change procedures.

Worked example: In an isolated, owned network, replay a benign training capture against a detection rule first. Expect an alert without disrupted traffic; only a separately configured inline prevention test should demonstrate a blocked connection.

Common mistake: Assuming every alert should trigger automatic blocking overlooks false positives, shared infrastructure and the consequences of interrupting legitimate traffic.

Follow-up: What evidence would you require before changing a new rule from alert-only to blocking?

• NIST Cybersecurity Framework 2.0Final · February 2024
• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

A firewall enforces traffic policy between hosts, networks or security zones. Basic rules match properties such as addresses, ports and protocols; stateful inspection also tracks connection state to evaluate related traffic. Some firewalls inspect application behaviour or use identity context, but those capabilities depend on configuration and visibility. Allowing HTTPS does not mean the application or its content is safe. The trade-off is connectivity versus exposure: broad permissions simplify access but increase reachable attack surface, while restrictive rules require careful dependency mapping. Validate rules using allowed and denied cases, and review logs without assuming missing records prove no traffic occurred.

Worked example: In an owned two-VM lab, permit a test web service on port 443 and deny an unused port. Expect only the configured service connection to succeed, subject to routing and host-firewall settings.

Common mistake: Treating a permitted connection as trustworthy confuses network reachability with application security, user authorisation and the safety of transferred content.

Follow-up: How would you distinguish a firewall denial from a service that is not listening?

• NIST Cybersecurity Framework 2.0Final · February 2024

SQL injection happens when an application builds a database instruction by mixing untrusted input into executable query text. The database may interpret part of that input as an instruction rather than as a value. Depending on permissions and query structure, this can expose or alter data; it does not automatically reveal every table. Parameterised queries separate query structure from supplied values. Dynamic identifiers, such as selectable column names, require safe design and allowlists rather than ordinary value parameters. The trade-off is initial refactoring effort versus dependable prevention. Least-privilege database accounts reduce consequences but do not repair the vulnerable query.

Worked example: In an intentionally vulnerable, isolated application you own, compare unsafe string concatenation with a parameterised lookup using synthetic records. Expect unusual input to remain a literal value after correction rather than changing query structure.

Common mistake: Relying only on input filtering or a web application firewall leaves unsafe query construction in place and can miss alternative inputs.

Follow-up: Why do parameterised values not automatically make a user-selected table name safe?

• OWASP Top 10:2025Released 2025 edition
• OWASP Web Security Testing GuideVersioned testing guidance; authorised scope only

Phishing uses deceptive communication to persuade someone to disclose information, approve an action or interact with malicious content. Urgency, unusual payment instructions and misleading links are clues, not proof. Preserve the original email as an .eml file and examine Received headers from your organisation's trusted mail boundary; attackers can forge earlier entries. Check SPF, DKIM and DMARC results and alignment, but passing authentication does not prove benign intent because attackers can use their own domains or compromised accounts. Balance rapid escalation with evidence quality. Verify requests through a known independent channel and avoid opening attachments or uploading confidential messages to public tools.

Worked example: A synthetic message from billing@example.com passes DMARC but asks for an unexpected bank-detail change. Preserve it and verify through an established contact method; authentication supports domain alignment, not the legitimacy of that request.

1. Preserve the original .eml and record receipt time and reporting context using approved evidence storage.
2. Trace Received entries from the trusted receiving boundary and inspect authentication results and alignment.
3. Compare sender identity, requested action and destination domains without visiting suspicious links.
4. Verify the request through a known channel and escalate findings; quarantine or block only within documented authority.

Common mistake: Declaring a message safe because SPF, DKIM or DMARC passed ignores malicious sender domains, account compromise and fraudulent business requests.

Follow-up: Which Received header would you trust first, and what would a DMARC pass actually establish?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

Malware is software or code intended to perform harmful or unauthorised actions. Categories describe overlapping behaviours: worms self-propagate, viruses attach to hosts, ransomware can encrypt data, spyware collects information, and loaders introduce other payloads. A trojan presents itself as legitimate, but delivery and execution need not involve a user manually opening it. Classification helps explain behaviour, yet a label alone does not establish capabilities or attribution. Compare process activity, persistence and network evidence before drawing conclusions. The trade-off is speed versus certainty: suspected malware may require urgent escalation, but containment must remain within authority. Never execute unknown files on a workstation.

Worked example: Use a benign training simulator in an isolated, owned VM to create a harmless marker file. Expect the configured telemetry to show that action; it demonstrates logging, not the behaviour of real ransomware.

Common mistake: Running a suspicious attachment to see what happens can compromise the workstation and destroy the evidence needed for reliable investigation.

Follow-up: What evidence would distinguish a suspected loader from a file that merely has an alarming filename?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base

A distributed denial-of-service attack uses multiple sources to exhaust resources needed by legitimate users. Volumetric attacks consume network capacity, protocol attacks exhaust infrastructure resources, and application attacks target expensive operations. A traffic spike alone does not prove an attack; compare request patterns, service errors and normal demand. Upstream filtering can help before a link saturates, while caching and rate controls may reduce application load. The trade-off is availability versus exclusion: aggressive limits can block legitimate users behind shared addresses. Provider coordination and an approved response plan matter because local controls cannot recover bandwidth already exhausted upstream.

Worked example: On an owned local test service, generate a small, bounded request workload below agreed limits. Expect a configured rate limit to return controlled rejection responses; this tests a control, not resistance to internet-scale DDoS.

Common mistake: Blocking every busy source address can exclude legitimate users sharing a gateway while failing to address upstream bandwidth exhaustion.

Follow-up: Why might a healthy application server still be unreachable during a volumetric attack?

• NIST Cybersecurity Framework 2.0Final · February 2024
• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

Patch management identifies assets, evaluates updates, tests compatibility, deploys changes and verifies the resulting state. Delays can arise from ownership gaps, unsupported software, dependency concerns or limited maintenance windows, not simply carelessness. Prioritise using exploitation evidence, exposure, business importance and available mitigations; CVSS describes technical severity rather than the complete organisational risk. Testing reduces disruption but postponing an urgent fix also carries risk. Restate each finding, verify it, assess context, choose fix, defer, accept or false-positive disposition, and document evidence. Deferral or acceptance requires an accountable risk owner, treatment rationale and residual-risk review, not an analyst's informal decision.

Worked example: A synthetic inventory shows an exposed service with a relevant exploited vulnerability and an internal test server with a higher CVSS score. Verify applicability and context before prioritising, rather than sorting solely by score.

Common mistake: Closing a finding because deployment reported success skips verification that the vulnerable component changed and the service still functions correctly.

Follow-up: What evidence and approval would you record when an urgent patch must be deferred?

• NIST Cybersecurity Framework 2.0Final · February 2024
• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

Start with an investigative question, not a command list. For suspected SSH access, compare authentication records, login sessions, running processes and current connections around a defined time window. journalctl may expose service logs, while last, ps and ss provide different views of sessions, processes and sockets. Availability varies by distribution, retention, privileges and logging configuration; auth.log is not universal. Live collection changes some system state, so document commands and preserve relevant records using approved procedures. The trade-off is quick visibility versus completeness: a current socket snapshot cannot reconstruct yesterday's connection. Correlate timestamps and packet observations with endpoint evidence before attributing activity.

Worked example: In an owned Linux VM, make one successful and one failed SSH login from a lab client. Expect configured authentication logs to distinguish outcomes; correlate timestamps with a capture rather than assuming packets identify users.

1. Record the authorised scope, host time zone, suspected time window and available log retention.
2. Preserve relevant authentication records before filtering them, following the approved collection procedure.
3. Compare success and failure records with session history, process details and socket snapshots.
4. Correlate available packet timing and endpoint records; document gaps and avoid unsupported attribution.

# Illustrative read-only commands; adapt service names, privileges and time window.
journalctl -u sshd -u ssh --since '2026-10-12 09:00:00' --until '2026-10-12 09:15:00' --no-pager
last -F
ps -eo pid,ppid,user,lstart,args
ss -tunap

Common mistake: Treating empty command output as proof of no compromise ignores retention gaps, missing permissions, service-name differences and disabled logging.

Follow-up: How would you investigate an SSH login if the journal lacks records for the relevant period?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

Describe only work you actually completed: its objective, authorised scope, configuration, evidence and limitations. If you have no project, explain that honestly and outline a proposed exercise rather than speaking in the past tense. A useful beginner exercise checks whether a harmless action produces expected telemetry. For example, Windows Event 4688 depends on process-creation auditing; command-line details require additional configuration. Event 7045 concerns service installation in the System log, not Security. More telemetry improves visibility but increases storage and privacy considerations. Explain what your evidence supports, what remains unknown and how you would reproduce the observation safely.

Worked example: A proposed owned Windows VM lab enables process-creation auditing and launches Notepad. The expected observation is Event 4688 with matching process details. Describe this as a plan unless you have actually configured and checked it.

Common mistake: Claiming a SIEM project without explaining its data source and audit prerequisites turns a tool name into unsupported evidence of experience.

Follow-up: What configuration must exist before your proposed Windows process event can appear?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• Microsoft Windows: event 4688Audit policy and field availability matter

No certification is universally required for an entry-level security role. Start with the responsibilities in relevant vacancies, then compare official objectives, eligibility and current costs with your knowledge gaps and budget. CompTIA Security+ is one possible fundamentals option, while specialised cloud credentials may be more useful after relevant practice; this is not a ranking or hiring guarantee. Certifications structure study but cannot replace evidence of reasoning and safe work. Microsoft AZ-500 retired on 31 August 2026, so do not plan to sit that exam or assume an unverified replacement. Recheck official information before payment because programmes and requirements change.

Worked example: A beginner targeting monitoring roles compares current vacancies with official exam objectives, then budgets for study and practice. If fees are unaffordable, they can continue learning and produce honest notes without claiming certification.

Common mistake: Buying a credential because someone promises screening success ignores role fit, changing exam status and the limits of certification evidence.

Follow-up: Which specific knowledge gap would your chosen certification address, and how would you practise applying it?

• CompTIA Security+ certificationConfirm current objectives, eligibility and exam dates
• AWS Certified Security – SpecialtyConfirm current exam guide and eligibility
• Microsoft retired certification examsAZ-500 retired 31 August 2026; check active paths

Answer yes or no truthfully. If you have participated in a capture-the-flag exercise, describe one authorised challenge, your reasoning, failed approaches and the evidence behind the solution. Explain whether hints or a walkthrough helped, because assisted learning is different from independent discovery. If you have not participated, discuss genuine study or a clearly labelled future plan instead. CTFs can build problem-solving skills, but their deliberate clues and simplified environments differ from production systems. The trade-off is puzzle depth versus operational realism: finding a flag does not demonstrate incident handling, safe change management or business-risk judgement on its own.

Worked example: For a challenge you genuinely completed, explain the clue, your hypothesis and what confirmed it. If you used a walkthrough, identify the concept learned and whether you later reproduced it without assistance.

Common mistake: Presenting a copied walkthrough as independent discovery misrepresents your reasoning and makes it difficult to explain failed approaches or alternative hypotheses.

Follow-up: Which part did you solve independently, and which assumption would not transfer safely to a production system?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• OWASP Web Security Testing GuideVersioned testing guidance; authorised scope only

Define one realistic task and learn the tool's data model, permissions and limitations from official documentation. Use an isolated, owned or explicitly authorised lab with synthetic data, then compare expected events with actual records. Keep configuration notes and distinguish tool behaviour from missing telemetry. For example, CloudTrail S3 GetObject visibility requires appropriate data-event configuration; standard Event history is not enough. AzureActivity covers subscription activity, not Entra directory-role AuditLogs or SigninLogs. The trade-off is depth versus coverage: one week can support a bounded task, not mastery. Finish with a reproducible explanation, known gaps and questions requiring supervision.

Worked example: A proposed S3 learning task reads one synthetic object in an owned test bucket after enabling relevant data events. Expect a GetObject record to support comparison of caller, source IP and object activity.

Common mistake: Blaming the tool for missing records before checking collection settings, permissions, delivery delay and schema can lead to false conclusions.

Follow-up: How would you distinguish a collection gap from an event that genuinely did not occur?

• Amazon S3 security best practicesLiving vendor documentation
• AWS CloudTrail: management and data eventsLiving vendor documentation
• Microsoft Entra sign-in logsLiving vendor documentation