07 Validate your knowledge and tear down

No infrastructure changes until the teardown at the end. Budget 20 to 30 minutes for the questions and 15 for the teardown.

Outcome

A score you can act on, and an AWS account and ClickHouse organization with nothing left running.

What this is testing

Fourteen questions, one per decision the workshop asked you to make. They are not recall questions about which button is where; they are the judgement calls, and several have options that are all technically true statements with only one that answers the question asked.

The coverage maps onto the modules:

• which replication tool does which hop, and what happens when you reach for the wrong one;
• what logical replication does not carry, and what the first write after cutover does about it;
• what makes a cutover window short, and which step dominates it;
• what an orphaned replication slot costs, on which machine, and how the symptom misdirects;
• why ReplacingMergeTree, and what the ordering key has to contain for it to be correct;
• what search_path shadowing changes and what it leaves alone, including which sessions see it and when;
• how to read an EXPLAIN for pushdown, and what a plan with an aggregate above a Foreign Scan is telling you; and
• what the benchmark proves and what it does not — including the PostgresBench citation, which substantiates exactly one sentence.

Grading is client-side and instant. Your answers are kept in this browser only; nothing is sent anywhere and no instructor sees a score. Answers and explanations stay hidden until every question is answered and submitted, so a first pass has to be a real attempt. Read the explanations on the ones you got right as well — several of them name the failure mode behind the distractor.

Loading assessment...

If a question's explanation does not land, the module it came from is the place to go, not this page. The model answers with full rationales are in the reference track.

Teardown

Everything below provisions nothing and destroys everything. Do this even if you have run out of time for anything else on this page — leaving these resources running is the workshop's only ongoing cost, and it is a daily one in two separate accounts.

The order matters, and it is not the reverse of the order you built things in. Two dependencies decide it:

• The subscription on Managed Postgres holds a replication slot on RDS. Dropping the subscription while RDS is still reachable removes that slot with it. Destroy RDS first and the drop has nobody to talk to, and you are left cleaning up by hand — or leaving a slot behind on an instance that no longer exists, which is at least harmless, unlike the alternative.
• The ClickPipe reads from Managed Postgres and holds a replication slot there. Delete the pipe before the instance.

1. Stop the local processes

kill "$(cat /tmp/writer.pid)" 2>/dev/null && sleep 3 && tail -1 /tmp/writer.log
cd "$(git rev-parse --show-toplevel)/workshops/postgres_migration/grafana"
docker compose down

2. Delete the migration pipe, while RDS is still up

If you already deleted it at the end of module 04, confirm and move on. Order matters here: deleting the pipe while RDS is still reachable is what lets it remove the replication slot it created. Destroy RDS first and the pipe has nothing to clean up on a machine that no longer exists.

Delete the pipe from Data sources on your Managed Postgres service, then check the source:

psql -h "$RDS_HOST" -c "SELECT slot_name, active FROM pg_replication_slots;"
psql -h "$RDS_HOST" -c "SELECT pubname FROM pg_publication;"

The first query must return no rows. The second normally still lists the pipe's generated publication, which is harmless — publications retain no WAL — and goes with the instance in the next step anyway. If the slot query returns a row, drop it explicitly: an inactive slot on a live instance is the disk-fill timer from module 03's failure injection, still running.

psql -h "$RDS_HOST" -c "SELECT pg_drop_replication_slot('<slot_name>');"

3. Delete the ClickPipe

In the ClickHouse Cloud console, open the ClickPipe you created in module 05 and delete it. Then confirm its slot is gone from Managed Postgres:

psql "$TARGET_DSN" -c "SELECT slot_name, active FROM pg_replication_slots;"

No rows. A deleted pipe that left a slot behind would hold WAL on the Managed Postgres instance for as long as the instance exists, which is until the next step — but check anyway, because the habit is the transferable part.

4. Destroy the RDS instance and everything around it

The two aws checks below run after the destroy, when terraform output has nothing left to read, so re-export the region first.

cd "$(git rev-parse --show-toplevel)/workshops/postgres_migration/terraform"
export AWS_REGION="$(terraform output -raw region)"
echo "$AWS_REGION"
terraform destroy

This removes the DB instance, the custom parameter group, the DB subnet group and the security group — including the wide port 5432 allowlist you opened in module 03, which is the revert that matters most here. skip_final_snapshot is set, so nothing lingers as a snapshot you keep paying for.

Verify with Terraform and then independently, because a destroy that failed partway is the expensive case:

terraform state list
aws rds describe-db-instances --query "DBInstances[].DBInstanceIdentifier" --output table
aws rds describe-db-snapshots --snapshot-type manual --query "DBSnapshots[].DBSnapshotIdentifier" --output table

terraform state list prints nothing. Neither AWS query should name anything belonging to this workshop.

5. Delete the Managed Postgres instance

Delete it with the same CLI that created it in module 03. Its shop database, the two roles, the foreign server and the ch schema all go with it; there is nothing to clean up inside it first.

clickhousectl cloud postgres delete "$TARGET_PG_ID"

If TARGET_PG_ID is not set — a fresh terminal, or you are back the next day — list the instances and take the id from there. Do this rather than skipping the step: a Managed Postgres instance left running is the second most expensive thing this workshop can leave behind, after the RDS instance you just destroyed.

clickhousectl cloud postgres list

list is beta and may return empty or FORBIDDEN depending on your API key's role. If it does, use the console — Managed Postgres — and do not take an empty list as proof that nothing is running.

6. Delete the ClickHouse service

Delete the service created in module 05, including its shop database and the workshop user:

clickhousectl cloud service delete "$CH_SERVICE_ID"

If CH_SERVICE_ID is not set — a fresh terminal, or a later day — list them and take the id from there:

clickhousectl cloud service list

Check the name against the id before you confirm, especially if your organization has other services. This is the one deletion in the teardown that can hit something that is not yours.

7. Keep what is worth keeping

The infrastructure is gone; the artifacts are not, and they are the part with a shelf life:

cd "$(git rev-parse --show-toplevel)/workshops/postgres_migration"
ls bench/results/
cat runbook/cutover.md
rm -f .env.local /tmp/schema.sql /tmp/source.txt /tmp/target.txt

bench/results/before.json and after.json hold both measurements with their configuration blocks. runbook/cutover.md is the document you wrote, executed and amended — it is the thing to take to work. Delete .env.local; it holds the two role passwords.

Nothing left running

Done when

• every row of the table above is confirmed, not assumed;
• terraform state list prints nothing and no AWS query names a workshop resource;
• both replication slots are gone, on both instances, before the instances were;
• bench/results/ holds both runs; and
• .env.local is deleted.

What you did

You moved a live transactional workload between two Postgres instances with under a minute of write downtime, executing a runbook you wrote before you had a target to rush at. You found out, on paper if module 02 went well, that logical replication does not carry sequence values. You broke replication on purpose and watched a suspended subscription turn into a disk-fill timer on a machine nobody was looking at. You streamed the analytical copy into ClickHouse with the other replication tool, choosing the engine and the ordering keys rather than accepting them. And then you moved the analytical workload onto a column store with one ALTER ROLE, proved three ways that the application had not changed, found the one panel where the planner's coverage ran out, and measured what the whole thing bought: not a faster dashboard, but the checkout throughput the dashboard had been taking.