Simulado · CNCF
Simulado Kubernetes and Cloud Native Associate (KCNA)
Resposta curta
O simulado de Kubernetes and Cloud Native Associate (KCNA) tem 50 questões em 90 minutos, com nota de corte de 75%, 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
- Cloud Native Architecture
- Cloud Native Application Delivery
- Cloud Native Observability
- Container Orchestration
- Kubernetes Fundamentals
Questões de exemplo, com explicação
Três questões do banco, abertas para ler.
A team needs to run 5 identical replicas of a stateless web app and wants Kubernetes to automatically recreate Pods if they crash and to support rolling updates. Which resource is the most appropriate choice to declare and manage this desired state?
- A standalone Pod, which Kubernetes scales automatically when it crashes
- A Deployment, which manages a ReplicaSet to maintain the desired number of Pod replicas ✓ (correta)
- A Namespace, which controls how many replicas of an app may run
- A Service, which keeps the desired count of replicas running and restarts failed Pods
Por que esta é a correta
A Deployment, which manages a ReplicaSet to maintain the desired number of Pod replicas, is correct: Deployments are the standard way to declaratively manage stateless replicated apps, providing self-healing (the underlying ReplicaSet recreates failed Pods) and rolling updates. 'A Service, which keeps the desired count of replicas running and restarts failed Pods' is wrong because a Service only provides stable network access and load balancing to Pods, it has no role in replica count or restarts. 'A standalone Pod, which Kubernetes scales automatically when it crashes' is wrong because a bare Pod is not self-healing or scalable, if its node fails the Pod is gone with no controller to recreate it. 'A Namespace, which controls how many replicas of an app may run' is wrong because a Namespace is a logical partition for organizing resources, not a replica controller (quota limits exist but are separate ResourceQuota objects, not the replica manager).
In a standard Kubernetes control plane, which CNCF project serves as the distributed key-value store that holds the cluster's entire state and configuration data?
- Prometheus, which is responsible for storing the cluster's state and configuration data
- etcd, a consistent and highly available key-value store used as Kubernetes' backing store ✓ (correta)
- containerd, which stores cluster state in addition to running the containers
- Envoy, which acts as the persistent database for all Kubernetes object definitions
Por que esta é a correta
etcd is correct because Kubernetes uses it as the single source of truth for all cluster state, storing every object's desired and current configuration in a consistent key-value store. Prometheus is wrong because it is a monitoring and time-series metrics system; it scrapes and stores metrics, not cluster object state. Envoy is wrong because it is an L7 proxy used for service networking and as a data-plane proxy in service meshes, not a database. containerd is wrong because it is a container runtime that pulls images and runs containers; it does not store cluster state.
Kubernetes is designed so that it can work with different container runtimes (containerd, CRI-O, and others) without changing its own core code. What makes this pluggability possible?
- Each runtime being required to be a fork of Docker so the commands stay identical
- The Container Runtime Interface (CRI), a standard API the kubelet uses to talk to any compliant runtime ✓ (correta)
- Kubernetes embedding a single fixed runtime that all clusters must use
- The Container Network Interface (CNI), which standardizes how containers are scheduled
Por que esta é a correta
The Container Runtime Interface (CRI), a standard API the kubelet uses to talk to any compliant runtime is correct because CRI defines a common contract so the kubelet can drive any runtime that implements it, making runtimes interchangeable. The Container Network Interface (CNI) is wrong because CNI standardizes pod networking, not runtime communication, and it has nothing to do with scheduling. Requiring each runtime to be a fork of Docker is a misconception: runtimes like containerd and CRI-O are independent projects, and CRI is what lets them plug in, not shared lineage. Kubernetes embedding a single fixed runtime is wrong because that would be the opposite of pluggability; CRI exists precisely so no single runtime is hardcoded.
Faça o simulado completo
- 50 questões sorteadas do banco, com cronômetro de 90 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
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 Kubernetes and Cloud Native Associate (KCNA)?
Tem 50 questões e limite de 90 minutos. A nota de corte do simulado é 75%.
Este é o exame oficial de Kubernetes and Cloud Native Associate (KCNA)?
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.