Decide the approach for post-deployment smoke testing on UAT/PROD #216

Background

database/migrations/V1.4.0.2__initial_schema.ddl  includes a  public_cps_za_test  table used to write/read a "test topic" event, originally added by @oto-macenauer-absa as a PoC mechanism for basic post-deployment smoke testing (write to a test topic, read via SQS, confirm the pipeline works end-to-end). New question was raised whether this is still needed now that a DEV environment exists for testing, and flagged that it means a test-only object lives permanently inside the real UAT/PROD schema. @miroslavpojer raised that running any automated smoke test — read or write — against PROD carries real risk, especially write-based tests, which could be silently forgotten and cause harm over time.

Questions To Answer

1. Do we still need an automated post-deployment smoke test against UAT/PROD, given DEV exists for general testing?
2. If yes, should it be read-only, write-based, or both?
3. Should smoke-test objects (tables/topics) be kept separate from the real production schema/queues instead of embedded alongside real data (current solution)?
4. Should  public_cps_za_test be removed, kept as-is, or replaced with a differently scoped mechanism?

Additional Resources

• Discussion thread #214 (comment).
• Related: #201 (Flyway migrations setup)