Certified Kubernetes Security Specialist CKS CKS Questions 826–845 | Page 12/12

826

MCQhard

You are securing etcd. Which of the following is required to enable TLS client authentication for etcd?

A.Set --auto-tls to true

B.Set --peer-client-cert-auth to true

C.Use --cert-file and --key-file only

D.Set --client-cert-auth to true and provide --trusted-ca-file

AnswerD

The correct configuration is to set --client-cert-auth=true, which forces etcd to require a certificate from every client, and provide --trusted-ca-file to tell etcd which CA to use when verifying those client certificates. Together these flags implement mutual TLS: clients verify the server via the server's certificate, and the server verifies clients via their CA-signed certs. This is the standard way to authenticate and authorize access to etcd in a hardened Kubernetes control plane.

Why this answer

Etcd requires `--client-cert-auth=true` to enforce TLS client certificate authentication for incoming client requests, and `--trusted-ca-file` must be provided to specify the CA certificate used to validate client certificates. Without both, client certificate authentication is not enabled.

Exam trap

The trap here is that candidates confuse `--peer-client-cert-auth` (for inter-node communication) with `--client-cert-auth` (for client-to-server communication), leading them to select option B instead of D.

How to eliminate wrong answers

Option A is wrong because `--auto-tls` enables self-signed TLS for peer and client connections but does not enforce client certificate authentication; it is intended for development or testing, not secure production use. Option B is wrong because `--peer-client-cert-auth` enables client certificate authentication for peer-to-peer communication between etcd members, not for client connections to the etcd API. Option C is wrong because `--cert-file` and `--key-file` only configure the server certificate for TLS, but without `--client-cert-auth=true` and `--trusted-ca-file`, the server will not request or validate client certificates.

Full explanation →

827

Multi-Selecthard

Which THREE of the following are valid flags for enabling admission plugins on the API server?

Select 3 answers

A.--enable-admission-plugins=AlwaysPullImages

B.--enable-admission-plugins=PodSecurity,NodeRestriction

C.--plugin-dir=/admission

D.--enable-admission-plugins=NodeRestriction

E.--admission-control=NodeRestriction

AnswersA, B, D

AlwaysPullImages is a valid admission controller that forces all newly created pods to pull images with Always pull policy, overriding the pod spec's imagePullPolicy. It is commonly used in multi-tenant or production clusters where ensuring the latest image and avoiding node-local cache tampering is critical. Passing it as a comma-separated list to --enable-admission-plugins on the API server enables it.

Why this answer

`--enable-admission-plugins=AlwaysPullImages` is the valid flag to enable the AlwaysPullImages admission plugin on the kube-apiserver. This flag accepts a comma-separated list of plugin names, and AlwaysPullImages is a built-in admission controller that forces every new Pod to pull images again, even if they already exist on the node, enhancing security by ensuring only authorized images are used.

Exam trap

CNCF often tests the distinction between the deprecated `--admission-control` flag and the current `--enable-admission-plugins` flag, as well as the difference between built-in plugin flags and plugin directory flags, to catch candidates who rely on outdated knowledge or confuse configuration parameters.

Full explanation →

828

MCQmedium

An administrator runs `kubectl exec -it nginx-pod -- sh` and inside the container runs `curl http://example.com`. This succeeds. However, the administrator wants to detect such outbound connections using Falco. Which syscall should Falco monitor to detect this network connection?

A.open

B.connect

C.execve

D.bind

AnswerB

The connect syscall establishes a connection between a socket and a remote address; for curl, this is the exact moment the TCP handshake begins with the destination web server. When tracing system calls, connect is the first syscall that carries the remote IP and port, so it directly identifies the outbound HTTP request. Thus, of the listed options, connect is the correct syscall to monitor for this network activity.

Why this answer

The `connect` syscall is invoked when a client initiates an outbound TCP connection, such as when `curl http://example.com` is run inside the container. Falco monitors syscalls at the kernel level, and detecting `connect` allows it to capture the destination IP and port of the outbound request. This is the correct syscall to monitor for outbound network connections.

Exam trap

The trap here is that candidates confuse `execve` (which starts the `curl` process) with the actual network syscall (`connect`), thinking that monitoring process execution is sufficient to detect outbound connections, but Falco needs the syscall that establishes the connection itself.

How to eliminate wrong answers

Option A is wrong because `open` is used to open files or devices, not to establish network connections; it would not detect the `curl` request. Option C is wrong because `execve` is used to execute a new program (like `curl` itself), but it does not capture the network connection details; monitoring `execve` would only show that `curl` was started, not the outbound connection. Option D is wrong because `bind` is used to associate a socket with a local address (typically for listening servers), not for initiating outbound connections; it would not detect the client-side `connect` call.

Full explanation →

829

MCQhard

An etcd cluster is configured with TLS. You need to enforce that only the API server can read and write to etcd. Which method should you use?

A.Configure etcd RBAC with a role that grants readwrite access only to the API server's client certificate CN

B.Set etcd's --peer-client-cert-auth flag to true

C.Set etcd's --client-cert-auth flag to false

D.Use a NetworkPolicy to restrict access to etcd port 2379

AnswerA

etcd RBAC is the correct mechanism because it authorizes actions based on the authenticated client certificate's CN. Creating a role that grants readwrite on the /registry/ prefix and binding it only to the API server's CN (e.g., 'kube-apiserver') ensures that no other valid TLS peer can access cluster state. This effectively locks etcd data while still allowing the API server to function.

Why this answer

Etcd supports Role-Based Access Control (RBAC) that can restrict access based on the Common Name (CN) in the client certificate. By creating a role with readwrite access and binding it only to the API server's client certificate CN, you ensure that only the API server can read and write to etcd, while other clients are denied.

Exam trap

CNCF often tests the distinction between client-to-etcd authentication (--client-cert-auth) and peer-to-peer authentication (--peer-client-cert-auth), and candidates may confuse the two or think disabling client-cert-auth improves security, when it actually opens access.

How to eliminate wrong answers

Option B is wrong because --peer-client-cert-auth enables client certificate authentication for peer-to-peer communication between etcd members, not for client-to-etcd access, so it does not restrict API server access. Option C is wrong because setting --client-cert-auth to false disables client certificate authentication entirely, allowing any client to connect, which is the opposite of enforcing access control. Option D is wrong because a NetworkPolicy can restrict network-level access to port 2379, but it cannot enforce certificate-based identity; it would block all traffic including legitimate API server traffic if misconfigured, and does not provide the granularity of CN-based authorization.

Full explanation →

830

MCQmedium

A security team wants to ensure that only container images from a trusted registry (mytrustedregistry.io) are deployed in the cluster. They plan to use OPA/Gatekeeper. Which kind of Gatekeeper constraint template and constraint should they create?

A.A constraint that uses a pattern to match the image field against allowed registries

B.A constraint that validates the cluster's registry mirror configuration

C.A constraint that inspects the image field in the Pod's metadata annotations

D.A constraint that checks the imagePullSecrets field in the Pod spec

AnswerA

An admission control policy, such as an OPA/Gatekeeper ConstraintTemplate or a Kyverno ClusterPolicy, can inspect the containers[].image field in the Pod spec and apply a regex or a list of allowed registry prefixes. This directly enforces that every container, including init containers, only references images from trusted registries at admission time. It is the standard, spec-accurate way to restrict image provenance because the image is a first-class field in the container definition.

Why this answer

OPA/Gatekeeper enforces policies via constraint templates that define Rego rules. To restrict container images to a trusted registry, you create a constraint template that inspects the `spec.containers[*].image` field in the Pod spec and uses a pattern (e.g., regex or prefix match) to ensure the image string starts with `mytrustedregistry.io/`. The constraint then applies this template to the cluster, rejecting any Pod that references an image from an untrusted registry.

Exam trap

The CKS exam often tests the misconception that image validation is done via annotations or `imagePullSecrets`, but the actual image source is always in the `spec.containers[*].image` field, and Gatekeeper policies must target that field directly.

How to eliminate wrong answers

Option B is wrong because validating the cluster's registry mirror configuration does not enforce which images are actually used in Pods; it only checks the mirror setup, not the image source. Option C is wrong because the image field is in the Pod spec (`spec.containers[*].image`), not in the Pod's metadata annotations; inspecting annotations would miss the actual image reference. Option D is wrong because `imagePullSecrets` only specifies credentials for pulling images, not the registry source; an attacker could use a secret to pull from an untrusted registry, so checking this field does not prevent deployment of images from unauthorized registries.

Full explanation →

831

MCQhard

A pod is scheduled on a node that has the AppArmor profile 'my-profile' loaded in complain mode. The pod annotation specifies 'localhost/my-profile' but the container is running without the profile being enforced. What is the most likely cause?

A.The pod must run as privileged to use AppArmor

B.The annotation is missing the 'localhost/' prefix

C.The profile is in complain mode, not enforce mode

D.The profile is not loaded on the node

AnswerC

AppArmor profiles can be run in complain (audit) mode, where every access is allowed but violations are logged, or in enforce mode, where disallowed accesses are blocked. In complain mode the profile is technically loaded and appears to be in effect, yet it imposes no real restrictions on the container's system calls. To secure the workload, the profile must be set to enforce mode (e.g., using 'aa-enforce' or writing to /sys/kernel/security/apparmor). The question describes a profile that exists but fails to restrict, which exactly matches complain mode behavior.

Why this answer

AppArmor profiles can operate in either 'enforce' or 'complain' mode. When a profile is loaded in complain mode, violations are logged but not blocked, so the container runs without enforcement. The pod annotation 'localhost/my-profile' correctly references the profile, but the profile itself is not set to enforce mode, which is why the container is running without the profile being enforced.

Exam trap

CNCF often tests the distinction between 'complain' and 'enforce' modes, where candidates mistakenly assume that a loaded profile always enforces restrictions, ignoring that complain mode only logs violations without blocking them.

How to eliminate wrong answers

Option A is wrong because AppArmor does not require the pod to run as privileged; it works with standard containers and enforces profiles at the kernel level via LSM hooks. Option B is wrong because the annotation 'localhost/my-profile' already includes the 'localhost/' prefix, which is the correct format for referencing a locally loaded profile. Option D is wrong because the question explicitly states the profile 'my-profile' is loaded on the node in complain mode, so it is present and not missing.

Full explanation →

832

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.

Full explanation →

833

MCQhard

A Kubernetes cluster enforces image signature verification using the Cosign admission controller. A developer attempts to deploy a pod using an image that was signed with a key that is not in the trusted public key list. The pod is rejected. Which component is responsible for this rejection?

A.The Kubernetes API server's admission chain, specifically the Cosign admission webhook.

B.The Kubernetes scheduler, which filters nodes based on image signature policies.

C.The container runtime interface (CRI) on the node, such as containerd or CRI-O.

D.The kubelet on the node where the pod is scheduled.

AnswerA

Admission webhooks intercept API requests before persistence. The Cosign admission controller is a validating webhook that checks image signatures against trusted keys. If the signature is not valid or the key is untrusted, it rejects the pod creation request. This is the component that enforces the policy at admission time.

Why this answer

Admission controllers in the Kubernetes API server enforce policies before objects are persisted. The Cosign admission webhook validates image signatures against a configured list of trusted public keys. If the signature does not match a trusted key, the webhook denies the pod creation, preventing unsigned or untrusted images from running.

Exam trap

The trap here is assuming that image signature verification happens at the node level via the container runtime, when in fact it is typically enforced at admission time.

Full explanation →

834

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.

Full explanation →

835

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.

Full explanation →

836

MCQhard

You have configured Kyverno to enforce that all Pods must have an image from a trusted registry. However, a newly created Pod is not being rejected even though it uses an untrusted image. What is the most likely reason?

A.Kyverno is not an admission controller; it only mutates resources

B.The Kyverno policy requires an external registry to compare images, which is unavailable

C.The Kyverno webhook is not invoked because the failure policy is set to Ignore or the resource is not matched by the policy's rules

D.The Pod was created by a Deployment controller, which bypasses admission control

AnswerC

The failurePolicy field in Kyverno's ValidatingWebhookConfiguration controls what happens when the webhook cannot be invoked or errors. If set to 'Ignore', any webhook failure is silently ignored and the request proceeds, so the policy would not block the Pod if, for example, the webhook endpoint is unavailable. Additionally, Kyverno policies can have match statements (e.g., specific kinds, namespaces, label selectors) — if this Pod does not match those criteria, the webhook receives the request but the policy simply does not apply to it.

Why this answer

Kyverno operates as a dynamic admission controller via a MutatingAdmissionWebhook or ValidatingAdmissionWebhook. If the webhook's failure policy is set to `Ignore`, the webhook will not block the Pod creation when it fails to invoke, and the Pod will be admitted. Additionally, if the policy's rules do not match the Pod (e.g., due to incorrect resource selection or namespace exclusion), the webhook will not be triggered, allowing untrusted images through.

Exam trap

The trap here is that candidates assume admission control is bypassed by controllers like Deployments, but in Kubernetes, all API requests—including those from controllers—go through admission webhooks; the real issue is usually a misconfigured failure policy or rule mismatch.

How to eliminate wrong answers

Option A is wrong because Kyverno is indeed an admission controller that can both mutate and validate resources; it does not only mutate. Option B is wrong because Kyverno policies can enforce image registry checks locally using pattern matching or regular expressions without requiring an external registry to be available. Option D is wrong because admission control applies to all API requests, including those from controllers like Deployments; the Deployment creates Pods via the API server, which invokes admission webhooks before persisting the resource.

Full explanation →

837

Matchingmedium

Match each container security context setting to its effect.

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

Concepts

Matches

Prevents processes from gaining more privileges than their parent

Ensures the container runs with a user ID that is not 0 (root)

Mounts the container's root filesystem as read-only

Drops all Linux capabilities, minimizing kernel privileges

Disables privileged mode, preventing access to host devices

Why these pairings

Correct matches: runAsNonRoot forces non-root execution; runAsUser sets a specific UID. Common confusion is swapping these effects. Other settings like privileged and readOnlyRootFilesystem also enforce least privilege.

Full explanation →

838

MCQhard

A pod running in the cluster is in a CrashLoopBackOff state. You run 'kubectl describe pod <pod>' and see the following event: 'Warning BackOff Back-off restarting failed container'. Which command would you run to see the standard error output of the container?

A.kubectl logs <pod> --previous

B.kubectl exec <pod> -- cat /var/log/syslog

C.kubectl describe pod <pod>

D.kubectl logs <pod>

AnswerA

In a CrashLoopBackOff state, the current container instance has often just started and immediately exited, meaning its fresh logs are empty or contain only startup noise. The `--previous` flag makes `kubectl logs` fetch the log output from the last terminated container instance, which is exactly where the application's crash error (e.g., panic, fatal exception, or misconfiguration) is recorded. Without this flag, you lose the most relevant diagnostic data for the loop.

Why this answer

`kubectl logs <pod> --previous` retrieves the logs from the previous instance of a crashed or restarting container. When a pod is in CrashLoopBackOff, the current container may have already restarted, so the standard error output from the failed run is only available in the previous container's logs. This command specifically fetches those logs, which typically contain the stderr output that caused the crash.

Exam trap

CNCF often tests the distinction between `kubectl logs <pod>` and `kubectl logs <pod> --previous`; the trap here is that candidates assume the current container's logs contain the crash information, but in a CrashLoopBackOff, the current container may have already restarted and its logs are empty or show only the restart loop, so the `--previous` flag is required to see the actual error output from the failed run.

How to eliminate wrong answers

Option B is wrong because `kubectl exec <pod> -- cat /var/log/syslog` attempts to run a command inside the currently running container, but in a CrashLoopBackOff state the container may not be running or may restart immediately, making exec unreliable; also, containerized applications often do not log to /var/log/syslog. Option C is wrong because `kubectl describe pod <pod>` shows events and metadata but does not display the container's standard error output; it only shows the back-off event already seen. Option D is wrong because `kubectl logs <pod>` fetches logs from the current (possibly restarted) container, which may be empty or show only the restart loop, not the stderr from the failed previous instance.

Full explanation →

839

Multi-Selecthard

Which TWO of the following are true about Kubernetes audit logging?

Select 2 answers

A.Audit logging can be enabled without restarting the API server

B.Audit stages include 'RequestReceived', 'ResponseStarted', 'ResponseComplete', and 'Panic'

C.The audit policy file is passed to the API server via the --audit-policy-file flag

D.The 'Request' level logs both request and response bodies

E.The 'Metadata' level logs the request body

AnswersB, C

The Kubernetes audit system defines exactly four stages at which an event can be recorded: RequestReceived, ResponseStarted, ResponseComplete, and Panic. RequestReceived occurs immediately when the API server receives a request, ResponseStarted happens after response headers are sent but before the response body, ResponseComplete after the full response is sent, and Panic if a panic occurs while handling the request. Because these stages are captured in the audit policy rules, operators can choose to log only certain stages, such as logging RequestReceived for all requests and ResponseComplete for mutating requests.

Why this answer

Option B is correct because Kubernetes defines exactly four audit stages — RequestReceived, ResponseStarted, ResponseComplete, and Panic — which determine when an event is recorded during the request lifecycle. Option C is correct because the API server is configured with the --audit-policy-file flag to specify the audit policy file that defines what to log and at which level. Option A is not correct because enabling audit logging requires API server flags (such as --audit-policy-file and --audit-log-path), which means the kube-apiserver must be restarted.

Option D is not correct because the Request level logs only the request body, not the response body. Option E is not correct because the Metadata level logs request metadata (user, timestamp, resource, verb) but not the request body.

Exam trap

CKS often tests the exact audit stages and levels — candidates confuse 'Request' with 'RequestResponse' and mistakenly believe audit logging can be enabled without restarting the API server.

Full explanation →

840

MCQhard

A cluster administrator has applied a PodSecurityPolicy (PSP) to restrict privileged containers. After upgrading to Kubernetes 1.25, they notice that PSPs are no longer working. What is the MOST likely reason?

A.The PSP API version needs to be updated to v1

B.PSPs were replaced by NetworkPolicies in 1.25

C.PSP support was removed from Kubernetes in 1.25

D.The PSP was not applied to the correct namespace

AnswerC

Correct: PodSecurityPolicy support was removed in Kubernetes 1.25. The PSP API (policy/v1beta1) was deprecated in v1.21 and removed entirely in v1.25, meaning any PSP manifest, even if syntactically valid, will be rejected by the API server and the admission plugin will no longer enforce anything. This is exactly why the administrator's PSP fails to take effect in a 1.25 cluster; the entire subsystem has been excised.

Why this answer

PodSecurityPolicy (PSP) was deprecated in Kubernetes 1.21 and completely removed in Kubernetes 1.25, meaning the PSP admission controller and API resource no longer exist in that version. The cluster administrator's PSPs stopped working because the feature was removed entirely, not due to a configuration or versioning issue. The replacement is Pod Security Admission (PSA), which uses built-in admission controllers and Pod Security Standards.

Exam trap

The trap here is that candidates may think PSPs are merely deprecated or need a version update, but the CKS exam tests the specific knowledge that PSP was removed entirely in 1.25, and that NetworkPolicies serve a completely different purpose.

How to eliminate wrong answers

Option A is wrong because PSP API version updates are irrelevant; the entire PSP API was removed in 1.25, not just deprecated or requiring a version bump. Option B is wrong because NetworkPolicies control network traffic between pods, not pod security constraints like privileged containers; they are not a replacement for PSPs. Option D is wrong because namespace scoping is not the issue; PSPs were cluster-level resources that applied globally via admission controllers, and their removal affects all namespaces equally.

Full explanation →

841

MCQmedium

You are auditing RBAC and find a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to the service account 'default' in namespace 'kube-system'. What is the risk?

A.The risk is only if the service account is used by external users

B.The ClusterRoleBinding is invalid because it uses a namespace-scoped service account

C.Any pod using the default service account in kube-system has cluster-admin privileges

D.No risk, as it is limited to kube-system namespace

AnswerC

The ClusterRoleBinding 'a' assigns the cluster-admin ClusterRole to the 'default' service account in the kube-system namespace. Every pod scheduled into kube-system automatically mounts that service account's token unless automountServiceAccountToken is explicitly set to false. Using this token, a pod can authenticate to the Kubernetes API and has full administrative power: reading secrets, creating privileged pods, deleting nodes, and modifying RBAC policies. This effectively gives cluster-admin behavior to any workload running in that namespace without any additional authentication.

Why this answer

The ClusterRoleBinding 'admin-binding' binds the 'cluster-admin' ClusterRole to the 'default' service account in the 'kube-system' namespace. Since ClusterRoleBindings are cluster-scoped, they grant permissions across all namespaces. Any pod in the 'kube-system' namespace that uses the 'default' service account (which is the default if no other service account is specified) will inherit cluster-admin privileges, allowing full control over the entire cluster.

Exam trap

CNCF often tests the distinction between RoleBindings (namespace-scoped) and ClusterRoleBindings (cluster-scoped), and the trap here is that candidates mistakenly think a ClusterRoleBinding to a namespace-scoped service account is invalid or limited to that namespace.

How to eliminate wrong answers

Option A is wrong because the risk is not limited to external users; any pod (including internal workloads) using the default service account in kube-system gains cluster-admin privileges, regardless of user identity. Option B is wrong because ClusterRoleBindings can bind to namespace-scoped subjects (like service accounts) — the binding is valid and does not require the subject to be cluster-scoped. Option D is wrong because ClusterRoleBindings grant permissions cluster-wide, not limited to the kube-system namespace; the binding gives admin access to all namespaces.

Full explanation →

842

MCQeasy

Which kubectl command can be used to determine if anonymous authentication is enabled on the API server?

A.kubectl get --raw /api/v1

B.kubectl describe node | grep anonymous

C.kubectl cluster-info dump | grep -i anonymous

D.kubectl get pods -n kube-system kube-apiserver-<node> -o yaml | grep anonymous-auth

AnswerD

The correct approach is to retrieve the kube-apiserver static Pod manifest, since the API server runs as a static Pod on the control-plane node and its YAML includes the complete container command and args. Running kubectl get pods -n kube-system kube-apiserver-<node> -o yaml and grepping for 'anonymous-auth' will show whether the flag is explicitly set (true or false) or absent, in which case the default of true applies. This gives a definitive, authoritative answer about the API server's configuration. This command is straightforward, targeted, and leverages kubectl's native access to pod definitions.

Why this answer

The kube-apiserver manifest file (typically located in /etc/kubernetes/manifests/kube-apiserver.yaml) contains the `--anonymous-auth` flag. By inspecting the pod definition via `kubectl get pods -n kube-system kube-apiserver-<node> -o yaml`, you can see the exact command-line arguments passed to the API server, including whether `--anonymous-auth=false` is set (disabled) or absent (enabled by default). This is the most direct and reliable method to check anonymous authentication status.

Exam trap

The trap here is that candidates might think `kubectl cluster-info dump` or `kubectl get --raw` can reveal server flags, but these commands do not expose the API server's startup arguments; only inspecting the pod manifest or directly reading the static pod YAML file shows the actual `--anonymous-auth` setting.

How to eliminate wrong answers

Option A is wrong because `kubectl get --raw /api/v1` returns API resource listing and does not expose server configuration flags like anonymous authentication. Option B is wrong because `kubectl describe node` shows node metadata and conditions, not API server flags; the grep for 'anonymous' would not match anything relevant. Option C is wrong because `kubectl cluster-info dump` outputs cluster-wide logs and resource dumps, but it does not parse the API server's command-line arguments; grepping for 'anonymous' might yield false positives from logs or other components, not a definitive check of the `--anonymous-auth` flag.

Full explanation →

843

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.

Full explanation →

844

MCQmedium

An admin runs 'kubectl run nginx --image=nginx' and the pod fails with 'ImagePullBackOff'. The cluster has an OPA/Gatekeeper constraint that only allows images from 'myregistry.io'. How can the admin quickly test the restriction?

A.Delete the OPA constraint

B.Add a label 'allowlist=true' to the pod

C.Use an image from 'myregistry.io/nginx:latest'

D.Use 'kubectl run nginx --image=nginx --validate=false'

AnswerC

If the OPA constraint's allowlist pattern permits images from 'myregistry.io', then specifying 'myregistry.io/nginx:latest' properly satisfies the image provenance check. The policy inspects the image field in the Pod spec and, if the registry matches the allowed pattern, the admission review passes; this is the correct way to test a compliance requirement without circumventing the control.

Why this answer

The OPA/Gatekeeper constraint explicitly restricts allowed images to those from 'myregistry.io'. By specifying an image from that registry (e.g., 'myregistry.io/nginx:latest'), the admin can quickly verify that the constraint permits compliant images. This tests the policy's intended behavior without altering or bypassing the constraint.

Exam trap

A common misconception is that '--validate=false' bypasses admission controllers, but it only affects client-side validation and has no effect on server-side webhooks like OPA/Gatekeeper.

How to eliminate wrong answers

Option A is wrong because deleting the OPA constraint removes the restriction entirely, which does not test the policy — it circumvents it. Option B is wrong because adding a label 'allowlist=true' to the pod does not affect image validation; OPA/Gatekeeper constraints typically evaluate image registry patterns, not arbitrary pod labels. Option D is wrong because '--validate=false' only skips client-side validation (e.g., schema checks) and does not bypass server-side admission webhooks like OPA/Gatekeeper, so the pod will still be rejected.

Full explanation →

845

MCQeasy

Which command loads an AppArmor profile into the kernel?

A.apparmor_load /path/to/profile

B.aa-load /path/to/profile

C.aa-status /path/to/profile

D.apparmor_parser -r /path/to/profile

AnswerD

`apparmor_parser -r /path/to/profile` is the legitimate way to load (or replace) an AppArmor profile: it reads the textual profile file, parses it into the binary policy format, and writes that policy to the kernel through the AppArmor securityfs interface. The `-r` flag means 'replace' an existing profile with the same name; to add a new profile, you would use `-a` or omit the flag (the default is add). Because the kernel only understands the compiled policy, apparmor_parser is the required userspace bridge and thus correctly loads the profile.

Why this answer

The `apparmor_parser` command is the standard tool for loading AppArmor profiles into the Linux kernel. The `-r` flag (replace) loads or reloads the specified profile file, merging it into the kernel's security policy. This is the correct method because AppArmor profiles are text files that must be parsed and loaded by the kernel's LSM (Linux Security Module) subsystem via this utility.

Exam trap

The trap here is that candidates may confuse the command with similar-sounding names like `aa-load` or `apparmor_load`, or mistake `aa-status` (a status-checking tool) for a loading command, because the CKS exam often tests precise command names and their specific functions.

How to eliminate wrong answers

Option A is wrong because `apparmor_load` is not a valid command; AppArmor does not provide a command with that name. Option B is wrong because `aa-load` is not a standard AppArmor command; the correct command is `apparmor_parser`. Option C is wrong because `aa-status` is used to check the status of loaded AppArmor profiles (e.g., which profiles are enforced or complain mode), not to load a profile into the kernel.

Full explanation →

Certified Kubernetes Security Specialist CKS (CKS) — Questions 826–845