CKS Supply Chain Security 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.

• ✓

  Generate TLS certificates, then configure etcd with TLS, then restart etcd, then verify health and restrict network access

  Why this is correct

  This is the correct order because TLS certificates must be generated before configuring etcd to use them, then etcd must be restarted to apply the changes, and finally health verification and network restriction ensure the setup is secure and functional.

• ✗

  Configure etcd with TLS, then generate TLS certificates, then restart etcd, then verify health and restrict network access

  Why it's wrong here

  Configuring etcd to use TLS before any certificates are generated is logically impossible. The etcd configuration parameters, such as --cert-file, --key-file, and --trusted-ca-file, must reference existing PEM files; without them, the process will fail to start or silently fall back to plaintext communication. Additionally, any attempt to validate the configuration with clients will fail because they cannot securely connect without a certificate to present. Certificate generation must always occur first.

• ✗

  Generate TLS certificates, then restart etcd, then configure etcd with TLS, then verify health and restrict network access

  Why it's wrong here

  Restarting etcd immediately after generating certificates but before updating its configuration to enable TLS leaves the service running with its previous non-TLS settings, so the newly created certificates are never loaded. This creates a risky window where etcd is still exposed on plaintext HTTP despite having the necessary certificate material on disk, allowing potential data interception. The restart only applies TLS if the configuration has already been edited to reference the certificates, making this ordering functionally incorrect.

• ✗

  Restrict network access to etcd, then generate TLS certificates, then configure etcd with TLS, then restart etcd

  Why it's wrong here

  Applying network restrictions to etcd before provisioning TLS can sever administrative access needed to generate or distribute certificates. For example, if certificate generation depends on cloud provider APIs, an external CA, or communication with peer nodes, firewalling etcd ports first may block that connectivity entirely. Even if certificates are pre-staged, restricting the network without enabling TLS does not encrypt data, leaving data at rest and in transit vulnerable. TLS should be established first to secure the communication channels, then the network surface can be safely limited to trusted peers.

Go deeper

Related to this question