CKS Cluster Setup Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  1. Generate a new certificate and key pair for the API server. 2. Replace the existing certificate files on the control plane node. 3. Restart the kube-apiserver process or container. 4. Verify the new certificate is serving correctly using curl or openssl.

  Why this is correct

  This is the correct order because the new certificate must be generated first, then its files must replace the old ones, the API server must be restarted to load the new certificate, and finally verification ensures the process succeeded.

• ✗

  1. Restart the kube-apiserver process. 2. Generate a new certificate. 3. Replace the old certificates. 4. Verify.

  Why it's wrong here

  Restarting kube-apiserver before generating a new certificate only causes the process to reload the existing certificate from disk, so it does nothing to rotate anything. If the old certificate is still present, the restart is wasted; if the old certificate has already been removed or expired, the API server may fail to start. The subsequent generate/replace steps cannot take effect until another restart, making the first restart redundant and the sequence incorrect.

• ✗

  1. Replace the existing certificate files. 2. Generate a new certificate. 3. Restart the API server. 4. Verify.

  Why it's wrong here

  Attempting to replace certificate files before generating the new certificate is an impossible operation because there is no new key/cert pair to copy into place. Even if you removed the old files first, the API server would be left with no valid credentials, and any subsequent generation step would not automatically re-deploy the files unless repeated. The correct sequence must generate first to have the artifacts available for replacement.

• ✗

  1. Generate new certificate. 2. Replace old files. 3. Verify using curl. 4. Restart API server.

  Why it's wrong here

  Running curl or openssl verification immediately after replacing files but before restarting the API server cannot confirm rotation because the running process still uses the previously loaded certificate from memory. The verification would either connect to the old certificate, giving false confidence, or fail if the old certificate has expired/been revoked, while the new files sit unused on disk. Only a restart loads the new certificate, so verification belongs after the restart step.

Go deeper

Related to this question