Select Two (Multi-Select) Questions

Granting cluster-admin permissions to all application service accounts

Why it fails: Zero trust applies least privilege, so service accounts receive only the permissions their workload needs; cluster-admin grants unrestricted control and violates that principle. It is tempting because broad permissions avoid access-denied troubleshooting, which was the correct choice in trusted legacy environments. Here, least-privilege role bindings and scoped RBAC are required instead.

Assuming internal cluster networks are fully secure and trusting all pods by default

Why it fails: Zero trust explicitly rejects implicit trust in the internal cluster network, requiring mutual authentication and authorisation for every pod-to-pod request. It is tempting because perimeter-only models historically assumed a trusted internal network, which was the correct choice before zero trust. Here, default pod trust directly contradicts the model's verify-every-request principle.

Hardcoding administrative credentials directly into source code for operational simplicity.

Why it fails: Hardcoded administrative credentials in source code violate the least-privilege and secrets-management tenets central to cloud native security, exposing credentials through repositories and build pipelines. It is tempting because embedding credentials removes runtime authentication steps, but the correct approach uses short-lived tokens from a secrets store or workload identity.

Implicit trust of internal microservices communicating within the same cluster network.

Why it fails: Cloud native security mandates zero trust: every service-to-service request must be authenticated and authorised regardless of network location. Implicit trust within a cluster network assumes the perimeter is safe, so a single compromised pod can reach every peer. It is tempting because it removes per-request authentication overhead, but mTLS and service mesh policies are the correct control.

Perimeter-only defense, relying exclusively on an external corporate firewall.

Why it fails: Perimeter-only defence fails because cloud native workloads are distributed across clusters, serverless functions and third-party APIs, so an external firewall cannot inspect east-west traffic or compromised identities inside the boundary. It is tempting because firewalls are familiar and centralised, but zero trust with identity-based, per-request verification is required.

/var/lib/kubelet/config.yaml

Why it fails: This file holds kubelet runtime configuration, not static pod manifests; those reside in /etc/kubernetes/manifests. It is tempting because kubelet settings govern pod behaviour, but the kubelet config file is consumed by the kubelet service, not scanned for static pods.

/etc/default/kube-proxy

Why it fails: kube-proxy runs as a DaemonSet on worker nodes, not as a static pod, so /etc/default/kube-proxy holds only its environment flags. Static manifests live in /etc/kubernetes/manifests. It tempts because kube-proxy is a core component, but it is deployed dynamically rather than via the kubelet.

~/.kube/config

Why it fails: ~/.kube/config is a client-side kubeconfig storing cluster, user and context credentials for kubectl, not a server-side static pod manifest. The kubelet reads manifests only from /etc/kubernetes/manifests. It tempts because it is a familiar control-plane file, but it configures CLI access, not pod scheduling.

NetworkPolicies automatically block all traffic across all namespaces upon cluster installation.

Why it fails: NetworkPolicies are namespaced resources that only take effect once created and selected by pod labels; installation alone changes nothing, since Kubernetes defaults to allow-all ingress and egress. It is tempting because policies do restrict traffic, and a deny-all default would be the correct behaviour to cite if the question asked about a cluster with a default-deny policy applied.

Egress traffic is blocked by default even if no NetworkPolicy is created.

Why it fails: With no NetworkPolicy selecting a pod, Kubernetes permits all ingress and egress by default; egress is never blocked implicitly. It is tempting because egress rules within a policy do restrict outbound traffic, and an explicit default-deny egress policy would be the correct mechanism when an organisation requires outbound traffic to be blocked.

NetworkPolicies apply to cluster nodes rather than individual pods.

Why it fails: NetworkPolicies select pods via label selectors within a namespace; they never target cluster nodes, which are governed by other controls. It is tempting because node-level firewalling and CNI enforcement happen on nodes, and a node-targeted policy would be the right answer if the requirement were host-level traffic filtering rather than pod-level isolation.

etcd auto-compaction is permanently disabled

Why it fails: CIS Benchmark requires etcd auto-compaction to be enabled, not permanently disabled, since unbounded growth degrades the datastore. It tempts because disabling features can appear hardening-related, but compaction is a maintenance safeguard; the benchmark checks the --auto-compaction-retention setting is configured.

etcd is exposed directly on the public internet without authentication

Why it fails: CIS Benchmark requires etcd client and peer traffic to be restricted to trusted networks with authentication and TLS, so public exposure without authentication is a finding, not a verified configuration. It tempts because auditors do check listening addresses and auth flags, but the compliant state is the opposite.

Etcd consensus authorizer.

Why it fails: Etcd is the API server's backing datastore, not an authorisation module; it stores cluster state and never evaluates SubjectAccessReviews. The authorisation chain comprises Node, ABAC, RBAC and Webhook modes. Etcd's consensus mechanism is tempting because it governs data consistency and quorum, which matters for storage durability, not for deciding whether a request is permitted.

Kube-proxy IPVS routing authorizer.

Why it fails: Kube-proxy IPVS routing balances service traffic on nodes; it is not an API server authorization module. It is tempting because kube-proxy is a genuine Kubernetes networking component, but authorization modes are RBAC, ABAC, Node and Webhook, which evaluate API requests rather than routing service packets.

Removing all TLS certificates from the kubelet configuration.

Why it fails: Stripping TLS certificates leaves kubelet traffic unencrypted and unauthenticated, allowing interception and impersonation rather than preventing unauthorised access. It is tempting when certificate rotation or handshake errors block a node, and would only be acceptable in an isolated test cluster with no network exposure.

Setting kubelet authorization mode to AlwaysAllow.

Why it fails: AlwaysAllow grants every request without consulting authorisation, so any caller reaching the kubelet API can inspect or control containers. It is tempting during troubleshooting because it removes authorisation denials, and it would be chosen only in a disposable lab where access control is deliberately out of scope.

Enabling the kubelet read-only port 10255.

Why it fails: Port 10255 serves unauthenticated read-only kubelet data, exposing pod specs and container details to anyone who can reach it, so enabling it weakens security. It is tempting as a monitoring convenience: read-only access needs no credentials, which suits trusted, isolated networks where scraping metrics without auth is desired.

Allowing unrestricted use of the host network and host PID namespaces

Why it fails: Restricted mandates hostNetwork: false and hostPID: false, so permitting unrestricted host namespace access fails the profile. It is tempting because host networking and host PID are valid configurations under the privileged profile for infrastructure pods needing node-level visibility, such as monitoring or networking agents.

Enabling privileged mode for all standard workloads

Why it fails: Restricted forbids privileged containers outright, requiring privileged: false plus dropping ALL capabilities, so enabling privileged mode contradicts the profile rather than satisfying it. It is tempting because privileged mode is a legitimate setting for system-level workloads such as CNI plugins or node agents, where namespaces like baseline or privileged permit it.

isolated

Why it fails: The three official Pod Security Standard levels are privileged, baseline and restricted; "isolated" is not among them. It tempts because isolation describes what restricted policies achieve through seccomp, capabilities and volume controls, so the label feels like a real enforcement level.

secure

Why it fails: Kubernetes recognises exactly three Pod Security Standard levels: privileged, baseline and restricted. "Secure" is not one of them. It tempts because it sounds like the natural opposite of privileged and matches the intent of restricted, which is the actual hardened level.

Kubernetes NetworkPolicy egress CIDR blocks

Why it fails: NetworkPolicy egress CIDR blocks restrict outbound pod traffic; they filter packets after authentication and never verify client identity at the API server. It is tempting because NetworkPolicy is a genuine Kubernetes security control, but it is correct only for segmenting pod traffic, not for authenticating API requests.

PersistentVolume claim capacity metadata

Why it fails: PersistentVolume claim capacity metadata describes storage allocation for volumes; it plays no part in authenticating API requests. It is tempting because PVCs are core Kubernetes objects, but they are the right answer only when sizing or binding storage, not when identifying clients via certificates, tokens, or OIDC.

Container image pull secrets stored in private registries

Why it fails: Image pull secrets authenticate a kubelet to a private registry when fetching images; they never reach the API server as client credentials. It is tempting because these secrets are Kubernetes authentication artefacts, but they are correct only for registry access, not for authenticating API requests via certificates, tokens, or OIDC.

Store plaintext passwords directly inside Dockerfile ENV directives

Why it fails: NIST SP 800-190 recommends injecting secrets at runtime through a secrets manager or orchestrator, never baking plaintext credentials into image layers. It is tempting because ENV directives are a convenient way to pass configuration, but they persist in image metadata and are readable by anyone pulling the image.

Rely exclusively on public unverified base images to speed up development

Why it fails: The framework requires base images from trusted, verified sources with provenance and vulnerability scanning; unverified public images introduce unpatched flaws. It is tempting because public images accelerate development, yet NIST SP 800-190 treats image provenance and scanning as mandatory controls.

serviceSelector

Why it fails: serviceSelector is not part of the NetworkPolicy peer specification; ingress sources are defined with podSelector and namespaceSelector only. It is tempting because services front pods and seem a natural way to name traffic origins, but Kubernetes selects peers by pod and namespace labels, not by Service objects.

ingressSelector

Why it fails: NetworkPolicy ingress rules accept only podSelector and namespaceSelector; ingressSelector is not a field in the API schema, so the manifest is rejected. It is tempting because the name mirrors the ingress rule structure, but selecting source pods is done with podSelector, optionally combined with namespaceSelector.

nodeSelector

Why it fails: nodeSelector schedules pods onto nodes and never appears inside a NetworkPolicy ingress rule; peer selection uses podSelector and namespaceSelector. It is tempting because it is a genuine Kubernetes selector field, but it targets node labels for scheduling, not traffic sources for policy peers.

Etcd is encrypted at rest using a customer-managed KMS encryption provider.

Why it fails: Encrypting etcd at rest with a customer-managed KMS key protects stored secrets from disk-level access and does not grant a compromised pod any path to escalate privileges or reach other components. It is tempting as a security control, but it is a hardening measure rather than a weakness enabling lateral movement.

The cluster uses a properly configured PodSecurityStandard of Restricted across all namespaces.

Why it fails: A correctly applied Restricted PodSecurityStandard blocks privileged containers, host namespace access and hostPath mounts, removing the mechanisms a compromised pod would use to escalate or pivot. It is tempting to flag any cluster-wide policy, but this one restricts the attacker rather than aiding them.

Disabling all automated security tooling to speed up commits

Why it fails: Shift-Left moves security checks into development, so disabling automated tooling removes the pre-commit and pipeline scanning that embodies the philosophy. It is tempting because faster commits appear to reduce friction, yet automation is precisely what Shift-Left relies on; manual, post-deployment review is its opposite.

Waiting until a production breach occurs to audit logs

Why it fails: Shift-Left detects and remediates issues during design, coding and CI, so auditing only after a production breach is reactive detection, not early prevention. It appeals because post-incident forensics is a genuine security activity, but that belongs to incident response, not to shifting controls earlier in the lifecycle.

Relying entirely on manual code reviews post-release

Why it fails: Shift-Left embeds automated, continuous security checks in the pipeline, so relying solely on manual post-release review reintroduces late, human-dependent gates. It is tempting because code review is a legitimate quality control, but performed after release it cannot prevent defects reaching production, which is what Shift-Left targets.

Configuring kubelet authorization mode to Webhook.

Why it fails: Webhook authorization is the recommended secure kubelet mode, so configuring it strengthens rather than compromises the control plane. It is tempting because the option names a kubelet setting, and misconfigured kubelet authorisation genuinely is a risk, but Webhook is the mitigation, not the vulnerability.

Enabling etcd encryption at rest with a valid key.

Why it fails: Encrypting etcd at rest with a valid key protects control plane data, so it mitigates rather than introduces compromise. It is tempting because etcd holds secrets and misconfigured encryption can expose them, but a valid key with encryption enabled is the recommended hardening control, not a weakness.

Relying solely on the cloud provider's default network security group for all protection

Why it fails: Default security groups are provider-managed and identical across tenants, so they cannot serve as a layered control you own. Relying on them alone removes the network-policy and workload-level segmentation that defence in depth demands; custom policies and pod-level controls provide that.

Granting all developers cluster-admin permissions for operational speed

Why it fails: Granting cluster-admin to all developers collapses the authorisation layer, removing least-privilege separation that defence in depth requires. It is tempting for operational convenience, but RBAC scoping with namespace-bound roles is the control that actually limits blast radius.

Running all containers in privileged mode

Why it fails: Privileged mode grants containers full host capabilities and device access, removing the isolation that prevents breakouts. It tempts because it resolves permission errors quickly during troubleshooting, and would be chosen if the workload genuinely required host-level access, but it maximises escape risk.

Mounting host /proc and /sys directories in read-write mode

Why it fails: Read-write host /proc and /sys mounts expose kernel and host interfaces, enabling breakout rather than preventing it. It tempts because some tooling needs host metrics, and would be acceptable if mounted read-only and narrowly scoped, but write access directly undermines isolation.

Automatically updating kernel modules on the underlying worker node

Why it fails: Admission webhooks evaluate Kubernetes API requests at creation time; they cannot reach onto worker nodes to patch kernel modules, which is node configuration management. It is tempting because kernel vulnerabilities affect container isolation, and it would be correct as a node-level hardening task performed by configuration management or a patched AMI.

Manually restarting unhealthy pods across worker nodes

Why it fails: Admission webhooks act on API requests before objects are admitted; restarting running pods is a runtime remediation performed by controllers such as Deployments or liveness probes. It is tempting because unhealthy pods are a security and reliability concern, and it would be correct as ongoing operational recovery rather than admission-time policy.

InsecureServing

Why it fails: InsecureServing is a removed API server flag for serving plain HTTP, not an admission plugin, so it cannot enforce policy at admission time. It is tempting because its name suggests a security setting, but it concerns transport, not admission control.

AlwaysAllow

Why it fails: AlwaysAllow permits every request without evaluation, so it enforces no security policy at admission time and defeats the auditor's compliance goal. It is tempting as a permissive default for troubleshooting clusters, where blocking admission would hinder debugging, but it is never a security control.

kubelet automatically runs security audits on all container images prior to pull.

Why it fails: Admission controllers intercept API server requests; the kubelet pulls images and runs containers, performing no pre-pull security audit. The option tempts candidates who associate image scanning with cluster security, but image scanning belongs to registry or CI tooling, not the admission control request path.

etcd executes consensus validation scripts to strip unauthorized RBAC rules.

Why it fails: etcd is a key-value store providing consistent storage and watch semantics; it runs no validation scripts and cannot strip RBAC rules. Admission controllers enforce policy in the API server's admission chain before persistence. etcd would be the correct focus when discussing backup, quorum, or encryption-at-rest of cluster state, not policy enforcement.

kube-proxy inspects network payloads at Layer 7 to block unauthorized API requests.

Why it fails: kube-proxy programs iptables/IPVS rules for Service traffic on nodes; it never parses Layer 7 payloads or intercepts API server requests. Admission controllers run as webhooks or compiled plugins inside the API server's request pipeline. kube-proxy would be relevant when troubleshooting Service load balancing or ClusterIP reachability, not policy enforcement.