Courseiva

CKA Practice Question: Cluster Architecture, Installation and Configuration

You are asked to backup the etcd database on a control plane node. The etcd is running as a static pod. Which command sequence will create a consistent snapshot?

⚠ Common exam trap

Watch out — candidates often assume 'kubectl exec' into the etcd pod (Option A) is sufficient, but they forget that etcdctl inside the pod still needs explicit TLS flags and endpoint specification, or they mistakenly use an insecure HTTP endpoint (Option D) without realizing that production etcd requires HTTPS.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /backup/etcd-snapshot.db

It uses the etcdctl v3 API with the required authentication flags (--cacert, --cert, --key) and the correct endpoint (https://127.0.0.1:2379) to connect to the etcd server running as a static pod. This ensures a consistent snapshot is taken over the secure gRPC connection, which is mandatory when etcd is configured with TLS.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • kubectl exec -n kube-system etcd-controlplane -- etcdctl snapshot save /backup/etcd-snapshot.db

    Why it's wrong here

    While `kubectl exec` allows running commands inside a pod, directly executing `etcdctl` without specifying `ETCDCTL_API=3` will default to API v2, which is incompatible with modern Kubernetes etcd deployments. Furthermore, even if the API version were set, `etcdctl` requires specific TLS certificates (`--cacert`, `--cert`, `--key`) to authenticate with the secure etcd server, which are missing here. The `/backup` path is also unlikely to be writable or persistent within the ephemeral container filesystem.

  • ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db

    Why it's wrong here

    This command correctly sets the `ETCDCTL_API` environment variable to `3`, which is essential for interacting with modern etcd clusters. However, it fails to specify the `--endpoints` flag, meaning `etcdctl` won't know where to connect to the etcd server, defaulting to `127.0.0.1:2379` but still lacking the crucial TLS authentication parameters. Crucially, it omits all necessary TLS certificates (`--cacert`, `--cert`, `--key`) required for secure communication with a production Kubernetes etcd instance, leading to connection refusal.

  • ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /backup/etcd-snapshot.db

    Why this is correct

    This command is the correct approach for backing up an etcd database on a Kubernetes control plane. It explicitly sets `ETCDCTL_API=3` for compatibility with modern etcd versions, specifies the secure HTTPS endpoint `https://127.0.0.1:2379`, and provides all required TLS certificates (`--cacert`, `--cert`, `--key`) for mutual authentication with the etcd server. This ensures a secure and successful connection, allowing `etcdctl` to perform the snapshot operation reliably.

  • etcdctl --endpoints=http://localhost:2379 snapshot save /backup/etcd-snapshot.db

    Why it's wrong here

    This command is fundamentally flawed for several reasons. It omits `ETCDCTL_API=3`, causing `etcdctl` to default to the deprecated API v2, which is incompatible with Kubernetes' etcd v3. More critically, it attempts to connect using insecure HTTP to `localhost:2379` without any TLS certificates. Production Kubernetes etcd clusters are configured for secure HTTPS communication with mutual TLS authentication, meaning this connection attempt will be rejected outright due to protocol mismatch and lack of credentials.

About these practice questions

One of 302 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.