In Terraform, which parts of a resource can a dynamic block NOT generate, and why?

## Two separate limits, often confused ### 1. Blocks, not arguments A `dynamic` block generates *repeatable nested blocks*. It has no effect on arguments. The confusion is understandable because HCL writes both inside the same braces, but a provider's schema distinguishes them sharply: ```hcl resource "aws_security_group" "web" { name = "web" # argument -> use an expression tags = { Env = "dev" } # argument (a map) -> use an expression ingress { ... } # nested block -> a dynamic block can generate it } ``` So the answer to "how do I build tags dynamically?" is never a dynamic block; it is `merge(var.common_tags, { Name = local.name })`, or a `for` expression producing a map. Conversely, `ingress`, and any other repeatable nested block the provider declares, is exactly what `dynamic` is for. A useful way to tell them apart without guessing: look at how the provider documentation writes it. `tags - (Optional) A map of tags` is an argument. `ingress - (Optional) Configuration block ... can be specified multiple times` is a repeatable block. ### 2. Schema blocks, not meta-arguments The second limit is stricter and more interesting. Terraform's documentation states that a dynamic block can only generate arguments that belong to the resource type, data source, provider or provisioner being configured — it cannot generate meta-argument blocks such as `lifecycle`, and it cannot generate `provisioner` blocks, because Terraform must process these before it is safe to evaluate expressions. The same applies to the meta-arguments that are not blocks: `count`, `for_each`, `depends_on` and `provider` are read while Terraform builds the resource graph. That graph is what decides evaluation order in the first place, so those values cannot themselves be the result of arbitrary evaluation. `lifecycle` sits in the same bucket: `prevent_destroy` and `ignore_changes` steer how the plan is constructed, before per-instance expressions have results. ## What people try, and what to do instead **"Make ignore_changes conditional on an input."** Not possible via `dynamic`, and `ignore_changes` takes attribute references rather than arbitrary expressions. The realistic answers are: accept ignoring the attribute always; split into two resources selected by `count`, each with its own literal lifecycle; or move the branch up into the module interface so a caller picks the behaviour. **"Generate provisioners for a variable list of scripts."** Also not possible. Provisioners are meta-blocks. Loop *inside* one command, or push the work to the machine image or a configuration-management run, which is where it belongs anyway. **"Attach depends_on dynamically."** No. `depends_on` is fixed configuration; pass the dependency through an attribute reference so the implicit dependency does the work, which is stronger and cheaper than an explicit one. **"Make the provider conditional."** No. Provider selection is graph-time; the pattern is an aliased provider chosen by the caller. ## Why the restriction is the right design It is tempting to read the limit as an implementation gap, but it falls straight out of how Terraform works. The dependency graph must exist before values are known, because the graph determines the order in which values *become* known. Anything that shapes the graph — how many instances, what depends on what, which provider, whether a resource may be destroyed — has to be resolvable up front. Everything that merely fills in a resource's body can wait, and that is exactly the ground `dynamic` covers. Knowing where the line sits keeps you from burning an afternoon on a construction the language will never accept, and it makes the alternative obvious: when configuration genuinely must vary in graph shape, you vary it with separate resources, separate modules or `count`, not with generated syntax.