How would you enforce that a container never downloads and executes a binary after it has started?
answer
- no API request, no admission decision
- the write is one instant, not a lifetime
- admission bounds the grant, not the behaviour
- preventive versus detective
- a sensor on the node sees execution
basics
~20 sNot at admission. Admission decides once, when the object is written, and a process fetching code an hour later produces no API request, so no rule runs. Admission can narrow what the workload is granted; only a runtime sensor can observe the act.
solid answer
~50 sThis is a behaviour, not a field, so the request that creates the Pod cannot express it. Admission runs once, synchronously, on a write; an hour later the container reaching out and executing something never touches the API server, so there is nothing to intercept. What admission can do is reduce the opportunity — it decides what the workload is granted at start, such as whether its filesystem is writable and which privileges it holds — but that is a structural constraint, not an observation, and it will never tell you the act happened. Observing it needs a sensor on the node watching process execution and outbound connections, correlated back to the workload. So the control splits: preventive narrowing at admission, detective observation at runtime, with a response path and an owner who actually reads the alerts. Pretending the first covers the second is the error interviewers are probing for.
go deeper
Remember that admission runs when an object is written and never again. Something a container does an hour later never reaches the API server, so no rule can fire on it.
Explain the split cleanly: admission constrains what the workload is granted at start, a runtime sensor observes what it actually does, and one is preventive while the other is detective.
Show you would refuse the admission framing, keep the structural narrowing anyway, and treat the runtime half as a commitment with a response path and a named owner.
Be ready to defend the cost of running node-level sensing across the estate, and to state plainly which part of this risk remains observable rather than preventable.
### Why the request cannot answer this Admission is a decision about a write. The API server receives a request to create or update an object, hands it to policy, and persists or rejects it. Everything the policy knows is in that request, and the request describes an *intended state*, not a history of what a process will do. A container that starts cleanly and then, an hour into its life, fetches a binary over the network and executes it does not generate an API request. Nothing is created, nothing is updated, so no admission decision is ever triggered. This is not a policy language limitation and it is not a matter of the rule being hard to write — there is simply no event to attach a rule to. ### What admission can legitimately contribute Admission decides the workload's starting conditions, and those conditions bound what is possible. A rule can refuse a workload that asks for a writable root filesystem, or one that requests privileges it should not hold, or one whose spec grants it more reach than its job needs. That genuinely raises the cost of the behaviour you are worried about. But be precise about what that is: it is a **preventive, structural** constraint on capability. It reduces the opportunity; it never observes the act, and it never confirms the act did not happen. A workload constrained at admission can still load code it never writes to disk, or execute from a writable volume it was legitimately given, or use network access it needs for its actual job. Admission granted the shape of the box; it cannot see inside it afterwards. ### What can answer it The fact you need — a process executed that was not part of the image, a connection opened to an address nothing should be talking to — is only visible to something watching the workload as it runs: a sensor on the node observing process execution and network activity, attributing events to the workload that produced them. That is a **detective** control. It reports after the act, which means its value depends entirely on what follows: an alert nobody reads is not a control. A serious answer names the response path — kill or quarantine the workload, page an owner, or feed the finding into an investigation — and names who owns the alerts. It also acknowledges the cost: a node-level sensor is infrastructure with its own footprint, its own failure modes and its own tuning burden, which is why the request 'can we just do it at admission' keeps coming back. ### Reading the split correctly The two halves are not substitutes and they do not overlap: | | Admission | Runtime sensor | |---|---|---| | When | once, at the write | continuously, while running | | Sees | the intended object | actual execution and network activity | | Nature | preventive | detective | | Failure | workload never starts | act happened, you find out after | A candidate who offers only the left column has answered a different question. A candidate who offers only the right column has skipped the cheap structural work that shrinks what the sensor has to catch. ### The judgment an interviewer is looking for First, say out loud that the requirement is not admission-shaped and why: there is no API request at the moment the behaviour occurs. Second, split it honestly — narrow the grant at admission, observe at runtime, and be explicit that the first is not coverage of the second. Third, treat the detective half as a real commitment with an owner and a response, not a checkbox. Fourth, be honest about what remains uncovered even then, so nobody reads the pair of controls as a guarantee. ### The trap answer The trap is to accept the framing and produce an admission rule that *looks* like it addresses the behaviour — blocking a particular command in the container's arguments, say, or requiring an annotation that the team promises means 'this workload does not download code'. Both decide something the requester will hear as the behaviour being prevented, and neither can be true: the arguments are only the entry point, and the annotation is a self-assertion by the person deploying. Producing that rule buys peace in the meeting and leaves the estate believing in a control that does not exist.
- Isn't a read-only root filesystem enough to close this?It raises the cost and it is worth doing, but it does not close it. Code can be executed from a writable volume the workload legitimately mounts, or loaded without ever being written to the root filesystem, and the constraint says nothing about what the process does with network access it already needs. It narrows the opportunity; it does not observe the act.
- How do you make the runtime half a real control rather than an alert stream?Give it a response and an owner. Decide in advance what happens when it fires — kill, quarantine, or page — name the team that receives it, and tune it against real workload behaviour until the signal is credible. An unread alert queue is worse than no control, because it is reported as coverage.
- The requester says a detective control is unacceptable because it is after the fact. What do you say?That preventing this class outright at deploy time is not available, so the choice is between a real detective control and an imaginary preventive one. You can shrink the window — reduce the grant at admission, tighten egress — but the honest position is that the behaviour is observable, not preventable, at the point they are asking for it.
Vetting someone at the door decides what keys they are handed. It does not tell you which rooms they walked into at three in the morning.
saying these in an interview costs you the question
- Proposes an admission rule to stop runtime behaviour
- Assumes a running container re-enters admission somehow
- Calls a runtime sensor preventive when it reports after the act
- Requires an annotation asserting the workload behaves
- Treats a one-time write check as continuous enforcement