A DevOps team is deploying an agent that manages Kubernetes cluster resources. The team is determining the appropriate autonomy level for the agent. The agent can: scale deployments up or down based on metrics, evict pods when nodes are under memory pressure, update ConfigMaps with new application settings, drain nodes before maintenance, and delete PersistentVolumeClaims (PVCs). The team has four autonomy levels available: (1) Suggest-only, (2) Suggest-and-execute with human confirmation, (3) Execute-and-notify, and (4) Fully autonomous. Which autonomy level assignment across these actions BEST reflects appropriate risk-proportionate governance?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Not all Kubernetes actions are equal — scaling a deployment is an operational reflex; deleting a PVC might permanently destroy customer data. Autonomy levels should track the risk profile of each action. Fast-reversible ops get full autonomy, slow-reversible ops get notify-after, and data-destructive ops get explicit confirmation. One size doesn't fit all.
Full explanation below image
Full Explanation
Risk-proportionate autonomy assignment requires evaluating each action independently:
Scale deployments (Level 4 — Fully Autonomous): Scaling is a core HPA-equivalent function. It is fast, reversible (scale back), and time-sensitive — automated scaling decisions that wait for human approval defeat the purpose of autoscaling. Operational efficiency justifies full autonomy.
Evict pods (Level 4 — Fully Autonomous): Pod eviction under memory pressure is a standard Kubernetes node pressure response. Evicted pods reschedule automatically. Delay could cause node OOM conditions. Fully autonomous is appropriate.
Update ConfigMaps (Level 4 — Fully Autonomous): ConfigMap updates apply new application settings without redeployment. Changes are trackable via Kubernetes audit logs and reversible. Standard operational update.
Drain nodes (Level 3 — Execute-and-notify): Node draining evicts all running pods from a node, causing temporary disruption to workloads. This is a planned maintenance operation with broader impact than individual pod eviction. The SRE team should be notified but does not need to pre-approve — the action is time-bounded and necessary for maintenance.
Delete PVCs (Level 2 — Suggest-and-execute with confirmation): PVC deletion can result in permanent data loss if the underlying PersistentVolume's reclaim policy is 'Delete.' Even with a 'Retain' policy, the agent cannot always know the downstream implications of orphaned storage. This is the one action class in Kubernetes that can be irreversible, warranting explicit human confirmation before execution.
Option A (all fully autonomous) treats PVC deletion as a routine operation — it is not, due to potential data loss. Option C (all suggest-only) eliminates all operational automation benefits. Option D (all level 2) is the safest but introduces unnecessary human confirmation overhead for routine operations like pod eviction and scaling, reducing the agent's operational value.