CCNA Cks Microservice Vuln Questions — Page 3 of 3

151

MCQeasy

Which command correctly creates a secret from a file named 'config.json'?

A.kubectl create configmap my-secret --from-file=config.json

B.kubectl create secret generic my-secret --from-file=config.json

C.kubectl create secret tls my-secret --cert=config.json

D.kubectl create secret generic my-secret --from-literal=config.json

AnswerB

kubectl create secret generic my-secret --from-file=config.json correctly creates an Opaque Secret named my-secret. The file's basename 'config.json' becomes the data key and its contents become the value; the Secret is then base64-encoded in API responses. This is the standard way to ingest entire files like credentials into Kubernetes without exposing them in the command line.

Why this answer

`kubectl create secret generic` with `--from-file=config.json` reads the file content and stores it as a key-value pair in the Secret, where the key defaults to the filename ('config.json') and the value is the raw file data. This is the standard method for creating a generic Secret from a file in Kubernetes.

Exam trap

The CKS exam often tests the confusion between `--from-file` and `--from-literal`, where candidates mistakenly use `--from-literal` with a filename, expecting it to read the file, or confuse `kubectl create secret generic` with `kubectl create configmap` for storing sensitive data.

How to eliminate wrong answers

Option A is wrong because `kubectl create configmap` creates a ConfigMap, not a Secret, which stores data in plain text without base64 encoding or the security context of a Secret. Option C is wrong because `kubectl create secret tls` expects a TLS certificate and key pair (typically `--cert` and `--key` flags pointing to PEM files), not a JSON configuration file; using `--cert=config.json` would misinterpret the JSON as a certificate. Option D is wrong because `--from-literal` expects a key=value string directly on the command line (e.g., `--from-literal=key=value`), not a filename; passing `--from-literal=config.json` would treat 'config.json' as a literal key with no value, failing to read the file.

Practice this question →

152

MCQmedium

You need to run a container with a sandboxed runtime using gVisor (runsc). Which Kubernetes resource must be created first to enable this?

A.A RuntimeClass resource with handler: runsc

B.A PodSecurityPolicy that allows the runsc runtime

C.A ValidatingWebhookConfiguration to validate the runtime

D.A priorityClass with a high priority

AnswerA

A RuntimeClass is a cluster-scoped API object that decouples the pod's runtime requirement from the node's runtime configuration. By defining a RuntimeClass named, for example, 'gvisor' with spec.handler: runsc, and then setting runtimeClassName: gvisor in a pod spec, the kubelet informs the CRI (e.g., containerd) to use the runsc OCI-compatible runtime for that pod's containers. This is the only declarative, supported way to select a sandboxed runtime like gVisor per workload, as the handler string maps directly to a runtime registered in the node's CRI configuration.

Why this answer

A RuntimeClass resource is required to define a container runtime configuration that uses gVisor (runsc). When you create a RuntimeClass with handler: runsc, you can then reference it in a Pod spec via the runtimeClassName field, which instructs the kubelet to use the runsc runtime instead of the default runc. This is the foundational step to enable sandboxed runtime isolation for containers.

Exam trap

A common misconception is that runtime selection is done via PodSecurityPolicy or admission webhooks, when in fact it requires a dedicated RuntimeClass resource that maps to a runtime handler configured in the container runtime (e.g., containerd).

How to eliminate wrong answers

Option B is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) controls security context constraints, not runtime selection; it cannot enable a specific runtime like runsc. Option C is wrong because a ValidatingWebhookConfiguration is used to intercept and validate API requests (e.g., enforcing policies), not to configure or enable a container runtime. Option D is wrong because a PriorityClass sets scheduling priority for pods, which has no effect on which container runtime is used.

Practice this question →

153

MCQmedium

A security auditor requires that all pods in a cluster must not run as root. Which Pod Security Standard (PSS) and enforcement mode should be applied at the namespace level?

A.Baseline profile with enforce mode

B.Restricted profile with enforce mode

C.Baseline profile with warn mode

D.Privileged profile with audit mode

AnswerB

The Restricted profile is the most stringent Pod Security level and explicitly mandates runAsNonRoot: true, forcing containers to run as a non-root user. When set to enforce mode, the Pod Security Admission controller rejects any pod that fails this check, along with other Restricted requirements like seccomp and capability drops. This directly satisfies the auditor's demand that no pod runs as root.

Why this answer

The Restricted profile is the only Pod Security Standard that prohibits running containers as root by enforcing the 'MustRunAsNonRoot' security context constraint. Applying it in 'enforce' mode ensures that any pod violating this rule is immediately rejected at admission time, which directly meets the auditor's requirement.

Exam trap

Candidates often mistakenly think that the Baseline profile is sufficient for non-root requirements, but Baseline only blocks host-level privilege escalation and does not prevent containers from running as root. The Restricted profile explicitly requires MustRunAsNonRoot, making it the correct choice.

How to eliminate wrong answers

Option A is wrong because the Baseline profile allows running as root (it only blocks known privilege escalations like hostPID and hostNetwork), so it does not satisfy the 'must not run as root' requirement. Option C is wrong because 'warn' mode only generates a warning without blocking the pod, which fails the auditor's enforcement mandate. Option D is wrong because the Privileged profile permits unrestricted privileges including root access, and 'audit' mode merely logs violations without enforcement, both of which contradict the requirement.

Practice this question →

154

MCQmedium

An administrator wants to enforce a policy that all containers must drop ALL capabilities and not allow privilege escalation. Which YAML snippet correctly implements this requirement in a PodSecurityPolicy-like manner using a security context? (Note: PodSecurityPolicy is deprecated; consider using a ValidatingAdmissionPolicy or OPA/Gatekeeper, but for this question choose the correct security context fields.)

A.securityContext: { privileged: false, capabilities: { drop: ["ALL"] } }

B.securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: ["ALL"] } }

C.securityContext: { allowPrivilegeEscalation: false, capabilities: { add: ["ALL"] } }

D.spec: { allowPrivilegeEscalation: false, capabilities: { drop: ["ALL"] } }

AnswerB

This configuration correctly sets both the allowPrivilegeEscalation field to false, which prevents the container process from gaining additional privileges through mechanisms like setuid executables or non-default capability handling, and drops all Linux capabilities via the capabilities.drop field, so the container begins with zero capabilities. Dropping ALL ensures that even if a vulnerability allows arbitrary code execution, the attacker cannot acquire kernel capabilities to compromise the host. This combination aligns with the Kubernetes Pod Security Standards restricted profile, which requires both settings to be explicitly configured. It is the only option that fully satisfies the policy's requirement.

Why this answer

It sets `allowPrivilegeEscalation: false` to prevent privilege escalation (e.g., via setuid binaries) and `capabilities: { drop: ["ALL"] }` to remove all Linux capabilities from the container. This combination enforces the requirement that containers start with no extra privileges and cannot gain more, aligning with the principle of least privilege in PodSecurityPolicy-like enforcement.

Exam trap

The exam often tests the distinction between `privileged: false` (which only disables privileged mode) and `allowPrivilegeEscalation: false` (which actively prevents privilege escalation), leading candidates to incorrectly choose option A.

How to eliminate wrong answers

Option A is wrong because `privileged: false` is the default and does not prevent privilege escalation; it only disables the privileged mode, but a container could still escalate via setuid binaries or other mechanisms. Option C is wrong because `capabilities: { add: ["ALL"] }` adds all capabilities, which is the opposite of dropping them, granting maximum privileges. Option D is wrong because `spec` is not a valid field inside a container's security context; the correct field is `securityContext`, and `allowPrivilegeEscalation` and `capabilities` must be nested under `securityContext`.

Practice this question →

155

MCQmedium

An administrator wants to enforce that all containers in a Kubernetes cluster run as non-root and have read-only root filesystems using OPA/Gatekeeper. Which two resources must be created?

A.NetworkPolicy and RoleBinding

B.PodSecurityPolicy and ClusterRole

C.ValidatingWebhookConfiguration and MutatingWebhookConfiguration

D.ConstraintTemplate and Constraint

AnswerD

ConstraintTemplate and Constraint are the correct custom resources in the OPA Gatekeeper framework. A ConstraintTemplate defines the rego policy, including the violation message and the parameters schema, while a Constraint instantiates that template with concrete values such as 'required labels' or 'forbidden capabilities'. This two-layer model allows one policy to be reused across many targets with different parameters. Together they implement a declarative admission policy that can reject any Kubernetes resource at admission time.

Why this answer

OPA/Gatekeeper enforces policies via the Constraint Framework, which requires two resources: a ConstraintTemplate (defining the policy logic in Rego) and a Constraint (applying the template to specific resources). Together, they allow you to require containers run as non-root and have read-only root filesystems by evaluating admission requests against the defined rules.

Exam trap

CNCF/CKS often tests whether you understand that OPA/Gatekeeper uses ConstraintTemplates and Constraints as the policy resources, not the underlying webhook configurations or legacy PodSecurityPolicy objects.

How to eliminate wrong answers

Option A is wrong because NetworkPolicy controls network traffic and RoleBinding grants RBAC permissions—neither enforces container runtime security settings like non-root or read-only filesystem. Option B is wrong because PodSecurityPolicy is a deprecated Kubernetes built-in admission controller, not part of OPA/Gatekeeper; OPA/Gatekeeper uses ConstraintTemplates and Constraints instead. Option C is wrong because ValidatingWebhookConfiguration and MutatingWebhookConfiguration are the underlying mechanisms OPA/Gatekeeper uses to register webhooks, but they are not the policy-defining resources; the actual policy logic is in ConstraintTemplates and Constraints.

Practice this question →

156

Multi-Selecthard

Which THREE of the following are capabilities that should typically be dropped from a container to minimize vulnerabilities?

Select 3 answers

A.CHOWN

B.NET_ADMIN

C.NET_RAW

D.KILL

E.SETUID

AnswersB, C, E

CAP_NET_ADMIN grants comprehensive control over the network stack, including the ability to configure network interfaces, manage routing tables, set firewall rules, and manipulate packet filters. This capability is extremely powerful because an attacker can use it to redirect traffic, disable security monitoring, or create rogue network paths, effectively compromising network isolation. Since most containerized workloads do not require low-level network administration, this capability is often dropped as a hardening measure in cluster security policies.

Why this answer

NET_ADMIN (B) is a powerful Linux capability that allows a container to perform network administration tasks such as modifying routing tables, firewall rules (iptables/nftables), and network interface configurations. Dropping this capability prevents a compromised container from altering the host's network stack or bypassing network policies, which is critical for minimizing the attack surface in a microservice environment.

Exam trap

Candidates often mistakenly believe that only network-related capabilities (NET_ADMIN, NET_RAW) should be dropped, but SETUID is also commonly dropped to prevent privilege escalation. Conversely, CHOWN and KILL are typically kept as they are less risky for container isolation.

Practice this question →

157

MCQeasy

To encrypt secrets at rest, which file must be modified on the control plane nodes?

A./etc/kubernetes/scheduler.conf

B./etc/kubernetes/manifests/kube-apiserver.yaml

C./etc/kubernetes/etcd.yaml

D./etc/kubernetes/kubelet.conf

AnswerB

This static pod manifest defines the kube-apiserver's runtime configuration, including command-line flags. To enable encryption at rest, you add the --encryption-provider-config flag here, which points to an EncryptionConfiguration YAML file that specifies the provider (e.g., aesgcm or kms). Because the API server is the only component that directly reads and writes secrets to etcd, this is the correct and canonical place to configure secret encryption.

Why this answer

To enable encryption of secrets at rest in Kubernetes, you must modify the kube-apiserver manifest file at `/etc/kubernetes/manifests/kube-apiserver.yaml` on control plane nodes. This file is a static Pod manifest that defines the API server's startup flags, including `--encryption-provider-config`, which points to an EncryptionConfiguration YAML file specifying the encryption providers (e.g., `aescbc`, `secretbox`) and keys. The API server is the component that writes and reads secrets from etcd, so it is the only place where encryption-at-rest configuration is applied.

Exam trap

CNCF exams often test the misconception that encryption-at-rest is configured by modifying etcd's manifest or configuration files, when in reality it is the API server that handles encryption before data reaches etcd.

How to eliminate wrong answers

Option A is wrong because `/etc/kubernetes/scheduler.conf` is the kube-scheduler's kubeconfig file used for authentication to the API server, not a manifest file for configuring encryption-at-rest. Option C is wrong because `/etc/kubernetes/etcd.yaml` is not a standard Kubernetes manifest; etcd is typically deployed as a static Pod via `/etc/kubernetes/manifests/etcd.yaml` on control plane nodes, but modifying that file would configure etcd itself, not the API server's encryption of secrets before storage. Option D is wrong because `/etc/kubernetes/kubelet.conf` is the kubelet's bootstrap kubeconfig file, used for node registration and authentication, and has no role in encryption-at-rest configuration.

Practice this question →

158

MCQhard

A developer asks you to run a container with gVisor runtime. The cluster has a RuntimeClass named 'gvisor' defined. Which field must be added to the Pod spec to use gVisor?

A.spec.containers[0].runtimeClassName: gvisor

B.metadata.runtimeClassName: gvisor

C.spec.runtimeClass: gvisor

D.spec.runtimeClassName: gvisor

AnswerD

This is the correct placement and spelling. The PodSpec's runtimeClassName field is a string that references the name of a RuntimeClass resource (such as one named 'gvisor') that the kubelet must use to run all containers in the pod. Setting it to 'gvisor' requires that a matching RuntimeClass object with the appropriate handler (e.g., 'runsc') exists in the cluster, and it ensures the pod is scheduled onto nodes that support that runtime.

Why this answer

The `runtimeClassName` field is a top-level field in the Pod spec (i.e., `spec.runtimeClassName`) that specifies the name of the RuntimeClass resource to use for running the Pod's containers. In this case, setting `spec.runtimeClassName: gvisor` instructs the kubelet to use the gVisor runtime (via the 'gvisor' RuntimeClass) for all containers in the Pod, enabling a sandboxed kernel for enhanced isolation.

Exam trap

The `runtimeClassName` field is a top-level field in the Pod spec (`spec.runtimeClassName`). A common mistake is setting it under `metadata` or `spec.containers[]`, or confusing it with the deprecated `runtimeClass` field. This question tests precise knowledge of the CNCF's Kubernetes API.

How to eliminate wrong answers

Option A is wrong because `runtimeClassName` is not a field within `spec.containers[]`; it is a Pod-level field, not a per-container field. Option B is wrong because `runtimeClassName` is not a metadata field; metadata fields are for labels, annotations, names, etc., and runtime configuration belongs in the spec. Option C is wrong because the correct field name is `runtimeClassName`, not `runtimeClass`; the Kubernetes API uses `runtimeClassName` as the exact key in the Pod spec.

Practice this question →

159

MCQhard

Which Istio resource is used to enforce mutual TLS (mTLS) for all services in a namespace, ensuring that traffic between services is encrypted?

A.DestinationRule

B.PeerAuthentication

C.ServiceEntry

D.VirtualService

AnswerB

PeerAuthentication is the Istio security resource that defines mTLS policy for workloads, supporting mesh-wide, namespace-wide, and workload-specific scopes. Setting 'mode: STRICT' requires all incoming connections to use mutual TLS, and the Envoy sidecars enforce this policy at the server end. This is the correct resource for enforcing mTLS in the mesh.

Why this answer

PeerAuthentication is the correct Istio resource for enforcing mutual TLS (mTLS) at the namespace level. It defines the TLS mode for traffic between services, and when set to `STRICT`, it requires that all traffic within the namespace uses mTLS, encrypting both the request and response. This is part of Istio's security features under the `security.istio.io/v1beta1` API group.

Exam trap

A common mistake on the CKS exam is confusing PeerAuthentication (which enforces mTLS at the service-to-service level) with DestinationRule (which configures TLS settings for upstream connections but does not enforce authentication). Candidates often choose DestinationRule when they see 'TLS' in the option.

How to eliminate wrong answers

Option A is wrong because DestinationRule is used to configure traffic routing policies, load balancing, and connection pool settings, not to enforce mTLS authentication; it can define TLS settings for upstream services but does not set the mTLS mode for the namespace. Option C is wrong because ServiceEntry is used to add external services to the Istio service mesh, enabling traffic management and security policies for those external endpoints, but it does not enforce mTLS for internal services. Option D is wrong because VirtualService is used for traffic routing and manipulation (e.g., canary deployments, fault injection), not for authentication or mTLS enforcement.

Practice this question →

160

Matchingmedium

Match each Kubernetes object or feature to its primary security purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Provides an identity for processes running in a pod

Stores sensitive data such as passwords, OAuth tokens, and ssh keys

Stores non-sensitive configuration data in key-value pairs

Specifies security settings for a pod or container

Limits resource consumption per namespace to prevent resource exhaustion

Why these pairings

Correct matches: NetworkPolicy controls network traffic; RBAC controls permissions; SecurityContext defines security settings. Common confusions: ServiceAccount is for identity, not encryption; PodSecurityPolicy is for security constraints, not resource limits.

Practice this question →

161

MCQhard

A Gatekeeper Constraint is not blocking pods that violate the policy. The constraint references a ConstraintTemplate that has been successfully created. What is the most likely cause?

A.The Constraint is missing the 'match' field

B.The Constraint has 'enforcementAction: dryrun'

C.The Constraint is in a different namespace than the pods

D.The ConstraintTemplate is missing the 'violation' rule

AnswerB

This is the correct cause: setting `enforcementAction: dryrun` explicitly tells OPA Gatekeeper to run its evaluation and log any violations to the audit status, but to never reject the admission request. The default enforcement action for a Constraint is `deny`, which blocks the request, but overriding it with `dryrun` disables that blocking while keeping the rule visible in reports. In this mode, deploying a violating Pod will succeed, and the violation will only appear as a status entry or in logs — precisely the symptom described. Fixing this requires changing the value to `deny` (or removing the field entirely) to activate active enforcement.

Why this answer

When a Gatekeeper Constraint has `enforcementAction: dryrun`, it logs violations but does not block pod creation or updates. This is the most likely cause because the constraint is correctly configured and the ConstraintTemplate exists, but the enforcement action is set to dryrun instead of the default `deny`.

Exam trap

A common trap is the misconception that a missing `match` field or namespace mismatch causes a constraint to be ineffective, but the real trap is that `enforcementAction: dryrun` silently allows violations while appearing to be correctly configured.

How to eliminate wrong answers

Option A is wrong because the `match` field is optional in Gatekeeper constraints; if omitted, the constraint applies to all resources in the cluster, so missing it would not prevent blocking. Option C is wrong because Gatekeeper constraints are cluster-scoped resources, not namespaced, so being in a different namespace than the pods is irrelevant. Option D is wrong because the ConstraintTemplate's `violation` rule is not a required field; the template defines the rego logic, and a missing rule would cause a template creation failure, not a silent non-blocking behavior.

Practice this question →