I85PREP
⌘ K
CKS study materials
CKS study resources

CKS practice questions

One question at a time. Build your CKS understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Cluster Setup

A cluster administrator wants to isolate all pods in namespace `prod` so that no ingress or egress traffic is allowed until explicit policies are added. Which NetworkPolicy specification accomplishes this?

  1. `podSelector: {}` with an empty `namespaceSelector` in each rule.
  2. `podSelector: {matchLabels: {app: prod}}`, `policyTypes: [Ingress, Egress]`, and no rules.
  3. `podSelector: {}`, `policyTypes: [Ingress]`, and no ingress rules.
  4. `podSelector: {}`, `policyTypes: [Ingress, Egress]`, and no rules. Correct answer.

Explanation

An empty `podSelector` selects every pod in the namespace. Listing both `Ingress` and `Egress` in `policyTypes` while providing no rules isolates all selected pods for both directions. Additional policies can then allow specific flows.

Question 2Cluster Setup

A Deployment should not receive a mounted service account token unless explicitly configured. Which pod-level setting disables the automatic token mount?

  1. Create a ServiceAccount with no Secrets and reference it.
  2. Set `automountServiceAccountToken: false` in the pod template. Correct answer.
  3. Set `tokenProjection: disabled` in the pod template.
  4. Set `serviceAccountName: none` in the pod template.

Explanation

The `automountServiceAccountToken` field on the pod specification controls whether the projected service account token is mounted. Setting it to `false` prevents the automatic mount for that pod. The ServiceAccount object can also set a default, but the pod-level value overrides it.

Question 3Cluster Setup

Which kubelet flag disables anonymous authentication to the kubelet API?

  1. `--anonymous-auth=false` Correct answer.
  2. `--anonymous-auth=true`
  3. `--authorization-mode=AlwaysAllow`
  4. `--client-ca-file=/etc/kubernetes/pki/ca.crt`

Explanation

The kubelet uses `--anonymous-auth` to control unauthenticated requests, and `--anonymous-auth=false` rejects them. Client certificate authentication is configured separately. Authorization mode determines what authenticated requests are allowed to do.

Question 4Cluster Setup

An Ingress must terminate TLS for `app.example.com`. Which Secret type and keys are required?

  1. type `kubernetes.io/tls` with keys `tls.crt` and `tls.key` Correct answer.
  2. type `kubernetes.io/dockerconfigjson` with key `.dockerconfigjson`
  3. type `kubernetes.io/ssh-auth` with key `ssh-privatekey`
  4. type `Opaque` with keys `username` and `password`

Explanation

Ingress TLS termination expects a Secret of type `kubernetes.io/tls`. The certificate chain is stored in `tls.crt` and the private key in `tls.key`. The Ingress `spec.tls` block references that Secret by name.

Question 5Cluster Setup

Which tool evaluates cluster nodes and control plane components against the CIS Kubernetes Benchmark?

  1. kube-bench Correct answer.
  2. Trivy
  3. kubesec
  4. kube-hunter

Explanation

kube-bench runs checks derived from the CIS Kubernetes Benchmark and reports remediation guidance. It is commonly run as a Job or directly on nodes. The other tools focus on penetration testing, manifest scoring, or vulnerability scanning.

Question 6Cluster Setup

Which kube-apiserver flag disables anonymous authentication?

  1. `--anonymous-auth=true`
  2. `--anonymous-auth=false` Correct answer.
  3. `--authorization-mode=RBAC`
  4. `--insecure-port=0`

Explanation

The `--anonymous-auth` flag on kube-apiserver controls whether unauthenticated requests are treated as anonymous users. Setting it to `false` rejects anonymous authentication. Authorization mode and port settings do not disable anonymous authentication.

Question 7Cluster Setup

To enforce the `restricted` Pod Security Standard on a namespace, which namespace label should be set?

  1. `pod-security.kubernetes.io/audit=restricted`
  2. `pod-security.kubernetes.io/enforce-version=restricted`
  3. `pod-security.kubernetes.io/enforce=restricted` Correct answer.
  4. `pod-security.kubernetes.io/warn=restricted`

Explanation

The `enforce` label makes Pod Security Admission reject pods that violate the selected standard. The `audit` and `warn` labels only record or report violations. `enforce-version` selects the policy version, such as `latest`, not the standard.

Question 8Cluster Setup

Pods on cloud nodes must be prevented from reaching the instance metadata endpoint at 169.254.169.254. Which cluster-side control directly blocks that egress?

  1. Add iptables rules inside each application pod.
  2. An egress NetworkPolicy denying 169.254.169.254/32. Correct answer.
  3. Set `dnsPolicy: ClusterFirst` on all pods.
  4. Set `hostNetwork: true` on sensitive pods.

Explanation

An egress NetworkPolicy can deny traffic from selected pods to the metadata IP address when the CNI enforces policy. This blocks pod access to the instance metadata service without changing node networking. Cloud-provider metadata hardening should also be used where available.

Question 9Cluster Setup

Pods labeled `app=api` in namespace `web` must accept traffic only from pods labeled `role=client` in namespace `team-a`. Which ingress `from` clause is correct?

  1. One `from` entry with only `namespaceSelector` team=a.
  2. One `from` entry with only `podSelector` role=client.
  3. One `from` entry with both `namespaceSelector` team=a and `podSelector` role=client. Correct answer.
  4. Two `from` entries, one for namespace team=a and one for pod role=client.

Explanation

Selectors inside a single `from` element are combined with AND, so the peer must be in the matching namespace and have the matching pod label. Separate `from` elements are combined with OR. Using only one selector broadens the allowed source.

Question 10Cluster Setup

In an EncryptionConfiguration, new Secrets must be written with a KMS provider while existing data encrypted with `aescbc` remains readable. How should the `providers` list be ordered?

  1. `identity` first, then `kms`, then `aescbc`
  2. `aescbc` first, then `kms`, then `identity`
  3. `identity` only
  4. `kms` first, then `aescbc`, then `identity` Correct answer.

Explanation

The first provider in the list is used for writing new data, and the remaining providers are used for reading existing data. Placing KMS first writes new Secrets with KMS, while `aescbc` later in the list allows existing data to be decrypted. `identity` is kept last as a fallback for unencrypted data.

Question 11Cluster Setup

Which `--authorization-mode` setting is recommended so kubelets are authorized by Node and other clients by RBAC?

  1. `ABAC`
  2. `Node,RBAC` Correct answer.
  3. `Webhook`
  4. `AlwaysAllow`

Explanation

`Node,RBAC` enables the Node authorizer for kubelet requests and RBAC for other authenticated clients. The order matters because authorization modes are evaluated in sequence. This combination is the standard hardened API server setting.

Question 12Cluster Setup

Which audit policy level records request metadata such as user, verb, and resource but not request or response bodies?

  1. `Request`
  2. `RequestResponse`
  3. `Metadata` Correct answer.
  4. `None`

Explanation

The `Metadata` level logs request metadata without the request or response body. The `Request` level includes the request body, and `RequestResponse` includes both bodies. `None` suppresses audit events for matching rules.

Question 13Cluster Setup

Which kubelet configuration disables the unauthenticated read-only port 10255?

  1. `--port=0`
  2. `--read-only-port=0` Correct answer.
  3. `--anonymous-auth=false`
  4. `--authorization-mode=Webhook`

Explanation

The kubelet read-only port is controlled by `--read-only-port`, and setting it to `0` disables that listener. Anonymous authentication and authorization settings affect requests on the secure port. The `--port` flag does not specifically disable port 10255.

Question 14Cluster Setup

After a default-deny egress policy, pods must resolve DNS through kube-dns in `kube-system`. Which egress rule permits DNS?

  1. to `k8s-app=kube-dns` pods in `kube-system` on UDP/TCP 53 Correct answer.
  2. to all namespaces on UDP 53
  3. to namespace `kube-system` on TCP 443 only
  4. to `k8s-app=kube-dns` pods in `kube-system` on UDP 53 only

Explanation

DNS normally uses UDP port 53, with TCP port 53 used for large responses and fallback. The rule should select the kube-dns pods in `kube-system` rather than all pods in the namespace. Allowing only UDP can break resolution when the client retries over TCP.

Question 15Cluster Setup

Which admission controller restricts a kubelet so it can modify only its own Node object and Pods bound to that node?

  1. `AlwaysPullImages`
  2. `NodeRestriction` Correct answer.
  3. `ImagePolicyWebhook`
  4. `PodSecurity`

Explanation

The `NodeRestriction` admission controller limits kubelet credentials to their own Node and Pod objects. It reduces the impact of a compromised node. `PodSecurity` enforces pod security standards, and the other plugins address image behavior.

Question 16Cluster Setup

kube-bench reports that the kube-apiserver has `--profiling=true`. Which remediation addresses this CIS finding?

  1. Set `--profiling=false` on kube-apiserver. Correct answer.
  2. Set `--secure-port=0`.
  3. Disable the audit log.
  4. Set `--anonymous-auth=true`.

Explanation

The CIS finding recommends disabling profiling on the API server to reduce exposed diagnostic endpoints. The remediation is to set `--profiling=false` in the API server manifest or startup flags. Audit and authentication settings do not address this specific finding.

Question 17Cluster Setup

An Ingress named `web` must serve TLS for host `app.example.com` using Secret `app-tls`. Which `spec.tls` block is correct?

  1. `tls: [{secretName: app-tls, host: app.example.com}]`
  2. `tls: [{secretName: app-tls}]` under each rule host
  3. `tls: [{hosts: [app.example.com], secretName: app-tls}]` Correct answer.
  4. `tls: [{hosts: [app.example.com], certName: app-tls}]`

Explanation

The Ingress `spec.tls` field is a list of entries with a `hosts` array and a `secretName`. The Secret must contain the certificate and key for the listed hosts. The other field names and placements are not valid Ingress TLS syntax.

Question 18Cluster Setup

A pod needs a time-bound service account token with a specific audience without relying on the legacy Secret. Which projected volume source should be used?

  1. `downwardAPI`
  2. `secret`
  3. `serviceAccountToken` Correct answer.
  4. `configMap`

Explanation

The `serviceAccountToken` projected volume source requests a bound token with configurable `audience`, `expirationSeconds`, and `path`. It is the modern replacement for relying on a long-lived ServiceAccount Secret. The other sources project existing data, not newly issued tokens.

Question 19Cluster Setup

Which kube-apiserver flags are required to write audit events to a log file using an audit policy?

  1. `--enable-admission-plugins=Audit`
  2. `--audit-log-path` alone
  3. `--audit-policy-file` alone
  4. `--audit-policy-file` and `--audit-log-path` Correct answer.

Explanation

Audit logging needs a policy to define what to record and a destination to receive the events. `--audit-policy-file` supplies the policy, and `--audit-log-path` enables the log backend. There is no `Audit` admission plugin used for this purpose.

Question 20Cluster Setup

An egress policy must allow traffic to `10.0.0.0/8` but exclude `10.1.0.0/16`. Which `ipBlock` is correct?

  1. `ipBlock` for `10.0.0.0/8` plus a `namespaceSelector` for `10.1.0.0/16`
  2. `ipBlock` with `cidr: 10.0.0.0/8` and `except: [10.1.0.0/16]` Correct answer.
  3. two separate `ipBlock` entries for `10.0.0.0/8` and `10.1.0.0/16`
  4. separate rules for `10.0.0.0/8` and `10.1.0.0/16` with `except`

Explanation

The `except` field inside a single `ipBlock` excludes a subrange from the allowed CIDR. This permits `10.0.0.0/8` while denying `10.1.0.0/16`. Separate blocks or rules would allow the excluded range rather than subtract it.

Question 21Cluster Setup

Which flag set secures etcd peer communication with mutual TLS?

  1. `--etcd-certfile`, `--etcd-keyfile`, `--etcd-cafile`
  2. `--peer-cert-file` and `--peer-key-file` only
  3. `--cert-file`, `--key-file`, `--trusted-ca-file`, `--client-cert-auth`
  4. `--peer-cert-file`, `--peer-key-file`, `--peer-trusted-ca-file`, `--peer-client-cert-auth` Correct answer.

Explanation

Etcd peer traffic is secured with the `peer` certificate, key, trusted CA, and client certificate authentication flags. These protect communication between etcd members. The non-peer flags secure client connections to etcd, and the `etcd-*` flags are used by kube-apiserver as an etcd client.

Question 22Cluster Setup

To enable the ImagePolicyWebhook admission controller, which kube-apiserver configuration is required in addition to enabling the plugin?

  1. An Ingress with TLS for the webhook endpoint in kube-system.
  2. A PodSecurityPolicy bound to the webhook service account in kube-system.
  3. A NetworkPolicy that allows image pulls from the registry to every namespace.
  4. `--admission-control-config-file` with the webhook kubeconfig and default behavior. Correct answer.

Explanation

ImagePolicyWebhook requires an admission control configuration file that defines the webhook connection and the default allow or deny behavior. The API server flag `--admission-control-config-file` points to that configuration. Network, PodSecurityPolicy, and Ingress resources do not configure the admission webhook itself.

Question 23Cluster Setup

A NetworkPolicy must allow egress from `app=api` pods to `app=db` pods on the port named `postgres` in the db containers. Which `ports` entry is valid?

  1. `ports: [{protocol: TCP, name: postgres}]`
  2. `ports: [{protocol: TCP, targetPort: postgres}]`
  3. `ports: [{protocol: TCP, port: 5432}]` only; named ports cannot be used.
  4. `ports: [{protocol: TCP, port: postgres}]` Correct answer.

Explanation

NetworkPolicy `ports` entries use the `port` field, which may contain a numeric port or a named port that matches the destination pod container port name. The field is not `name` or `targetPort`. Using the named port avoids hard-coding a numeric value.

Question 24Cluster Setup

An audit policy produces duplicate events because both `RequestReceived` and `ResponseComplete` stages are recorded. Which policy field suppresses the `RequestReceived` stage?

  1. `audit-log-maxbackup`
  2. `--audit-webhook-batch-buffer-size`
  3. `level: None` on every rule
  4. `omitStages: [RequestReceived]` Correct answer.

Explanation

The audit policy `omitStages` field lists stages that should not produce events. Setting it to `RequestReceived` suppresses events at that stage while preserving later stages such as `ResponseComplete`. The other fields affect rule level or backend tuning, not stage filtering.

Question 25Cluster Setup

Which kubelet flag makes the kubelet fail if kernel sysctls differ from kubelet defaults in a way that could weaken isolation?

  1. `--fail-swap-on=false`
  2. `--protect-kernel-defaults=true` Correct answer.
  3. `--read-only-port=0`
  4. `--streaming-connection-idle-timeout=0`

Explanation

`--protect-kernel-defaults=true` makes the kubelet enforce and check kernel parameters against its defaults. This helps prevent unsafe sysctl changes on nodes. The other flags control ports, streaming timeouts, or swap handling.

Question 26Cluster Setup

Which Kubernetes object associates a Role or ClusterRole with a subject such as a user, group, or ServiceAccount so that the permissions apply only within one namespace?

  1. A Role whose rules include a subjects list
  2. A ClusterRoleBinding that names the namespace in metadata
  3. A RoleBinding created in that namespace Correct answer.
  4. A ServiceAccount annotated with the subject name

Explanation

A RoleBinding grants the permissions of a referenced Role or ClusterRole to its subjects, and that grant is scoped to the namespace where the RoleBinding itself lives. A ClusterRoleBinding is the cluster-wide equivalent and cannot be namespace-scoped. Role rules describe verbs and resources only; subjects belong to the binding object.

Question 27Cluster Setup

A namespace must deny all inbound traffic to every Pod in it unless a more specific policy later allows it. Which NetworkPolicy specification achieves this?

  1. A podSelector matching app=web combined with policyTypes set to [Ingress]
  2. A podSelector matching tier=none, a label no Pod carries, combined with policyTypes set to [Ingress]
  3. An empty podSelector ({}) combined with policyTypes set to [Ingress] Correct answer.
  4. An empty podSelector ({}) combined with policyTypes set to [Egress]

Explanation

An empty podSelector selects every Pod in the namespace, and listing Ingress in policyTypes with no ingress rules makes the policy deny all inbound connections to those Pods. Only rules in policies that select a Pod can allow traffic to it, so a single such policy establishes default-deny ingress. Combined with other allow policies, the union of allowed traffic still applies.

Question 28Cluster Setup

Administrators want the API server to validate the serving certificate presented by each kubelet when handling requests such as kubectl logs or kubectl exec. Which kube-apiserver flag supplies the CA bundle used for that validation?

  1. --client-ca-file
  2. --kubelet-certificate-authority Correct answer.
  3. --tls-cert-file
  4. --kubelet-client-certificate

Explanation

The --kubelet-certificate-authority flag gives the API server a CA bundle it uses to verify the certificate the kubelet presents on its HTTPS serving port. Without it, the API server does not validate kubelet serving certificates and is exposed to man-in-the-middle attacks on the node network. Certificates the API server presents to the kubelet, and the CA it uses to authenticate clients of its own API, are configured by different flags.

Question 29Cluster Setup

A namespace must never hold more than 20 Pods, and creation of the 21st Pod must be rejected. Which object enforces this?

  1. A PodDisruptionBudget with minAvailable set to a value of 20
  2. A PriorityClass whose value caps total Pods in the namespace
  3. A ResourceQuota with count/pods set to 20 Correct answer.
  4. A LimitRange that caps the number of Pods each namespace may contain

Explanation

ResourceQuota supports object-count keys such as count/pods, and admission rejects a new Pod once the quota is exhausted. LimitRange governs per-container or per-Pod default and bounding values for compute resources and storage, not object counts. PodDisruptionBudget and PriorityClass influence eviction and scheduling priority rather than capping the number of objects.

Question 30Cluster Setup

A Role must let a ServiceAccount fetch exactly one Secret, named db-creds, in namespace prod. Which rule grants only that access?

  1. apiGroups: [""], resources: ["secrets"], verbs: ["get"] with a labelSelector of name=db-creds
  2. apiGroups: [""], resources: ["secrets"], verbs: ["get", "list"] with a fieldSelector of metadata.name=db-creds
  3. apiGroups: [""], resources: ["secrets/db-creds"], verbs: ["get"]
  4. apiGroups: [""], resources: ["secrets"], resourceNames: ["db-creds"], verbs: ["get"] Correct answer.

Explanation

RBAC rules support resourceNames to narrow a rule to individually named objects, and get can be restricted this way. The list and watch verbs cannot be meaningfully constrained by resourceNames because the API server does not filter lists against that field, so such a rule would not deliver the intended narrow access. RBAC rules have no fieldSelector or labelSelector fields, and subresource names are not used to identify individual objects.

Question 31Cluster Hardening

A Pod is created in namespace dev without a serviceAccountName field. Which behavior applies to its ServiceAccount token?

  1. The default ServiceAccount from the kube-system namespace is used instead
  2. The namespace's default ServiceAccount is used and its token is mounted Correct answer.
  3. A dedicated ServiceAccount named after each new Pod is generated automatically
  4. No ServiceAccount is attached until one is named explicitly in the Pod spec

Explanation

Pods that omit serviceAccountName are assigned the namespace's default ServiceAccount, and an API token is projected into each container unless automountServiceAccountToken is set to false on the Pod or the ServiceAccount. Tokens are not generated per Pod name.

Question 32Cluster Hardening

Which statement describes the scope of a Role compared with a ClusterRole?

  1. A Role grants permissions on nodes and persistent volumes only
  2. A Role grants permissions within a single namespace Correct answer.
  3. A Role grants permissions on cluster-scoped resources only
  4. A Role grants permissions across all namespaces in the cluster

Explanation

A Role is namespaced: its rules only apply to resources in the namespace where the Role and its RoleBinding exist. Cluster-wide grants require a ClusterRole combined with a ClusterRoleBinding.

Question 33Cluster Hardening

A RoleBinding in namespace staging references the ClusterRole view. What permissions does a subject of that binding receive?

  1. Read access to the rules of view, limited to the staging namespace Correct answer.
  2. No permissions, because a RoleBinding must reference only a Role
  3. Read access to the ClusterRole object itself through the API
  4. Cluster-wide read access to all resources covered by view

Explanation

A RoleBinding may reference a ClusterRole, but the permissions it grants apply only inside the RoleBinding's namespace. This is the standard way to reuse a common rule set across namespaces.

Question 34Cluster Hardening

By default, which port serves the authenticated, TLS-protected Kubernetes API?

  1. 10250
  2. 6443 Correct answer.
  3. 2379
  4. 8080

Explanation

The kube-apiserver serves authenticated HTTPS traffic on port 6443 by default. Port 8080 was the old unauthenticated localhost port and is no longer available in current releases.

Question 35Cluster Hardening

What does the command kubectl auth can-i list secrets --namespace prod report?

  1. It creates a temporary Role that grants list access to Secrets in that namespace
  2. It prints all RBAC rules in the cluster that mention the secrets resource
  3. It reports whether the current identity may perform that action Correct answer.
  4. It lists every Secret that the current user has created in that namespace

Explanation

kubectl auth can-i submits a SubjectAccessReview to the API server and prints whether the given verb and resource combination is allowed for the current or impersonated identity. It performs no listing and changes no RBAC objects.

Question 36Cluster Hardening

Which upgrading rule applies to a kubeadm-managed cluster?

  1. A cluster may jump several minor versions in a single upgrade run
  2. The control plane must be upgraded before the worker nodes Correct answer.
  3. The kubelet must be upgraded before the kube-apiserver on each node
  4. Worker nodes must be upgraded before the control plane components

Explanation

kubeadm upgrades the control plane components first and then each node's kubelet and kube-proxy. Skipping minor versions is not supported, so upgrades proceed one minor version at a time.

Question 37Cluster Hardening

Workloads must not reach the cloud instance metadata endpoint at 169.254.169.254. Which control limits this from inside the cluster?

  1. A Pod Security Admission label set to the restricted profile
  2. An egress NetworkPolicy that denies traffic to that IP address Correct answer.
  3. A LimitRange that caps the number of network connections per Pod
  4. A ResourceQuota that blocks the metadata service port for the namespace

Explanation

An egress NetworkPolicy that selects the workload and denies traffic to the metadata IP blocks the common SSRF path to cloud credentials. LimitRange, ResourceQuota and Pod Security Admission do not filter network traffic.

Question 38Cluster Hardening

Why is granting verbs: ["*"] on resources: ["*"] considered risky in a Role?

  1. It is rejected by the API server because wildcards are not supported
  2. It grants access to future resource types, including new CRDs Correct answer.
  3. It silently overrides every other Role in the same namespace
  4. It only applies to cluster-scoped resources, so namespaces leak data

Explanation

Wildcards in RBAC rules match every current and future resource and verb, including custom resources added later. Least privilege requires enumerating the specific verbs and resources actually needed.

Question 39Cluster Hardening

A ClusterRole sets an aggregationRule with a label selector. What is the effect?

  1. The ClusterRole is applied to every namespace that carries the label
  2. Rules from ClusterRoles with the matching label are merged in Correct answer.
  3. Only subjects whose labels match the selector are bound to the role
  4. The ClusterRole inherits all rules from the built-in cluster-admin role

Explanation

Aggregated ClusterRoles collect rules from any ClusterRole whose labels match the aggregationRule selector. Built-in aggregated roles such as admin and edit use this mechanism to compose permissions.

Question 40Cluster Hardening

A Role grants create on pods with resourceNames set to ["app"]. What access does it actually give?

  1. Only a Pod named app may be created in that namespace
  2. Only Pods whose names begin with app may be created
  3. Any Pod can be created; resourceNames does not restrict create Correct answer.
  4. No access, because create cannot be combined with resourceNames

Explanation

resourceNames restricts requests that target an existing named object, such as get, update or delete. A create request does not name an existing object, so the restriction is ignored and any name can be created.

Question 41Cluster Hardening

A ServiceAccount has automountServiceAccountToken: false, and a Pod using it sets automountServiceAccountToken: true. What is the result?

  1. No token is mounted, because the ServiceAccount setting wins
  2. The token is mounted, because the Pod-level setting takes precedence Correct answer.
  3. The token is mounted only if the ServiceAccount token Secret exists
  4. The Pod is rejected because the two settings conflict

Explanation

The Pod-level field overrides the ServiceAccount-level field when both are set. Admission uses the effective Pod value to decide whether to project an API token into the container.

Question 42Cluster Hardening

Since Kubernetes 1.24, what is true about running kubectl create serviceaccount build?

  1. It creates the ServiceAccount without a long-lived token Secret Correct answer.
  2. It creates the ServiceAccount and immediately binds it to view
  3. It fails unless a token Secret name is supplied with --token
  4. It creates the ServiceAccount together with a token Secret

Explanation

The legacy token controller no longer provisions a Secret for newly created ServiceAccounts; tokens are obtained on demand through the TokenRequest API or a projected volume. Long-lived Secrets can still be created manually if required.

Question 43Cluster Hardening

Which kube-apiserver flag disables unauthenticated requests to the API?

  1. --authorization-mode=AlwaysDeny
  2. --anonymous-auth=false Correct answer.
  3. --insecure-port=0
  4. --enable-admission-plugins=NodeRestriction

Explanation

Setting --anonymous-auth=false makes the API server reject requests that carry no credentials with 401 instead of mapping them to system:anonymous. Authorization modes and admission plugins do not remove anonymous authentication.

Question 44Cluster Hardening

Which pair of components restricts a kubelet to reading only the objects belonging to its own node?

  1. The RBAC authorizer together with the PodSecurity admission plugin
  2. The Webhook authorizer together with the LimitRanger admission plugin
  3. The Node authorizer and NodeRestriction admission plugin Correct answer.
  4. The ABAC authorizer together with the ResourceQuota admission plugin

Explanation

The Node authorizer scopes a kubelet's API access to its own Node and the Pods and Secrets bound to it, and NodeRestriction admission enforces the same limit on writes. Together they stop a compromised node from reading other nodes' workloads.

Question 45Cluster Hardening

Which value of --authorization-mode enables RBAC, the Node authorizer and webhook authorization together?

  1. Webhook,AlwaysDeny,Node
  2. AlwaysAllow,Node,RBAC
  3. RBAC,ABAC,AlwaysAllow
  4. Node,RBAC,Webhook Correct answer.

Explanation

The flag takes a comma-separated ordered list of authorizers, and a request is allowed if any enabled authorizer allows it. Node, RBAC and Webhook are the three used in a typical hardened cluster.

Question 46Cluster Hardening

A kubeconfig on an administrator's workstation embeds cluster-admin client credentials. Which protection is most direct?

  1. Restricting the file to mode 0600 owned by the user Correct answer.
  2. Encrypting it with a password stored in the same directory
  3. Compressing the file and renaming it to .kubeconfig.bak
  4. Storing it in the home directory with the default umask

Explanation

Client credentials in a kubeconfig carry whatever RBAC the embedded identity has, so file-level protection matters. Mode 0600 with a dedicated owner prevents other local users from reading the file.

Question 47Cluster Hardening

What is the correct order when upgrading a worker node managed by kubeadm?

  1. Drain the node, upgrade the kubelet, then uncordon the node Correct answer.
  2. Uncordon the node first so workloads keep scheduling during upgrade
  3. Upgrade the kubelet first, then drain the node, then uncordon it
  4. Skip draining whenever the node carries no taints

Explanation

Draining evicts workloads before the kubelet is restarted, which reduces disruption and avoids Pods stuck on a node running a mismatched version. The node is uncordoned once the new kubelet is healthy.

Question 48Cluster Hardening

What distinguishes the bound ServiceAccount token volume from the legacy Secret-based token?

  1. It is signed with the kubelet certificate instead of the API server key
  2. It expires and is invalidated when the Pod is deleted Correct answer.
  3. It is stored in a Secret object that only the kubelet can read
  4. It never expires and must be rotated manually by an administrator

Explanation

Bound tokens are time-limited and tied to the Pod's lifetime, and the kubelet obtains and rotates them through the TokenRequest API. Legacy Secret tokens persisted indefinitely and were not bound to any Pod.

Question 49Cluster Hardening

A ClusterRoleBinding grants list on secrets to the group system:authenticated. What is the result?

  1. The binding is rejected because groups cannot be bound to ClusterRoles
  2. Only ServiceAccounts in the default namespace get the access
  3. Only users who authenticated with client certificates get the access
  4. Every authenticated identity in the cluster can list Secrets Correct answer.

Explanation

system:authenticated includes every identity that has authenticated to the API, including all ServiceAccounts. Binding to that group effectively grants the permission cluster-wide.

Question 50Cluster Hardening

Which RBAC verb allows a subject to create or update a Role that grants permissions the subject does not itself hold?

  1. bind
  2. impersonate
  3. escalate Correct answer.
  4. approve

Explanation

The escalate verb on roles or clusterroles exempts the caller from the escalation check that otherwise requires holding every permission being granted. The bind verb is the analogous exemption for creating RoleBindings.