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.14.0.rhlw-00001 in the default dependency property.

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.