Minimize Microservice Vulnerabilities
Free Certified Kubernetes Security Specialist practice — 6 questions on Minimize Microservice Vulnerabilities, with explanations. No sign-up. Full 12-question mixed test →
A security team needs new pods created in the 'payments' namespace to be blocked at admission time if they violate the Restricted Pod Security Standard (e.g., run as root or request hostNetwork). Pods currently running in the namespace must NOT be disrupted or evicted. Which action BEST meets these requirements?
Pod Security Admission (PSA) is evaluated only at admission time (create/update requests). Setting the 'enforce' mode to 'restricted' blocks new non-compliant pods from being created but never inspects or evicts already-running pods, satisfying both requirements exactly.
You must run an untrusted, multi-tenant workload with the strongest possible isolation boundary using a Kubernetes RuntimeClass, accepting higher pod startup latency as a tradeoff. Which technology and characteristic correctly describes this choice?
Kata Containers boots each pod inside its own lightweight VM backed by hardware virtualization extensions, providing a true hardware-enforced isolation boundary between the container and the host kernel — the strongest isolation of the RuntimeClass sandbox options, at the cost of slower pod startup than runc or gVisor.
You want the API server to reject any new pod in namespace 'test' that violates the Restricted Pod Security Standard, while pods that merely violate the less-strict Baseline standard should only generate a warning to the client (not be blocked). Which pair of namespace labels achieves this?
Setting enforce=restricted blocks any pod that fails the Restricted profile. Setting warn=baseline separately causes the API server to emit a client-side warning for anything that fails the looser Baseline profile (which restricted pods will already satisfy), without blocking it — matching the requirement exactly.
A Kyverno ClusterPolicy is deployed to prevent pods from running as root. New pods that explicitly set runAsUser: 0 are still successfully created and running as root, but Kyverno reports the violations in its PolicyReport. What is the most likely cause?
Kyverno validate rules support two failure actions: 'Audit' (report violations via PolicyReport but allow the request) and 'Enforce' (reject the admission request). PolicyReport entries with pods still running as root is the textbook symptom of validationFailureAction being left at the default 'Audit' instead of 'Enforce'.
A compliance requirement states that Kubernetes Secret objects must remain confidential even if an attacker obtains a raw copy of the etcd data files (e.g., from a stolen backup). Which control on the kube-apiserver directly satisfies this requirement?
By default, Kubernetes stores Secret data in etcd only base64-encoded (not encrypted). Configuring encryption-at-rest via an EncryptionConfiguration passed with --encryption-provider-config causes the API server to encrypt Secret payloads (e.g., with AES-CBC or an external KMS) before writing them to etcd, so stolen etcd data files remain unreadable without the encryption key.
Which statement correctly describes how Cilium implements pod-to-pod mTLS/transparent encryption, as distinguished from a traditional sidecar-based service mesh?
Cilium's CNI uses eBPF programs attached at the kernel level to enforce network policy and can enable transparent encryption of traffic between nodes using IPsec or WireGuard tunnels. This happens below the application layer, so individual microservices do not need to manage their own TLS certificates for this transport-level protection — a key distinction from sidecar-proxy service meshes like Istio.
Ready for the real thing?
The full course has two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed answer explanations.
Start my full course on Udemy →