An operator restores an RDS snapshot and selects the production database's existing identifier. The restore fails, and the original instance is still running under that name. What should the restore use?
Select an answer to reveal the explanation.
Short Explanation
You cannot hang a second sign with the same street number while the first shop is still open. You restore to a new database identifier and leave the running instance on its current name. A reboot or a Multi-AZ setting does not free that name.
Full Explanation
An RDS instance identifier must be unique for the account in that Region. Restore creates a new instance, and the call fails when the chosen identifier still belongs to the instance that is running. Choosing a new identifier lets the restore proceed while production keeps its name and endpoint. Rebooting the original instance does not release the identifier. The name stays with that instance until it is renamed or deleted. Multi-AZ adds a standby in another Availability Zone. The standby is not a second instance with its own identifier, and enabling it does not move the name. A read replica is a different replica of the source, and it cannot be created under the source identifier while the source still has it. If the old name is required later, rename after cutover. The restore itself still needs a free identifier now. Caveat: the restored instance gets its own endpoint, so applications keep using production until you deliberately cut them over. Operational check: retry the restore with an identifier that does not already exist and confirm the new instance becomes available.