Minimize Microservice Vulnerabilities practice questions

Use 'privileged' PSS with Warn mode

Why wrong: Privileged profile disables all Pod Security Standard restrictions, permitting privileged containers, host namespaces, and all Linux capabilities, which maximizes the risk of container breakout. Adding Warn mode does not change this behavior because warning merely adds an admission annotation and does not block or reject the pod, so a compromised container can still leverage root privileges and elevated capabilities to escape.

Use 'baseline' PSS with Audit mode

Why wrong: Baseline profile (non-privileged) does prevent privileged containers and host namespace sharing, but it still allows running as root and keeps default capabilities like CHOWN and SETUID, which are often enough for a breakout. Audit mode is purely reactive: it only logs policy violations and never intercepts them, so pods that violate baseline are admitted and execute with the same dangerous root context, meaning the audit log is of no help during an active attack.

Use 'baseline' PSS with Enforce mode

Why wrong: Baseline with Enforce mode does force every pod to comply with the baseline standard, but baseline still allows root user execution and default capability sets. Even with enforcement, a root-running pod can install kernel modules, modify host files if volumes are mounted, or use standard tools like mount/nsenter to break out, so the enforcement is meaningless if the policy itself is too permissive for the threat model.

Set `securityContext.runAsNonRoot: true` in the Pod spec

Why wrong: Setting runAsNonRoot: true only enforces a non-zero UID for the container's main process; it does not alter the mount options of the root filesystem. A non-root process can still write to directories it owns or has write permissions for, so this setting alone fails to prevent modifications to the container's writable layer.

Mount an emptyDir volume to the container's writable directories

Why wrong: Mounting an emptyDir volume at writable directories just provides ephemeral in-memory or ephemeral-disk storage that disappears with the Pod. EmptyDir volumes are explicitly writable, so they do not set the root filesystem to read-only; they merely redirect writes under that mount point. Any other writable path in the root filesystem remains modifiable.

Set `securityContext.privileged: false` in the Pod spec

Why wrong: privileged: false is the Kubernetes default and only prevents the container from gaining host privileges like device access or seccomp/profile escalation; it has no bearing on whether the root filesystem is writable. A standard, unprivileged container still has a writable root filesystem layer, so this setting does not satisfy the read-only requirement.

Apply a NetworkPolicy to block egress traffic from the Pod

Why wrong: A NetworkPolicy governs network flow at L3/L4 and cannot restrict the syscalls a container process can invoke. A vulnerable system library is present in the image and executes locally; even blocking all egress, an attacker who compromises the container can still trigger the syscall inside the Pod. Therefore it does not address the reported library vulnerability.

Apply an AppArmor profile to the Pod

Why wrong: AppArmor is a mandatory access control LSM that constrains file paths, capabilities, and network access but does not provide fine-grained syscall filtering. Many syscalls tied to library CVEs require no file access, so an AppArmor profile may allow the vulnerable call. Unlike seccomp, it cannot reliably block the specific syscall by number, making it an incomplete fix.

Use a PodSecurityPolicy to drop all capabilities

Why wrong: PodSecurityPolicy, deprecated and removed in Kubernetes 1.25, controls security context features such as capabilities, but capabilities are privilege flags, not syscall denylists. A system library CVE is often exploitable through an unprivileged syscall, so dropping all capabilities leaves the vulnerable syscall available. The legacy PSP mechanism also cannot be applied on modern clusters and is not a syscall mitigation.

Add `DAC_OVERRIDE` capability

Why wrong: DAC_OVERRIDE bypasses file permission checks; not related to DNS or TCP sockets.

Add `NET_ADMIN` capability

Why wrong: NET_ADMIN is for network administration tasks; creating TCP sockets does not require it.

Add `NET_BIND_SERVICE` capability

Why wrong: NET_BIND_SERVICE allows binding to privileged ports; DNS client uses ephemeral ports, not required.

Set the container's root filesystem as read-only

Why wrong: Setting the container's root filesystem to read-only (readOnlyRootFilesystem: true) does prevent an attacker from writing malware or tampering with system binaries inside the container image, which is a strong integrity control. However, it does nothing to restrict the container's ability to communicate with other pods, reach external services, or abuse legitimate tools already present inside the image. An attacker can still perform lateral movement, exfiltrate data, or interact with services across namespaces using existing binaries and outbound connections, so this measure alone does not confine a compromise's movement.

Run the container as root to simplify debugging

Why wrong: Running the container as root (or with a privileged user) violates the principle of least privilege and dramatically increases the risk of a container breakout. Even with a non-privileged container, a kernel exploit that lets an unprivileged root process (e.g., via CAP_SYS_ADMIN or chroot escapes) gain host root access becomes far more damaging if the attacker already controls a root process inside the container. Root also gives the process full freedom to read sensitive files, install setuid binaries, and interact with host devices if security contexts are not restricted, thereby enlarging the blast radius in ways that resource limits or network policies cannot contain.

Use hostNetwork: true to share the host's network namespace

Why wrong: Setting hostNetwork: true grants the container the exact same network namespace as the host machine, meaning every socket opened by the compromised container appears as a host process and can bind to any host interface. This bypasses the pod-level network isolation that Kubernetes normally provides, allowing the attacker to sniff host network traffic, connect to internal services on the host, and potentially interfere with other containers or the kubelet. It also makes NetworkPolicy ineffective because pod egress/ingress rules are typically not enforced for pods using the host network namespace, greatly expanding the attack surface.

Use images from any public registry for flexibility

Why wrong: Relying on arbitrary public registries exposes the supply chain to untrusted and unvetted content; attackers can publish malicious images or simply provide outdated packages with known vulnerabilities. Without a curated allowlist of vetted registries, you cannot guarantee image provenance, integrity, or licensing compliance. This flexibility thus introduces serious security risks that automated scanning alone cannot fully mitigate.

Always use the latest tag to get the most recent patches

Why wrong: The latest tag is a mutable pointer that shifts with every push, so builds become non-reproducible and mystery changes can silently break container behavior. This makes audits and rollbacks difficult because you cannot determine the exact image contents that originally ran. Instead, reference images by immutable digest or a release-specific tag to ensure verifiable, consistent deployments and controlled patch updates.

Containers can run in privileged mode

Why wrong: The PSP snippet explicitly sets `privileged: false`, which denies privileged mode. In Kubernetes, if `privileged` were true, the container would have full host access and bypass most security restrictions, but this policy prevents that. Therefore, the statement that containers can run in privileged mode is incorrect.

Containers cannot use ConfigMap volumes

Why wrong: The `volumes` list in the PSP explicitly includes `configMap`, so ConfigMap volumes are permitted. Kubernetes PSPs require each volume type to be explicitly allowed; any missing type is denied. Since configMap is listed, containers can mount ConfigMap volumes, making this option wrong.

Containers must run as the root user

Why wrong: The policy specifies `runAsUser.rule: MustRunAsNonRoot`, which enforces that containers run as a non-root user (UID not 0). This is the opposite of requiring root. Additionally, the PSP may also set `runAsUser` ranges, but the rule itself forbids root execution, so saying it must run as root is false.

The container is running without any capabilities

Why wrong: The command output shows a non-zero CapEff bitmask with many capability bits set. A process with no capabilities would report CapEff as 0x0, but here the effective set grants the container process numerous privileged operations. The presence of these bits directly refutes the claim that the container is running capability-less.

The container has dropped all capabilities except NET_BIND_SERVICE

Why wrong: If only CAP_NET_BIND_SERVICE were retained, the CapEff bitmask would contain exactly one bit set (bit 10, corresponding to the value 0x400). The observed mask is far broader than a single bit, so the container retains many other capabilities. Dropping to that single capability would be a restrictive posture, but it is not what the data shows.

The container has default Docker capabilities, which is secure

Why wrong: Docker's default container capability set is a curated subset, typically around 14 capabilities such as CHOWN, DAC_OVERRIDE, NET_RAW, and SETUID, and excludes dangerous ones like SYS_ADMIN and SYS_MODULE. The provided CapEff mask includes all capability bits, not just that allowed default subset. Therefore claiming it is a secure default is incorrect; the mask must equal Docker's default list, which it does not.

Manually inject sidecar proxies into every pod to enforce mTLS.

Why wrong: Manually adding sidecar proxies to every Pod is not a secure, scalable mTLS strategy: it relies on human consistency, so any Pod that misses the injection will communicate using plaintext traffic and violate the service-mesh policy. Every Pod should instead be intercepted automatically by a mutating admission webhook or a managed sidecar injection mechanism (e.g., Istio or Linkerd), which labels and rewrites Pod specs consistently. Manual injection also complicates upgrades and forces operators to manage proxy configuration drift, creating gaps in identity coverage and encrypted connectivity between services.

Run containers in privileged mode to allow them to perform necessary system calls.

Why wrong: Privileged mode is far broader than simply allowing necessary system calls: it disables most container isolation, grants all capabilities (including CAP_SYS_ADMIN), exposes host devices, and effectively lets the process operate as root on the host for kernel operations, making container escape trivial if the workload is compromised. Kubernetes workloads almost never need this; instead, the correct hardening step is to drop all capabilities, add only the required Linux capabilities, and apply a seccomp profile that filters the exact system calls. Running privileged to satisfy a few syscalls needlessly elevates every microservice to maximum host access.

Store secrets directly in container images for easy access.

Why wrong: Baking secrets into a container image is fundamentally insecure because every image is built from immutable layers; anyone who can pull the image from a registry, cached copy, or CI artifact can inspect the layer history and extract plaintext credentials. Secrets placed in images also spread across base images and tags, making revocation and rotation impractical and turning each image into a persistent credential leak. Use Kubernetes Secrets (with RBAC, encryption at rest, and short-lived credentials) or an external secrets manager so secrets are delivered only to the Pod that actually needs them.

The seccomp profile must be set via an admission controller, not OPA.

Why wrong: OPA/Gatekeeper is an admission controller that can absolutely be used to enforce seccomp profiles by validating the `securityContext` of incoming resources. The explanation is not that a different admission controller is required; rather, the constraint's logic is looking at the pod-level field while the Deployment actually sets the seccomp profile inside each container's `securityContext`. This tooling is fully capable of the enforcement, but the scope of the check is the root cause of the bypass.

OPA/Gatekeeper is not properly installed or the constraint is not active.

Why wrong: If OPA/Gatekeeper were not properly installed, or if the constraint template had not been instantiated as a Constraint with a `match` scope covering this Deployment, the system would probably reject all checks or apply no constraint at all. Since the constraint is still enforcing other checks (like privileged containers), the admission controller is active and functioning. The defect is not in the deployment or activation of Gatekeeper, but in the specific JSON path used inside the violation rule.

The cluster's nodes do not support seccomp, so the profile is ignored.

Why wrong: Seccomp is a Linux kernel feature, and modern Kubernetes nodes—especially those running containerd 1.6 or newer—enable it by default through the default profile. Even if a profile were ignored due to node limitations, the failure would manifest as a warning or error from the kubelet during pod creation, not as a silent pass in the policy check. The cluster's nodes are capable, so the reason the Deployment passes must be the constraint's field‑level logic.

Run containers as root to avoid permission issues.

Why wrong: Running containers as root violates the principle of least privilege and dramatically enlarges the damage a compromised process can do; if the container escapes, the attacker already has host root-equivalent UID 0. Permission issues should be solved with a non-root securityContext (runAsUser, fsGroup), allowed group IDs, or admission controls like Pod Security Admission, never by falling back to root.

Allow all egress traffic from pods to simplify network management.

Why wrong: Permitting unrestricted egress traffic removes the network layer's ability to contain a breach; if a pod is compromised, an attacker can exfiltrate data to any external IP and also pivot to internal services. Best practice is a default-deny egress NetworkPolicy that allows only specific destinations (e.g., port 443 to trusted API hosts) and also constrains pod-to-pod egress via policy, rather than allowing all connections.

Use hostNetwork: true for pods to improve network performance.

Why wrong: Using hostNetwork: true attaches the pod directly to the node's network namespace, so network policies governing pod-to-pod traffic are silently bypassed and the pod's ports can collide with kubelet, host services, or other daemons. This also lets an attacker who compromises the pod see host-level network traffic and interact with node-local services, significantly expanding the blast radius; performance gains are usually negligible compared with the isolation loss.

Encrypt traffic by configuring TLS certificates in each pod's environment variables and updating the application code to use HTTPS.

Why wrong: Putting TLS certificates in environment variables and rewriting application code to use HTTPS is far from minimal overhead. Certificate material in env vars is exposed via the pod spec and any consumer of the Kubernetes API, and it does not protect against direct pod access. This approach also only secures selected endpoints, fails to provide mutual TLS, and forces a separate deploy and key rotation for every service.

Use Kubernetes NetworkPolicies to restrict pod-to-pod communication based on labels and namespaces, and enable TLS in each service's code.

Why wrong: NetworkPolicies are not an encryption mechanism: they only filter traffic by labels, namespaces, IP, and port (L3/L4) and say nothing about the authenticity or confidentiality of the traffic they allow. Not only do they leave service data plaintext, but adding TLS in each service's code reintroduces application-level changes and fragmented certificate management, so this solution still misses the transparent mutually authenticated encryption requirement.

Move all services to a separate overlay network using Weave Net and enforce egress rules with iptables on each node.

Why wrong: Moving to a Weave Net overlay network only changes how pods are networked; it does not add encryption or authentication between pods. Enforcing egress with iptables on each node is a static, IP-based approach that is tedious to maintain in a dynamic cluster, provides no service identity, and still leaves all allowed traffic unencrypted.

Apply the NetworkPolicy using kubectl apply, then create the YAML manifest, then deploy test pods, then verify connectivity.

Why wrong: This sequence is impossible because `kubectl apply` requires a manifest to already exist — you cannot apply a NetworkPolicy that has not yet been written. Even if the two steps were logically swapped, this ordering creates a nonsensical workflow where a policy is applied from a nonexistent file, and any attempt would fail with a 'file not found' error. Additionally, it leaves no record of what policy was actually applied, since the YAML was never created; so the subsequent verification steps are meaningless. A valid workflow must start with authoring the YAML manifest, then applying it.

Create the NetworkPolicy YAML, then deploy test pods, then apply the policy, then verify connectivity.

Why wrong: This order introduces an unprotected time window: test pods are deployed before the policy exists, so they can communicate freely under the default allow-all behavior. When the NetworkPolicy is applied later, it only governs new connections — already-established sessions may remain unaffected depending on the CNI, and the verification step, which runs after policy application, does not test the traffic that occurred in that initial unblocked period. Furthermore, if a problem is detected, it is difficult to tell whether it was caused by the policy being absent initially or by a flaw in the policy itself, because the pods were never observed under enforcement from the start.

Deploy test pods, then create and apply the NetworkPolicy, then verify connectivity.

Why wrong: Starting with test pods means the cluster runs in a default-permissive state before the NetworkPolicy exists, so any inter-pod communication that occurs during that period is completely unrestricted and goes unverified. After the policy is created and applied, existing connections may not be re-evaluated (depending on the CNI implementation), so some connections between the test pods could remain allowed even though the policy should deny them, producing misleading results when you verify connectivity. This order also delays the enforcement point, meaning a security-sensitive workload would be exposed in the interim, which defeats the purpose of applying a NetworkPolicy in the first place.

Step 1: Build and push container image, Step 2: Install Trivy, Step 3: Scan image with Trivy, Step 4: Parse results and enforce policies

Why wrong: Building and pushing the container image before Trivy is installed creates a dangerous gap: an unverified image has already been published to the registry, and only later do you provision the scanner. This means a vulnerable image could be pulled by other teams or deployed before the scan ever runs. Additionally, Trivy's database and checks should be in place at the start of the pipeline so that image creation can be blocked or gated immediately if a scan is required as a pre-commit or pre-push check. The correct sequence puts tool installation ahead of artifact generation to integrate security from the beginning.

Step 1: Install Trivy, Step 2: Scan image with Trivy, Step 3: Build and push container image, Step 4: Parse results and enforce policies

Why wrong: Scanning before the image is built and pushed is impossible because Trivy needs a concrete image reference (e.g., repo:tag or a local image ID) to enumerate package versions and compare them against its vulnerability database. If no image exists, trivy image will throw a manifest unknown error or an invalid reference error, and the pipeline would abort. Even if you intended to scan the Dockerfile or build context, Trivy does not perform static analysis on source—it inspects the final image filesystem. Therefore, the build-and-push step must always precede any vulnerability scanning.

Step 1: Install Trivy, Step 2: Build and push container image, Step 3: Parse results and enforce policies, Step 4: Scan image with Trivy

Why wrong: Parsing results and enforcing policies before scanning is logically impossible because there is no scan output—no JSON report, no SARIF, no list of CVEs—to feed into your admission controller or policy engine. The enforcement step consumes the scan findings to decide whether to allow or block deployment; without that data, you would be making decisions based on no evidence. In practice, tools like OPA or Kyverno evaluate Trivy's report after the scan completes, so scanning must be the immediate third step. Only after vulnerabilities are collected can you parse the results and apply thresholds or exceptions.

ServiceAccount: Encrypts secrets at rest

Why wrong: ServiceAccounts are Kubernetes identities that pods use to authenticate to the API server; they do not perform any encryption or decryption of stored data. Encryption at rest is handled independently by etcd encryption configuration (encryption-provider-config) using KMS, AES-CBC, or secretbox, and by volume encryption mechanisms in cloud providers. Saying ServiceAccount encrypts secrets conflates identity with cryptographic protection.

PodSecurityPolicy: Defines CPU and memory limits for pods

Why wrong: PodSecurityPolicy (now deprecated in favor of Pod Security Admission) is a cluster-level admission controller that enforces security constraints on pod creation, such as preventing privileged containers, restricting host namespaces, requiring seccomp/AppArmor profiles, and constraining volume types. It has never controlled CPU or memory requests/limits; resource bounds are managed separately by ResourceQuota and LimitRange objects. This option misattributes resource governance to a policy designed for privilege and hardening.

Egress rule: In a NetworkPolicy, specifies which incoming traffic is allowed to reach pods.

Why wrong: This statement is false because egress rules govern outbound connections from pods, not inbound traffic. An egress rule in a NetworkPolicy specifies which destinations—pods, namespaces, or IP/CIDR blocks—and which ports the selected pods are permitted to reach when initiating connections. Incoming traffic is controlled by ingress rules; swapping the two is a common misunderstanding that can lead to accidental over-permissive or over-restrictive policies.

Calico network policy: A Kubernetes native resource for network segmentation.

Why wrong: This answer is incorrect because Calico network policies are not native Kubernetes resources; they are custom resources introduced by the Calico CNI plugin. Native Kubernetes network segmentation is achieved through the built-in NetworkPolicy API, which CNI plugins implement to enforce rules. Calico's custom policy resource depends on Calico being installed as the cluster's networking solution or at least having its CRDs registered, so it is not part of core Kubernetes.

violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.capabilities.drop == "ALL" }

Why wrong: This policy incorrectly targets `capabilities.drop` rather than `runAsUser`. The expression `capabilities.drop == "ALL"` is also malformed: `capabilities.drop` is a list (e.g., `["ALL"]`), so comparing it to a string will never match a standard YAML manifest. Even if it matched, dropping all capabilities does not change the user ID; a container can still run as UID 0 with no capabilities, so this would neither flag nor prevent running as root.

violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.securityContext.runAsUser == 0 }

Why wrong: This rule checks the pod-level `securityContext` but completely ignores container-level settings. While the field path `input.review.object.spec.securityContext.runAsUser` is valid, it only sees the pod default and misses per-container `securityContext.runAsUser: 0`, which is the more common place to set it. A pod could have no root at the pod level yet contain containers running as root, so this policy would allow violations to pass.

violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }

Why wrong: This policy is wrong because it flags containers that set `runAsNonRoot: true`, which is the exact opposite of the intended constraint. `runAsNonRoot` is a boolean that, when true, requires the container to run as a non-root UID; it is a security control that prevents root, not an indicator of root. Denying pods that enforce non-root would block safe workloads and leave actual root-running containers (where `runAsNonRoot` is false or unset) untouched.

DestinationRule

Why wrong: DestinationRule is a traffic-management API that controls load balancing, connection pool, and TLS settings for upstream hosts. While it can set client-side TLS context (e.g., for originating mutual TLS to external services), it does not enforce mTLS on workloads within the mesh. mTLS enforcement is a server-side policy, which belongs to PeerAuthentication, not DestinationRule.

ServiceEntry

Why wrong: ServiceEntry is used to add external or non-registered services to Istio's service registry, enabling traffic management and observability for those destinations. It is a discovery/routing resource and contains no fields for authentication, TLS modes, or credential validation. Thus, it cannot enforce mutual TLS.

VirtualService

Why wrong: VirtualService defines routing rules for traffic between services, such as URI-based forwarding, header matching, and traffic weight shifting. It is purely a traffic-management construct and does not include any authentication or mTLS enforcement options. Security policies like mTLS are handled by separate resources like PeerAuthentication.

kubectl run webhook --image=webhook --restart=Never

Why wrong: This command creates a standalone Pod using the --restart=Never flag, which forces a Pod rather than a Deployment. It does not create a ValidatingWebhookConfiguration, and the arbitrary image 'webhook' is irrelevant to the API server's admission configuration. To register an admission webhook, you must provide a YAML manifest with the proper kind and apiVersion, then apply it.

kubectl create -f webhook.yaml

Why wrong: This works only on the first run, because kubectl create is imperative: it attempts to create a brand-new resource and returns an error if a ValidatingWebhookConfiguration with that name already exists. Unlike apply, create does not compute a diff against the live object or the last-applied configuration, so it is unsuitable for updating webhook definitions. Prefer apply for declarative management to avoid breaking re-runs.

kubectl expose deployment webhook --port=443

Why wrong: This command creates a Service object that fronts the pods of a Deployment named 'webhook' on port 443, but it does not register any admission webhook with the API server. A ValidatingWebhookConfiguration is a separate, cluster-scoped resource that tells the kube-apiserver which URL or service to call during request validation. Using expose here would not produce the required configuration kind, and no service definition alone can enable admission control.

Run kubectl get secret -o yaml and check for an encryption annotation.

Why wrong: The kubectl get secret -o yaml command retrieves the secret through the API server, which transparently decrypts the data before returning it, so you see plaintext (base64-encoded but unencrypted) values. Kubernetes does not add an annotation to secret objects indicating whether encryption at rest is enabled; annotations are arbitrary metadata and would not reflect storage-layer encryption. Additionally, the API server decrypts the data in memory, so there is no encrypted representation in the YAML to inspect.

Use kubectl describe secret and look for 'Encrypted: true'.

Why wrong: The kubectl describe secret command displays secret metadata, type, and data field names (with sizes), but it never includes an 'Encrypted' field or any indication of encryption status because the Kubernetes API does not expose such information. Encryption at rest is a storage-layer feature of the etcd backend, completely invisible to API clients. The output format is fixed by the API server and will not show a boolean flag like 'Encrypted: true'.

Check the apiserver logs for encryption status messages.

Why wrong: API server logs may record configuration details at startup, such as the chosen encryption provider or errors loading the EncryptionConfiguration file, but they do not log per-secret encryption status for read or write operations. Each secret is encrypted and decrypted in the storage layer on the fly, and these operations are not audited by default nor written to the event log. Therefore, examining logs would not give you any definitive information about whether a specific secret is encrypted at rest.