Lesson 0019 · 25 minutes · Cluster Setup

Verify a platform binary before deployment

A checksum does not prove who produced an artifact, but it detects whether the bytes match a checksum obtained through a trusted channel. Treat a mismatch as a release blocker, not a warning to work around.

Exam reflex: verify the artifact before copying it into a privileged path, making it executable, or restarting a control-plane component. A failed checksum means stop and investigate.

Timed task: 15 minutes

In lab/lesson-19-artifacts, the trusted-release team supplied SHA256SUMS separately from the two received artifacts. Verify both artifacts using a Linux checksum command. Then create lab/lesson-19-answer.md containing:

  1. The exact verification command you ran.
  2. Which artifact is verified and may proceed to the next deployment-review stage.
  3. Which artifact must not be deployed.
  4. Two appropriate next actions for the mismatched artifact.

Do not edit either artifact or the checksum file. The artifacts are small training stand-ins, not real Kubernetes executables.

Verification

cd lab/lesson-19-artifacts
sha256sum -c SHA256SUMS

# PowerShell equivalent for a single artifact:
Get-FileHash .\kubelet-v1.35.0-linux-amd64 -Algorithm SHA256

One result should be OK; one should be FAILED. A command can return non-zero when any verification fails—that non-zero result is expected evidence, not a reason to skip the check.

Retrieval check

Question

What is the correct immediate response to a checksum mismatch for a proposed kubelet binary?

Documentation target

Review the official Kubernetes release process and the security guidance for obtaining release artifacts. In production, pair checksums with signed provenance and trusted release channels.

What to send me

Send the four requested items from your Markdown answer. I’ll check your operational decision, not just the command syntax.