Appendix: delivery readiness review
Use this review after the workshop to assess whether you can explain and demonstrate the seven-track workflow. An instructor or practice lead reviews your saved evidence and asks you to connect each observation to its conclusion. This is a discussion of delivery readiness, separate from the module exercises.
Prepare for the review
Bring your Git history, run-specific outputs, image references, inventory, and compliance report. Preserve the relationship between each file and the run or digest it describes. Keep passwords, tokens, and private signing keys out of shared evidence.
For each row, record Pass or Needs follow-up and explain the reason. Mark the overall review complete when all seven tracks and the delivery-scope discussion pass. A screenshot of a completed lesson is not evidence that its control worked.
Review the seven tracks
| Track | Demonstrate and explain | Evidence |
|---|---|---|
1 — Hummingbird |
Source verification gates copying, and destination verification gates publication. Explain what happens when verification fails. |
Ansible run output, source/destination digest and signature evidence, the negative attempt, and the published verified destination. The independent validation Job is optional instructor QA. |
2 — Dependencies |
Maven resolves through Nexus, and the POM selects the exact version named by the sample OSV fixed event. |
Authored settings, before/after dependency trees and downloads, and |
3 — Source |
Developer Hub creates the application; source records verified inputs; a reviewed Renovate PR updates its pin file. |
Catalog entry, Gitea commits, Dockerfile and POM, and the bot PR with the learner’s merge. |
4 — Build |
Explain source restrictions, dependency prefetch, offline Maven, and build-pod egress. Describe the scope and outcome of the known-bad test. |
Pipeline and NetworkPolicy configuration, selected-run logs, image digest and matching SBOM, plus negative-test logs and restored BuildConfig input. |
5 — Signatures |
Verify both application signatures and explain the Conforma pass/fail comparison and its attestation exception. |
Keyless verification, policy reports and snapshot, admission public key, and key-based verification for the same digest. Module 5.3 does not require a mirrored TUF exercise. |
6 — Production |
Show how the production commit selects the signed digest and how the runtime rejects an unsigned image. |
Fetched Git commits, Argo CD source/revision and health, desired digest and Ready pods, destination signature verification, and unsigned rejection reason. |
7 — Compliance |
Connect the retrieved application inventory to production, interpret the exact library version under the sample advisory, and explain the ACS outcome. |
TPA document IDs, downloaded inventory, OSV and OpenVEX, local blast-radius report, and a named ACS TaskRun with logs. An execution error needs follow-up; a completed policy rejection must be reported accurately. |
Use the corresponding modules in the navigation to revisit a missing observation. Tracks 1–4, 6, and 7 use direct evidence review; Track 5 retains its report and validation steps.
Discuss delivery scope
Choose a customer requirement from Consultant delivery map. Explain which workshop evidence supports it and what additional implementation or testing it needs. Use Konflux terminology when comparing platforms.
The discussion should distinguish image signing from provenance, connected mirroring from physical transfer, and a single-image sample assessment from organization-wide compliance. Python, Artifactory, and other deployment patterns are reference topics; the hands-on path remains one Java application.
Record the result
| Area | Result | Evidence and follow-up |
|---|---|---|
Track 1 |
||
Track 2 |
||
Track 3 |
||
Track 4 |
||
Track 5 |
||
Track 6 |
||
Track 7 |
||
Delivery scope |
||
Overall |
Write the observation, any gap, and the next action for each row. Agree on a follow-up demonstration where evidence is missing rather than treating workshop attendance as proof of readiness.