After a point-in-time restore, a new RDS instance is online with a different endpoint. The ticketing application's configuration still names the original endpoint, so it reads the old database. What should change?
Select an answer to reveal the explanation.
Short Explanation
The restored database is a new shop on a new street, and your sign still points at the old one. You update the application configuration to the new endpoint so it uses the restored instance. Rebooting the original or turning on Multi-AZ does not move that name to the restore.
Full Explanation
Point-in-time restore creates a new RDS instance. That instance has its own endpoint, and the original instance keeps the endpoint it already had. The ticketing application is still configured with the original name, so it connects to the old database and never sees the restored data. Updating the application configuration to the new endpoint points it at the restored instance. Rebooting the original instance restarts that instance. It does not load the restored data into it, and it does not change which host the old endpoint names. The master password authenticates clients to the instance they already reached. Resetting it does not redirect the old DNS name to the new instance. Multi-AZ failover moves the original instance's endpoint to its own standby, which is a copy of the original, not the separate instance the restore created. Caveat: any other client that has the old endpoint hardcoded, including a reporting job, keeps reading the old database until that client is updated too. Operational check: from the application host, resolve the configured endpoint and confirm it is the new instance, then read a row that exists only in the restore.