An AWS CDK pull request renames a construct id from 'Table' to 'MainTable', and cdk diff now shows the live DynamoDB table being destroyed and a new one created. Explain how the CDK derives logical IDs from the construct tree, and how you would make that rename safe.

## What a logical ID is A CloudFormation template is a map of logical IDs to resource definitions. The logical ID is the identity CloudFormation uses to decide, on every update, whether a resource in the new template is the same resource it already manages. If a logical ID present in the deployed stack is absent from the new template, that resource is deleted. If a logical ID appears that was not there before, it is created. There is no rename operation anywhere in that model. That single fact is the root of this question. Everything else is about how the CDK chooses those IDs on your behalf. ## How the CDK builds one Constructs form a tree. Every construct takes `(scope, id, props)`, and the scope is its parent, so the ids chain into a path: `MyStack/MainTable/Resource`. At synthesis the CDK allocates a logical ID from that path — the readable components joined together, with a short hash of the full path appended so that two constructs with the same leaf id in different branches do not collide. Some structural ids such as `Resource` and `Default` are omitted from the readable part, which is why an `s3.Bucket` with id `Data` becomes something like `Data` plus a hash rather than `DataResource` plus a hash. The important property is that the ID is a **pure function of the path**. Not of the variable name, not of the resource's physical name, not of its position in the file, and not of anything random — which is what makes CDK deploys repeatable. But it also means every part of the path is load-bearing. ## Why the rename destroys the table Renaming the id from `Table` to `MainTable` changes the path, which changes both the readable prefix and the hash. The synthesized template now contains a logical ID CloudFormation has never seen, and no longer contains the one it is managing. The update therefore creates a new empty table and deletes the old one with all its data. The same mechanism fires in cases that look innocent: - Wrapping existing resources in a new construct to tidy the code — every child's path gains a component. - Moving a resource from the stack into a helper construct, or out of one. - Upgrading a shared construct library whose author renamed an internal child id. - Reordering nothing at all, but changing the id casing. None of these are visible as "dangerous" in a diff of the source. They are visible in `cdk diff`, which is exactly why the diff is read before the deploy rather than after it. ## The ways out **Do not rename.** The cheapest option, and the right default. Construct ids are part of the deployed contract, like a database column name. Rename the TypeScript variable, the class, the file — none of those touch the path. Say this first in an interview; the mitigations below are for when the rename is genuinely forced. **Pin the logical ID.** Every L2 construct has an L1 child reachable through `node.defaultChild`. Cast it to the matching `Cfn*` type and call `overrideLogicalId('TheDeployedId')`. Synthesis then emits the old ID under the new construct id, and CloudFormation sees no change at all. The cost is a permanent, slightly odd line of code that you must not delete, so comment it. **Rename at the stack level.** `Stack.renameLogicalId` overrides the generated allocation so the template keeps emitting the ID already deployed. It is the same idea applied without reaching into the child. **Accept the replacement.** For a stateless resource — a Lambda function, a security group, a queue you can drain — replacement may be entirely fine, and pinning IDs forever has its own cost. Decide deliberately rather than by accident. ## Prevention beats recovery The production discipline around this has three parts. Set a retain removal policy, and where the service offers it, deletion protection, on anything stateful — then the worst outcome of a mistaken rename is an orphaned resource and an empty new one, not a restore from backup. Run `cdk diff` in the pull request and make replacements of stateful resource types something a human must acknowledge. And treat any shared construct library's internal tree as an API: if the platform team renames a child id inside a published construct, every consumer's next deploy carries a replacement. ## The comparison worth making Candidates coming from other tooling often look for a "moved" declaration that tells the tool an address changed. The CDK has no such construct: identity is the path, and the remedies are to keep the path or to override the ID it produces. Knowing that difference — and not searching for a feature that does not exist while a production deploy is pending — is the point of the question.