Recover an authenticated etcd dependency without stale watches
A hands-on CKA lab. You produce the real artefact and 10 automated checks verify it behaves the way the exam expects.
- Certification
- CKA
- Format
- Structured configuration
- Difficulty
- hard
- Estimated time
- 45 min
- Automated checks
- 10
The brief
Repair recovery.json: steps contain host=recovery plus one command each; etcdCommand and apiCommand supply effective service arguments. Commands are inert. This supplied host has systemd-managed etcd and kube-apiserver, not static Pods. Both services initially remain active but unhealthy. Stop both before restore; preserve /var/lib/etcd. Empty output directories are /recovery/explicit and /recovery/default. Approved /backup/approved.db has status hash f00d1234, revision 900 and a valid integrity footer. /backup/old.db has dead1234/revision600 and old values; /backup/damaged.db has the approved observed contents/revision but an invalid footer. Inspect the chosen source with etcdutl snapshot status before restore; require the approved hash/content/revision and enforced integrity. Restore using etcdutl snapshot restore to unused output storage. Never skip the hash check. Maximum pre-failure observed revision is 3000: restored revision must exceed it and all restored revisions must be marked compacted. Restore adds --bump-revision to snapshot revision. Match the running etcd data-dir, member name, initial-cluster, advertised peer and token to the restore. Old token old-production is forbidden. A single loopback peer may be http://localhost:2380 or http://127.0.0.1:2380. Default single-member identity is default, initial-cluster=default=http://localhost:2380, token=etcd-cluster. Client URLs must be https://127.0.0.1:2379 and/or https://localhost:2379 with client-cert-auth. Server CA/cert/key: /pki/ca.crt, /pki/server.crt, /pki/server.key. API/client CA/cert/key: /pki/ca.crt, /pki/api.crt, /pki/api.key. Configure API etcd endpoints and credentials; start services and observe etcdctl endpoint health, kubectl get --raw=/readyz and exact etcdctl get reads of /registry/configmaps/default/recovered=current-settings and /registry/deployments/default/api=image=api:stable. Every command must succeed. Inspect restore revision and failure witnesses; repair without Reset.
What the checks verify
Your work is graded on 10 independent properties, not on matching one reference answer.
- Bounded single commands and process arguments use the disclosed typed etcd3.6 grammar.
- The approved snapshot hash, revision and original keyspace are inspected before restore with integrity enforced.
- Both supplied services are stopped before every restore operation.
- Unused replacement storage preserves the original directory and restored logical membership matches the running service.
- The consumed restored revision strictly exceeds the maximum observed pre-failure revision.
- The forward restored revision and earlier watch history are marked compacted.
- HTTPS listener/API endpoint references and supplied server/client TLS paths preserve client authentication.
- Restored authenticated etcd and its API dependency are started and freshly observed healthy/ready.
- Authenticated exact reads observe every required restored key/value after final etcd startup.
- Every declared recovery or observation command succeeds in the supplied state sequence.
Where this sits in the CKA blueprint
- Domain
- Cluster Architecture, Installation and Configuration
- Objective
- Highly Available Control Plane
- Skill
- Control Plane and etcd Availability
Part of CKA preparation
Labs are written by ExamNova to teach the decisions the exam tests. They are not reproductions of vendor lab content.