You define an AWS CDK stack without passing the `env` property. Where does it deploy, what do `stack.account` and `stack.region` resolve to, and what stops working?

## What `env` actually sets `env` is a property of `StackProps` (and of `StageProps`): `{ account, region }`. It tells the CDK, at synthesis time, which AWS environment this stack is destined for. It is not credentials — it does not authenticate anything. It is a declaration that lets the CDK resolve environment-specific values while building the template, and lets the CLI refuse to deploy into the wrong place. ```typescript new ServiceStack(app, 'Prod', { env: { account: '111122223333', region: 'eu-west-1' } }); ``` ## Environment-agnostic: what you get Leave `env` out and the stack is environment-agnostic. Wherever the template needs the account or region, the CDK emits the CloudFormation pseudo-parameters `AWS::AccountId` and `AWS::Region`, which CloudFormation fills in at deploy time. The upside is genuine portability: one template, any account, any region — useful for a stack you publish for other people to deploy. The deployment target is then whatever the CLI resolves from the usual credential chain: `AWS_PROFILE`, environment variables, SSO cache, instance role. Nothing in the code constrains it. ## What stops working Everything that requires knowing the environment *before* the template exists: **Context lookups.** `ec2.Vpc.fromLookup`, `route53.HostedZone.fromLookup`, `ec2.MachineImage.lookup` and `ssm.StringParameter.valueFromLookup` all run during synthesis: the CLI calls AWS with your credentials and bakes the answer into the template as a literal. That requires a concrete account and region — both to make the call and to key the cache entry in `cdk.context.json`. In an environment-agnostic stack these throw an error telling you to specify `env`. **Branching on the environment in code.** `stack.region` is an unresolved token, a placeholder string that only becomes real inside CloudFormation. So `if (stack.region === 'us-east-1')` is always false, and string-concatenating it into a name that must be known at synth time produces a token instead of the value you expected. `cdk.Token.isUnresolved(value)` is how you check whether a value is one of these placeholders. **Availability zones.** `stack.availabilityZones` cannot ask AWS how many AZs the target region has, so an environment-agnostic stack falls back to two AZs. A VPC construct that would have spread across three subnets quietly builds two. ## The three ways to set env 1. **Omit it** — portable template, no lookups, two AZs. Fine for a sample or a redistributable stack. 2. **Hardcode it** — `env: { account: '111122223333', region: 'eu-west-1' }`. Synthesis is deterministic: the same code produces the same template on every machine and in CI, and the CLI errors if your credentials resolve to a different account. This is what production estates do, usually with the values coming from a per-environment config object in the repo. 3. **Take it from the ambient profile** — `env: { account: process.env.CDK_DEFAULT_ACCOUNT, region: process.env.CDK_DEFAULT_REGION }`. The CLI sets those two variables from the credentials in effect, so the stack gets a concrete environment (lookups work) but *which* environment depends on whoever ran synth. Convenient for a personal sandbox, dangerous as a default for shared environments: the same commit produces different templates for different people, and reviewing a diff tells you less than you think. ## Choosing The deciding question is whether the template is meant to be identical everywhere or specific to one place. A production stack is specific: you want the AMI, the VPC id and the AZ list pinned, you want `cdk diff` to be honest, and you want a misconfigured profile to fail loudly rather than deploy your production stack into a sandbox. Pin `env`. A library-style stack that other teams deploy into their own accounts is the genuine case for environment-agnostic — and it must then avoid lookups by design, taking VPC ids and similar values as explicit props or CloudFormation parameters instead. A useful middle pattern is to keep the environment values in one config file keyed by environment name, select it from a context value or an environment variable at the top of `bin/app.ts`, and pass the result into every stack. Environments are then explicit and greppable, and no stack is left agnostic by accident.