Hard Difficulty 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.

Enabling Horizontal Pod Autoscaling for CoreDNS replicas

Why it fails: Horizontal Pod Autoscaling adjusts replica counts based on load metrics; it performs no validation of operator provenance or permissions. It is tempting because it hardens cluster resilience, but defending against malicious operators requires verifying signatures and reviewing manifests before installation, which autoscaling does not address.

Disabling the Kubernetes Dashboard service deployment

Why it fails: Removing the Dashboard closes one web UI attack surface but does not inspect operator images, signatures or RBAC permissions, so a poisoned catalog operator still deploys. Disabling the Dashboard suits clusters where that add-on's exposure outweighs its convenience, not provenance enforcement.

Configuring liveness probes on all worker nodes to check kubelet responsiveness

Why it fails: Liveness probes only restart unresponsive containers; they inspect no image provenance, signature or operator manifest, so a malicious operator installs and runs unchallenged. Probes belong in availability and self-healing designs, detecting hung kubelets or deadlocked processes, not in admission-time supply chain verification.

IPsec tunnel encapsulation

Why it fails: CIS benchmarks require etcd peer and client connections to use TLS certificates, not IPsec encapsulation, so this fails the stated control. It is tempting because IPsec does encrypt traffic between hosts, and it would be correct for securing node-to-node communication at the network layer rather than etcd's own client authentication.

HTTP with token bearer headers

Why it fails: CIS benchmarks require etcd peer and client traffic to use TLS certificates for mutual authentication, so bearer tokens over plain HTTP leave the data store open to any client that can reach the port. Token headers suit API-server authentication, not etcd's certificate-based transport security.

Plaintext loopback interface binding

Why it fails: Binding etcd to the loopback interface restricts it to local clients only, which breaks the multi-node client access the audit requires. It is tempting because loopback binding genuinely removes external exposure, and it would be correct for a single-node development cluster where no remote client connects.

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.

Set kubelet authorization mode to AlwaysAllow.

Why it fails: AlwaysAllow makes the kubelet authorise every request regardless of identity, so any valid service account token can read arbitrary pod data. It grants no per-request evaluation against a policy. AlwaysAllow is used only in isolated test clusters where authorisation is deliberately bypassed, never where least privilege is required.

Enable anonymous access on port 10250.

Why it fails: Anonymous access on port 10250 removes authentication entirely, so any client reaching the kubelet can read pod logs and environment variables without even holding a token. This widens exposure rather than restricting token holders. Anonymous access is intended only for health probes on read-only endpoints in trusted, isolated networks.

Disable the kubelet authentication certificate.

Why it fails: Disabling the kubelet's client certificate authentication removes a verification mechanism, leaving requests unauthenticated and therefore unconstrained by any authorisation decision. It does not restrict token holders; it strips identity from callers. Certificate authentication is disabled only when another authenticator, such as a webhook, fully replaces it.

PersistentVolumeClaim

Why it fails: A PersistentVolumeClaim requests storage capacity; it cannot hold certificate and key material for Ingress TLS. It tempts engineers who associate volumes with storing files, and it would be right for persisting application data, not for a Secret referenced by the Ingress spec.

CertificateSigningRequest

Why it fails: A CertificateSigningRequest submits a CSR to the Kubernetes certificate API for signing; it does not store the issued certificate and private key pair for Ingress. It tempts teams automating certificate issuance, which suits internal PKI workflows rather than TLS termination secrets.

ConfigMap

Why it fails: ConfigMaps hold non-confidential data in plaintext, so storing a TLS private key there exposes it to anyone with read access to the namespace. It is tempting because ConfigMaps do mount files into pods cleanly, but that pattern suits configuration values, not credentials; a Secret is the resource designed for key material.

etcdctl check membership

Why it fails: No check membership subcommand exists in etcdctl; the verb check is not part of its command set, so it errors. It tempts because the wording mirrors the task, and etcdctl does offer member list and endpoint health. Those two commands together satisfy the requirement.

etcdctl cluster status

Why it fails: The cluster status subcommand reports endpoint health and leader information, not the member list with each member's health. It tempts because it is a genuine etcdctl health command, but member listing requires member list, then endpoint health per member. The stem asks for membership plus per-member health.

kubectl get etcdmembers

Why it fails: kubectl addresses Kubernetes API resources, and etcdmembers is not a registered resource type, so the command fails. It tempts because kubectl is the familiar cluster CLI, but etcd membership is queried with etcdctl against the etcd endpoints, not through the Kubernetes API server.

Enabling Pod Security Standards on the finance namespace.

Why it fails: Pod Security Standards govern pod-level security contexts such as privileged containers and host namespaces; they do not restrict RBAC verbs on Role objects. Preventing Role modification requires RBAC itself, for example restricting create/update/delete on roles. Pod Security Standards would be correct when hardening workload admission rather than protecting authorisation resources.

Setting the Role resource to immutable via 'immutable: true'.

Why it fails: Kubernetes has no 'immutable: true' field on Role objects; that field exists on ConfigMaps and Secrets. The scenario needs RBAC rules denying developers update, patch and delete on roles in the finance namespace. Immutability would be relevant when protecting configuration data from accidental or malicious edits.

A mandatory MutatingWebhookConfiguration that strips administrative verbs.

Why it fails: Mutating webhooks alter object content on admission; they cannot prevent a developer from issuing update or delete calls against a Role, and stripping verbs from a Role spec does not stop its deletion. RBAC authorisation on the roles resource is what blocks manipulation. Webhooks suit enforcing defaults or sidecars, not access control.

EnvoyFilter

Why it fails: EnvoyFilter patches the underlying Envoy proxy configuration for specific workloads; it does not expose an mTLS mode field, so STRICT cannot be set through it. It is tempting because it offers low-level control over proxy behaviour, which suits bespoke traffic manipulation, but cluster-wide peer authentication is declared elsewhere.

AuthorizationPolicy

Why it fails: AuthorizationPolicy defines allow, deny and audit rules for requests after identity is established; it has no mTLS mode field and cannot enforce encryption. It is tempting because it is the Istio resource for access control, but mutual TLS enforcement is a PeerAuthentication concern, not an authorisation one.

DestinationRule

Why it fails: DestinationRule configures traffic policy such as load balancing and connection pool settings for a host, and its TLS block governs origination, not peer authentication mode. It is tempting because it is a traffic-policy resource, but STRICT mTLS enforcement cluster-wide is declared in a mesh-level PeerAuthentication resource.

Zero-trust network architecture

Why it fails: Zero-trust network architecture governs identity-based segmentation and least-privilege access between workloads; it does not govern Linux capability assignment inside a pod. It is tempting because zero trust is a headline cloud native principle, and it would be correct where lateral movement between services went unrestricted.

Shared responsibility model

Why it fails: The shared responsibility model allocates duties between provider and customer; it is not a pod-level configuration control. The violation was granting CAP_SYS_ADMIN, which enables privileged operations and container escape. The shared responsibility model would be the correct framing when deciding which security tasks Microsoft Azure or the customer must perform.

Ephemeral infrastructure design

Why it fails: Ephemeral infrastructure design concerns short-lived, immutable, replaceable workloads; it says nothing about which Linux capabilities a container receives. It is tempting because ephemeral containers are a cloud native best practise, and it would be correct where long-running, manually patched pods drift from their declared image.

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.

Denial of Service

Why it fails: Denial of Service concerns availability, not confidentiality; reading exposed TLS private keys is Information Disclosure, a confidentiality breach. DoS is tempting because STRIDE lists it as a distinct category, and it would be correct if the attacker deleted or exhausted Secrets to disrupt workloads rather than reading them.

Elevation of Privilege

Why it fails: Elevation of Privilege covers gaining capabilities beyond those granted; reading a secret the attacker already has permission to read grants no additional privilege. This category applies when an attacker exploits a flaw to obtain higher access, not when existing read access exposes confidential key material.

Repudiation

Why it fails: Repudiation concerns denying that an action occurred, addressed by logging and non-repudiation controls; it does not describe unauthorised disclosure of secret contents. Repudiation is the relevant category when auditing or signing is absent, not when confidentiality of TLS private keys is breached.

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.

Setting kubelet readOnlyPort to 8080.

Why it fails: This opens an insecure port on worker nodes, worsening security.

Enabling anonymous access.

Why it fails: Anonymous access increases exposure.

Disabling the Node authorizer.

Why it fails: Disabling the Node authorizer removes restrictions on kubelet API access.

By applying a PodSecurityPolicy with spec.hostNetwork set to false.

Why it fails: Host network settings control network namespace sharing, not service account token mounting.

By editing the kube-apiserver manifest to include the --disable-service-account-tokens flag.

Why it fails: This flag does not exist in kube-apiserver; token mounting is controlled per ServiceAccount or per Pod.

By creating a LimitRange that restricts secret volume mounts.

Why it fails: LimitRanges constrain resource quantities (CPU, memory, storage request/limits), not service account tokens.

Add the production label to the target pod's metadata and reference it in the egress block.

Why it fails: Egress controls outgoing traffic; ingress is needed for incoming traffic.

Specify only a 'podSelector' with 'environment=production' without any namespace selector.

Why it fails: Omitting the namespaceSelector restricts the rule to pods within the same namespace only.

Use a cluster-wide ClusterNetworkPolicy resource with global label matching.

Why it fails: While AdminNetworkPolicy exists in some networking stacks, standard NetworkPolicies use namespaceSelector for cross-namespace rules.