In an AWS CloudFormation template, how do you make a whole resource and a single property exist only in production, and what happens to that resource when the condition later evaluates to false?

## The section and what may go in it `Conditions` is a top-level section, a map of names to boolean expressions: ```yaml Parameters: EnvType: Type: String AllowedValues: [dev, staging, prod] Conditions: IsProd: !Equals [!Ref EnvType, prod] IsNotDev: !Not [!Equals [!Ref EnvType, dev]] ProdInIreland: !And - !Condition IsProd - !Equals [!Ref 'AWS::Region', eu-west-1] ``` The available functions are `Fn::Equals`, `Fn::And`, `Fn::Or`, `Fn::Not`, `Fn::If` and `Condition` (referencing another condition by name). Inputs may be parameter values via `Ref`, pseudo parameters, mapping lookups via `Fn::FindInMap`, and other conditions. What they may **not** reference is a resource. Conditions are evaluated at the start of a create or update, before anything is provisioned, so `Fn::GetAtt` on a resource is meaningless here and is rejected. If your branch depends on something only knowable after a resource exists, conditions are the wrong tool — that is a custom resource, or a value supplied by the pipeline. ## Two granularities **Whole resource.** `Condition` is a resource attribute alongside `Type` and `Properties`: ```yaml ReadReplica: Type: AWS::RDS::DBInstance Condition: IsProd Properties: ... ``` Outputs take the same attribute, which matters because an output referencing a conditional resource must itself be conditional or the stack fails when the resource is absent. **Single property.** `Fn::If` chooses between two values inline, and `AWS::NoValue` is the branch that removes the property: ```yaml MultiAZ: !If [IsProd, true, false] BackupRetentionPeriod: !If [IsProd, 30, !Ref 'AWS::NoValue'] ``` Omitting a property is genuinely different from setting it to a default, because omission lets the service apply its own default — and for some properties, supplying a value at all changes update behaviour. `AWS::NoValue` is only meaningful inside `Fn::If`; it is not a general-purpose empty value. `Fn::If` nests, which is how you get more than two branches, though a three-deep nest is usually the signal that a `Mappings` lookup keyed by environment would read better. ## The dangerous part: conditions are re-evaluated on every update A condition is not a create-time switch that freezes. Every stack update recomputes it. If `ReadReplica` was created because `EnvType` was `prod`, and someone updates the stack with `EnvType=dev`, the resource is no longer part of the desired template — so CloudFormation **deletes it**. The same effect follows from editing the condition expression, or flipping the branch of an `Fn::If` that guarded whether a resource was declared. For a read replica that is inconvenient. For a database, a bucket that holds data, or anything with state, it is an incident. The mitigations are the ones you would expect: read the change set before executing it, because a conditional resource going away shows up there as a removal; and put a retention policy on stateful resources so an accidental removal does not destroy the data. ## When conditions are the wrong answer Conditions are seductive because one template feels DRY. Past a handful of them the template becomes hard to read — you can no longer tell what production looks like without mentally evaluating a dozen booleans, and no environment is exercised by testing another. Common alternatives: - **Mappings keyed by environment** for values that merely differ (instance size, retention days, AMI per region). `!FindInMap [EnvConfig, !Ref EnvType, InstanceType]` is far more readable than three nested `Fn::If`s. - **Separate templates**, or the same template deployed with different parameter files, when environments differ *structurally* rather than in a few settings. The rule of thumb interviewers like: conditions for a small number of genuine structural differences; mappings for values; separate templates when the branching starts to dominate the file. ## Summary shape of the answer Name the section, name the boolean functions, show `Condition:` on a resource and `Fn::If` with `AWS::NoValue` on a property, and then volunteer the update behaviour — that a condition turning false deletes the resource. That last point is what separates someone who has read the docs from someone who has operated a stack.