A production RDS database currently sits in one AWS CloudFormation stack and needs to move to a different stack, without being deleted or recreated. Walk through the steps, and say what happens if you get the order wrong.

## The constraint that shapes everything A physical resource can belong to exactly one CloudFormation stack. There is no move operation, and you cannot import a resource that another stack still manages. So the move is really two halves: the source stack must **release** the database while leaving it alive, and the target stack must **adopt** it. The order of those halves is the whole question, because the naive release deletes production. ## Step 1 — make the retain policy real first Add `DeletionPolicy: Retain` to the resource in the source template and update the stack, as its own deployment, with no other changes: ```yaml OrdersDb: Type: AWS::RDS::DBInstance DeletionPolicy: Retain UpdateReplacePolicy: Retain Properties: DBInstanceIdentifier: orders-prod # ...unchanged ``` This is metadata about how CloudFormation should behave, so the update makes no change to the running database. Do it as a separate deployment and confirm it succeeded — the entire safety of the next step rests on this one having landed. `UpdateReplacePolicy: Retain` is worth adding at the same time for the same reason. ## Step 2 — release from the source stack Now delete the resource block from the source template and update the stack again. Normally, removing a resource from a template tells CloudFormation to delete it. With `Retain` recorded, CloudFormation instead stops managing it and leaves it in place: the stack events show the resource leaving the stack, and the database keeps serving traffic. Anything else in the source stack that referenced it — an output, a `Ref` from a security group rule — has to be untangled in the same change, or the update fails. At the end of this step the database is running and **unmanaged**. That window is the risky part of the procedure: no stack describes it, so nothing will recreate it and nobody's template review protects it. Keep the window short and do not let anything else deploy into that account in the middle of it. ## Step 3 — adopt into the target stack Add the resource to the target template, carrying a `DeletionPolicy` because import requires one, then create a change set with `--change-set-type IMPORT` and a `--resources-to-import` entry mapping the logical id to the live instance's identifier: ```json [{"ResourceType": "AWS::RDS::DBInstance", "LogicalResourceId": "OrdersDb", "ResourceIdentifier": {"DBInstanceIdentifier": "orders-prod"}}] ``` Execute it. The stack goes to `IMPORT_COMPLETE` with nothing created, replaced or deleted. ## Step 4 — verify with drift detection Import records your template as the expected configuration without comparing it against the live database. If the template you wrote in the target stack differs from reality — a different instance class, storage size, backup retention, parameter group — the stack now holds a wrong expectation, and the first ordinary update that touches the resource can apply it for real, which for a database means a modification or even a replacement. So run detection on the imported resource and reconcile every `MODIFIED` property in the template before letting any normal deployment near the stack: ```bash aws cloudformation detect-stack-resource-drift \ --stack-name orders-prod-v2 \ --logical-resource-id OrdersDb ``` The cheapest way to get the template right in the first place is to read the live configuration from the service and write the template from that, rather than copying the source stack's version and hoping nothing drifted while it lived there. ## Failure modes, in order of severity **Removing before retaining.** The update deletes the database. This is the reason the two source-stack updates are separate deployments rather than one clever template edit — combining them is exactly where people get it wrong, and there is no undo. **Importing before releasing.** Rejected: the resource still belongs to the source stack. Harmless, but it tells you the order is fixed, not a preference. **A wrong template at import time.** Silent. Nothing fails, and the damage appears later during an unrelated deployment. Drift detection is the only thing standing between you and that. **Deleting the source stack to release the resource.** Works only if every retained resource genuinely has a retain policy, and takes everything else in the stack with it. Prefer removing the single resource from the template. ## Say this in the interview Retain, release, import, detect. Two source-stack updates, deliberately separate, and a drift check as the last step rather than the optional one.