A courts-clerk team needs its coding-agent-built document-review workflow to run inside a tightly controlled sandbox with custom networking rules that a fully managed runtime doesn't expose configuration for. What consideration should drive their deployment runtime choice here?
Select an answer to reveal the explanation.
Short Explanation
When the plumbing itself — custom networking, a locked-down sandbox — needs to be controlled directly, the platform has to let you touch the plumbing. A fully managed runtime hides that layer on purpose, trading control for convenience. GKE keeps that control exposed, which is exactly the tradeoff this courts-clerk team needs.
Full Explanation
Choosing between a managed runtime and GKE is fundamentally a tradeoff between operational simplicity and infrastructure control; GKE exposes cluster-level configuration including custom networking policies and sandbox isolation that a fully managed runtime abstracts away in exchange for less operational burden, so when a workload's requirements — like custom networking rules for a document-review sandbox — exceed what the managed option configures, GKE becomes the fitting choice. Prioritizing simplest autoscaling sidesteps the actual blocking requirement, since the managed option can't expose the needed networking configuration regardless of how good its autoscaling is. Prioritizing lowest per-request cost ignores that the requirement here is a capability gap, not a pricing comparison. Minimizing ongoing operational maintenance is the general argument for staying managed, but it doesn't address a hard requirement the managed option simply cannot satisfy. Scope caveat: choosing GKE for infrastructure control means also taking on the operational responsibility of managing that cluster, a real ongoing cost to weigh against the control gained. Operational check: confirm which specific networking or sandbox configuration the managed runtime cannot expose before committing to the added operational overhead of GKE.