Cloud, Container & AI Infrastructure Security
38 questionsDONEUNLOCKEDLOCKED
Cloud & AI Infrastructure Security Interview Questions
Cloud posture (CSPM/CNAPP), sensitive-data discovery (DSPM), infrastructure as code, container and Kubernetes controls, workload protection (CWPP) and runtime sensors. Follow identities, data and exposure through the AI infrastructure stack.
Worked answers that start from a threat model, explain each control by mechanism, and include the follow-ups and scoring an interviewer uses.
You have 5 free answers unlocked here.Sign in free for 5 more · 28 are premium.
01–16Foundationsthe mechanisms and vocabulary an interviewer expects you to have0/16 done
17–30Core questionsthe questions this round asks most, answered in full0/14 done
31–38Field scenariosdesign rounds, incidents and judgment calls with the inputs left incomplete0/8 done
The concepts behind Cloud, Container & AI Infrastructure Security
The lessons these answers build on. Introductory ones are free; advanced ones need Premium.
Foundational
What Containers Isolate, and What They Do NotContainers isolate processes using Linux namespaces, cgroups, capabilities, seccomp and security modules, but every container on a host shares one kernel. A kernel bug or a misconfiguration such as a privileged container, a mounted container runtime socket or a broad host mount lets code escape to the host. For untrusted code, including code written or run by AI agents, stronger boundaries such as gVisor's user-space kernel or Firecracker and Kata microVMs put a much smaller or separate kernel between the workload and the host.Foundational
Sandboxing Untrusted CodeAgents that write and run code, notebooks that execute model output, and platforms that run customer code all execute code nobody reviewed. A sandbox makes that safe by combining a strong isolation boundary with an environment that has nothing valuable in it: no credentials, minimal files, no network or tightly allowlisted egress, resource and time limits, and disposal after use. Isolation answers whether code can escape; the environment answers what it can do without escaping.Core
Cloud IAM and Privilege Escalation PathsCloud identity and access management decides what every user, service and workload can do, so it is the real perimeter of a cloud environment. Privilege escalation happens when a principal can use its permissions to gain more: attaching policies to itself, passing a powerful role to a resource it creates, changing code that runs under another role, or minting credentials. ML platforms are full of such paths because training and notebook roles are often broad. Least privilege, permission boundaries, organisation-level guardrails and path analysis keep them closed.Sign in
Foundational
Protecting Model WeightsTrained model weights can represent enormous investment and, for the most capable models, real misuse risk if stolen. Theft needs only one successful copy, through compromised credentials, insiders, supply chain attacks, exposed storage or the serving infrastructure itself. Protection combines limiting where weights exist and who can access them, strong identity and encryption with tightly controlled keys, monitored and restricted egress, hardened serving, and insider-risk controls. RAND's 2024 study frames the problem as security levels matched to increasingly capable attackers.Advanced
The Inference Stack as Attack SurfaceAn LLM inference service is a stack of components that all handle untrusted input: an API gateway, authentication and quotas, request and prompt processing, tokenizers, the model server, GPU drivers, caches, logging, and the management plane. Each layer has classic risks such as parsing bugs, exposed dashboards and broken tenancy, plus AI-specific ones: cost exhaustion, model extraction through the API, prompt leakage through shared caches, and data retained in logs. Threat-modeling the stack layer by layer turns 'secure the model' into concrete controls.🔒 Premium
Core
Self-Hosted Inference Servers: A Secure Reference DeploymentTeams increasingly run their own model servers, such as Ollama, vLLM, Triton, Ray Serve and llama.cpp. Most were designed for trusted networks: some have no authentication by default, expose model management next to inference, and rely on internal channels that deserialise data. Vulnerabilities and exposed servers followed. A secure deployment binds servers to loopback or a private segment behind an authenticating proxy, separates admin endpoints from inference, loads models only from an internal registry by digest, gives nodes no unnecessary cloud identity or egress and patches on a schedule.Sign in
Advanced
Multi-Tenant Inference Isolation: Caches, Batches, GPUs and Side ChannelsServing models cheaply means sharing: prompt caches, response caches, batches, adapters, GPUs and network paths. Each shared resource leaks wherever it is keyed by something coarser than the trust boundary. Researchers found providers sharing prompt caches across customers, recovered prompts from scheduling order, read GPU memory left by other processes, and inferred chat topics from encrypted packet sizes. Scope every cache by a server-derived tenant key, pick GPU sharing modes by isolation guarantee, pad streams, and remember confidential computing removes the operator, not co-tenants.🔒 Premium
Foundational
Infrastructure as Code Scanning and Runtime DriftIaC scanning checks intended infrastructure before deployment. Connect source templates, resolved plans and cloud observations so policy checks catch unknown values, exceptions and changes made outside the pipeline.Unlock all 38 answers · $25
Every worked answer in all 17 topics, every lesson in every course, the full concept curriculum, the complete practice-test bank, and the downloadable security field guides.
6 months · One payment · No auto-renewal