TD3 — Connect the API to private, recoverable data

Step 1 — Prepare private resources and a file secret · 30 minutes

Load scripts/course-env.sh and your observed digest from release.env. Use service names delivery-api and postgres, network td03-private, and explicit course.lab=TD03 plus course.environment=course-lab labels so TD4 can identify your objects. Create that labelled private bridge network and two named volumes: one for PostgreSQL data and one for a password file. Before reusing any same-named object, inspect its labels and stop if it is not yours. Generate a strong random password into an ignored host file with mode 0600; never print it or commit it. Move it into the Docker-owned secret volume without displaying its value. Arrange ownership so the PostgreSQL process and the API's permitted group can read the file through read-only mounts. Check readability as those users, while keeping the password out of terminal output and evidence. A named volume survives container removal; a container writable layer does not.

Step 2 — Connect PostgreSQL and the API privately · 35 minutes

Create your own repeatable scripts/td03-run.sh using the pinned PostgreSQL image and your TD2 API digest. Put both services on the private bridge. Mount the persistent data volume and supplied SQL initialization file into PostgreSQL; mount the password volume read-only into both services and pass the password file path to each process. Configure the API to reach postgres:5432 by Docker DNS. Apply explicit memory, CPU and process limits. Do not publish either service to a host port. Start PostgreSQL, wait for its readiness, then start the API. From a temporary peer on the same network, request /readyz; use docker inspect to verify both host port bindings are absent. Keep actual outputs under evidence/TD03/.

Step 3 — Prove data survives container replacement · 25 minutes

Insert one synthetic row into PostgreSQL and create one synthetic item through the supplied API. Record the returned item ID and read both records back. Stop and remove only your labelled TD3 service containers, leaving the named data and secret volumes intact. Re-run your saved definition, wait for readiness, then query the same row and API item. Compare the before/after values and container IDs. Explain why a new container ID with retained records supports the persistence claim; a restarted container alone would not.

Step 4 — Make and test a backup on disposable data · 40 minutes

Use pg_dump to save a custom-format backup in ignored backups/. These checks inspect the archive without restoring into your working database:

test -s backups/td03.dump
docker exec -i postgres pg_restore --list < backups/td03.dump
sha256sum backups/td03.dump

Check that the file is nonempty, list its contents with pg_restore --list, and record a SHA-256 checksum. Start a separate labelled PostgreSQL restore container with a new disposable data volume, no network and no host port. Verify the checksum before restoring with pg_restore. Query the synthetic row and API item in that restored database; compare them with the original records. Confirm the working database remained available and unchanged. Only after the checks pass, remove the labelled disposable restore container and volume. Preserve the dump and error if any check fails; never run a broad volume cleanup.

Step 5 — Explain three distinct claims · 50 minutes

Write evidence/TD03/OBSERVATIONS.md in your own words. For private reachability, cite network membership, service-name DNS, /readyz and absent host bindings. For persistence, cite the same row and API item after replacing the containers. For recovery, cite the checked dump and matching records in the separate restore target, including elapsed restore time. State the limit: this backup proves recovery of the captured records, not later writes or a complete disaster recovery objective. Keep the password and dump out of Git and shared evidence. TD4 will place these services behind a proxy in Compose.