Easy AI security interview questions

The first ten minutes of any design review decide its quality. This answer shows the sketch, the one question that finds most bugs, and why controls come last.

Reciting the six letters earns little. What scores is a diagram drawn aloud, one boundary walked in depth, and a list of threats with owners.

Definitions take ten seconds. The interviewer wants a worked failure: which layer broke, which one held, and why they did not break together.

Three words people use interchangeably, and a prioritisation question that exposes whether you have ever had a backlog of thirty findings.

Most candidates start by deleting the commit. The key was copied the minute it went public; the clock starts with revocation.

A penetration test is a controlled, authorised simulation of an attacker with a scope, rules and a report. The legal and planning parts are what separate it from an attack.

Most candidates say 'rings' and stop. The interviewer is listening for who enforces the boundary, where the kernel must distrust its caller, and why one kernel bug undoes every process boundary at once.

Isolation is enforced by page tables and credentials, then deliberately punched through by debuggers, shared memory and IPC. A strong answer names both the wall and the doors.

Reading rwx bits is the easy half. Interviewers check whether you know what execute means on a directory, why setuid binaries are an attack surface, and what the sticky bit does and does not protect.

The definition takes one sentence. The interview is about the four ways privilege actually moves, and why most escalations are misconfigurations rather than exploits.

Interviewers listen for precision: an overflow is an out-of-bounds write, an over-read is a different bug, and a use-after-free is about lifetime, not bounds. Getting the taxonomy right is most of the easy question.

Tool names are not the answer. Interviewers want to know what each view can and cannot tell you, and why a decompiler's output is a hypothesis to be checked at runtime.

A vulnerability is a gap between what the code assumes and what an attacker can make true. Nearly every one falls into a handful of root causes, and each has a matching way to find and prevent it.

Encryption alone does not stop a man in the middle: you could be encrypting to the attacker. The property that matters is authentication, and every successful MITM is a story about how it was skipped.

A classic warm-up that rewards precision: what state the server keeps, why spoofed SYNs cost the attacker nothing, and how SYN cookies move that state into the sequence number.

NAT is not a firewall, and inbound rules are only half a policy. Interviewers check whether you know what each device decides, and why the outbound direction is where breaches are contained.

Attackers scan the whole internet continuously and know your forgotten test server before you do. The answer is an inventory built from several sources, compared with what is actually listening.

Interviewers do not want the seven OSI names recited. They want you to say which layer an attack lives at, because that decides which control can see it.

The whole IPv4 internet is scanned many times a day. If a service answers, assume someone has already catalogued it.

A MAC address is a label the device chooses and announces in clear text on every frame. The answer turns on that one fact, and on what a network should check instead.

The most common screen question in security. The answer that scores sorts all four by one property: whether there is a key, and who holds it.

The trap is answering 'which is better'. Every protocol you use daily runs both, each doing the job the other cannot.

SHA-256 with a salt sounds right and fails. The answer that scores explains the attacker's economics and names the parameters.

'Yes, always' is the right default and the wrong answer. The interviewer wants the list of attackers it does nothing against.

Preimage, second preimage and collision resistance sound alike and protect different things. The birthday bound explains why the last one costs half the bits.

Ten seconds of definition, then the part that scores: why most access bugs happen to users who logged in perfectly.

Both are 'something you have'. One can be typed into a fake page in real time; the other checks which page is asking.

API keys identify a caller; OAuth delegates a user's authority. The scored answer picks by who is acting and on whose behalf, and makes API keys as safe as they can be when used.

Three bugs, one cause. The answer that scores names the cause, explains why parameters are structural, and lands on why prompts have no parameters.

'Sanitise input' is the answer that fails. The interviewer wants encoding at the point of output, for the specific context, with CSP behind it.

An easy coding warm-up with traps a security engineer should spot: symlinks, huge files, unreadable files and paths outside the tree. The scored answer handles each and tests it.

Every attribute answers one question: over which connections, to which scripts, from which sites and to which hosts does this cookie travel? Get those four right and most session theft paths close.

The user clicks a button on your page while believing they are on someone else's. The fix is a response header that tells the browser who may frame you, not script that tries to escape the frame.

Interviewers ask for the list to see whether you are current. They ask how you would use it to see whether you understand it is an awareness document, not a standard.

Most database breaches are not clever. They are a reachable database, an over-privileged account, a leaked credential or an exposed backup.

These breaches rarely involved exploits. Databases built for trusted networks were put on the internet with no password, and automated scripts found them within hours.

Both platforms sandbox apps and require signing; they differ in who decides what runs and how fast fixes arrive. Interviewers want the shared model first, then the differences that change a threat model.

The sandbox is a Linux user ID, SELinux and a signature that decides who you are. Get those three right and most Android security questions become reasoning rather than recall.

A standard is a checklist only if you use it badly. The answer interviewers want maps the app's data and threats onto MASVS areas, then picks which MASTG tests are worth the time.

The provider secures the model service. Everything you put into it, connect to it and build on top of it is still yours.

Three words every SOC uses and many candidates blur. The answer that scores defines each by what it obliges you to do, and names the decision that turns an alert into an incident.

The process tree tells most of the story in five minutes. Interviewers want an order of questions, the evidence for each, and a clear point at which you contain rather than keep looking.

Malware is just software that does what its operator wants on your machine. Every stage leaves evidence, and every stage has a control that can stop it.

Three parts, each short. The answer that scores ends with a design rule about what may and may not live in a prompt.

A knowledge check with two traps: two editions are in circulation with different numbers, and reciting names earns little. Grouping the ten into entries and impacts, and applying them to a system, earns the rest.

Three definitions and one practical consequence. The consequence is the point: security tests split into deterministic checks and measured rates.

An easy question with a lot of surface area. The scored answer walks the pipeline left to right, names the attacker's lever at each stage, and ties each to one control.

Trace the proposal to its executor, resource policy and task scope. A valid credential or tool schema does not by itself authorize this particular action.

A motivation question that is really a skills question. The scored answer gives a specific reason, maps existing skills to AI security work honestly, and shows what you have already done to close the gaps.

Compare the control each interpreter enforces. Then review a fictional document-ranking feature without mistaking valid syntax, visible text or human review for permission.

Map the author, entry route and executing identity. Compare two fictional systems using reachable consequences, then explain what evidence could reverse your judgment.

Classify overlapping policy failures without assigning severity by label. Review a prohibited draft, a denied publication and an uncertain audience, then allocate the repairs.

Verify exact text, confidential facts and invented reconstruction against the right source. Then scope the audience, impact and failed delivery path.

Reason from learned behavior without inventing a hidden persona. Apply an explicit content policy, preserve legitimate fiction and test both missed violations and unnecessary refusals.

An easy question with a revealing follow-up. The answer that scores limits cost at every layer, including the agent loop, not just requests per minute.

When people act on wrong output, the harm is real even though nothing was hacked. The scored answer names the concrete failures and designs the product so verification is easy and required where it matters.

Banning tools people find useful mostly moves the leak somewhere you cannot see. The scored answer offers an approved route, then adds policy, technical controls and visibility around it.

One attacks the model's inputs, the other its upbringing. The phase decides the defence, and interviewers want you to say so.

Every model makes mistakes. An adversarial example is a mistake someone chose for it, and that changes how you measure and defend.

Compare actual scope and evidence across AI red teaming, penetration testing and benchmarks. The labels alone do not tell you which boundaries were assessed.

Naming Govern, Map, Measure and Manage takes five seconds. Saying what each one produces in your organisation is the answer.

Banning AI tools moves usage to personal accounts. The answer that works gives people a sanctioned path that is easier than the shadow one.

Most model cards describe the model's best day. The scored answer adds what a reviewer needs: intended use, limits, evaluations with conditions, data provenance and security-relevant behaviour.

The obligations most consumer AI products meet first. The scored answer separates provider and deployer duties, gives the dates, and turns each into a product requirement.

Seven characteristics that frame most AI governance conversations. The scored answer names them precisely and shows how security supports, and trades off against, the others.

Slides on prompt injection change little. The scored answer teaches through the developers' own code, gives them paved roads, and measures behaviour change.

The one governance answer that goes stale. The scored answer gives the timeline as amended in 2026, the fine tiers, and a process for tracking changes rather than memorised certainty.