Pular para o conteúdo

Simulado · CNCF

Simulado Certified Kubernetes Administrator (CKA)

50
questões
120
minutos
66%
para passar no simulado
60
questões no banco

Resposta curta

O simulado de Certified Kubernetes Administrator (CKA) tem 50 questões em 120 minutos, com nota de corte de 66%, conforme configurado aqui. O jeito mais rápido de saber se você está pronto é fazer uma prova completa no relógio e ler a nota por domínio, não só o total.

Domínios cobrados

  • Cluster Architecture, Installation and Configuration
  • Services and Networking
  • Storage
  • Troubleshooting
  • Workloads and Scheduling

Questões de exemplo, com explicação

Três questões do banco, abertas para ler.

Questão 1 · Storage

A team deploys a Deployment with a PVC that requests a volume from a StorageClass configured with `volumeBindingMode: WaitForFirstConsumer`. The PVC stays in `Pending` indefinitely, and `kubectl describe pvc` shows no provisioning events at all. Meanwhile the corresponding Pod is also `Pending` because no node can be scheduled to it (a nodeSelector references a label that exists on no node). What is the most accurate explanation for why the PVC remains Pending?

  1. The StorageClass is missing a `provisioner` field, so the PVC can never be dynamically provisioned regardless of the Pod state.
  2. The PVC needs an explicit `volumeName` set to bind under WaitForFirstConsumer mode; without it the provisioner ignores the claim.
  3. A PVC using WaitForFirstConsumer must be created in the same namespace as the StorageClass, and StorageClasses are cluster-scoped, so the binding fails.
  4. With WaitForFirstConsumer, volume provisioning is deferred until the Pod is scheduled to a node; because the Pod is unschedulable, the scheduler never triggers binding/provisioning of the PVC. ✓ (correta)
Por que esta é a correta

WaitForFirstConsumer intentionally delays binding and dynamic provisioning until a consuming Pod is scheduled, so the provisioner can place the volume in a topology compatible with the chosen node. Since the Pod is unschedulable (its nodeSelector matches no node), the scheduler never reaches the point of triggering provisioning, leaving the PVC Pending with no provisioning events — exactly the observed symptom. 'Missing provisioner field' is wrong because that would still produce a Pending PVC but the symptom and binding mode described point to the scheduling dependency, not a malformed class; a missing provisioner also is not implied by the scenario. 'Same namespace as the StorageClass' is a misconception — StorageClasses are cluster-scoped and have no namespace, so namespace matching is irrelevant. 'Explicit volumeName required' confuses dynamic provisioning with static pre-binding; setting volumeName forces static binding to an existing PV and is not how WaitForFirstConsumer dynamic provisioning works.

Questão 2 · Services and Networking

A Service named 'payments' in namespace 'prod' has a correct selector and 3 ready backend pods, yet 'kubectl get endpoints payments -n prod' shows an empty ENDPOINTS column and clients receive connection refused. The pods are Running and their readiness probes pass. The Service spec defines 'port: 80' and 'targetPort: web'. Which root cause best explains the empty endpoints?

  1. EndpointSlices are disabled by default in current Kubernetes, so the legacy Endpoints object will always appear empty and clients must use EndpointSlices directly
  2. The Service selector must include the label 'kubernetes.io/service-name=payments' on the pods, and without it the endpoint controller refuses to register any pod
  3. A Service with a named targetPort requires a headless configuration (clusterIP: None); a normal ClusterIP cannot use named ports and silently drops all endpoints
  4. The pods' containers do not declare a named container port called 'web', so the named targetPort cannot be resolved to a numeric port and no endpoint addresses are populated ✓ (correta)
Por que esta é a correta

When targetPort is a name rather than a number, each backend pod must expose a containerPort with that exact name; if no container declares a port named 'web', the name cannot be resolved and the endpoint controller produces no addresses, which is the correct root cause. The claim that EndpointSlices are disabled and Endpoints is always empty is false: EndpointSlices are enabled and the endpoint controller still mirrors data into the legacy Endpoints object, which would be populated if endpoints existed. Named targetPorts do not require a headless Service: normal ClusterIP Services fully support named ports, so that option states a non-existent restriction. The label kubernetes.io/service-name is an internal label that the controller writes onto EndpointSlices, not a selector label you must place on pods, so requiring it on pods is fabricated.

Questão 3 · Cluster Architecture, Installation and Configuration

A node `worker-2` shows `Ready,SchedulingDisabled`. You ran `kubectl drain worker-2 --ignore-daemonsets` an hour ago to do maintenance, which is now complete. New pods are not being placed there. A colleague suggests `kubectl delete node worker-2 && kubeadm reset` to 'reset its state.' What is the correct, least-disruptive action to return the node to service?

  1. Restart the kubelet on worker-2; the `SchedulingDisabled` taint is set by the kubelet and only clears on kubelet restart
  2. Delete the node object and rejoin it with `kubeadm join`, since `SchedulingDisabled` means the node has been evicted from the cluster
  3. Run `kubectl uncordon worker-2`, which clears the unschedulable mark so the scheduler can place new pods on it again ✓ (correta)
  4. Run `kubectl drain worker-2 --undo` to reverse the drain operation and re-enable scheduling
Por que esta é a correta

`drain` cordons the node (sets `spec.unschedulable: true`, shown as `SchedulingDisabled`) and evicts pods. After maintenance, `kubectl uncordon worker-2` simply clears that flag and the scheduler resumes placing pods — the correct minimal action. There is no `kubectl drain --undo` subcommand; uncordon is the actual inverse of the cordon portion of drain. Deleting and rejoining the node is needlessly destructive: `SchedulingDisabled` does not mean the node left the cluster — it's `Ready`, just marked unschedulable. The unschedulable state is a node `spec` field set by the cordon/drain action, not a kubelet-managed taint that clears on kubelet restart, so restarting the kubelet would not uncordon it.

Faça o simulado completo

  • 50 questões sorteadas do banco, com cronômetro de 120 minutos
  • Nota por domínio e revisão de cada questão
  • Tutor de IA para conversar sobre cada questão que você errar
  • O que você errou alimenta seu plano de estudo
Começar simuladoEstudar a trilha antes

Simulado independente e não oficial. CNCF e o nome da prova são marcas de seus donos; o UpSkillScore não é afiliado a eles. Formato e nota de corte são a configuração do simulado no UpSkillScore, não uma declaração oficial.

Perguntas frequentes

Quantas questões tem o simulado de Certified Kubernetes Administrator (CKA)?

Tem 50 questões e limite de 120 minutos. A nota de corte do simulado é 66%.

Este é o exame oficial de Certified Kubernetes Administrator (CKA)?

Não. É um simulado independente, montado para espelhar a estrutura da prova real. Ele não substitui o exame oficial.

Preciso de conta para fazer?

Você lê a estrutura e as questões de exemplo sem conta. Fazer o simulado completo cronometrado, a nota por domínio e o tutor de IA exigem conta.