The "environment" absolutely should _not_ be part of the name of the resource. Coupling the notion of "environment" with your workload (be it in their name or

The "environment" absolutely should _not_ be part of the name of the resource. Coupling the notion of "environment" with your workload (be it in their name or their configuration files) is an anti-pattern that I wish people stopped following. If you have 3 environments, dev staging and prod, you want resources in these environments to be named _exactly the same_ in each environment. Whatever your workloads are, wherever they run, they themselves should never _be aware of the environment they run in_. From a workload's point of view the "environment" and its label (dev, staging or prod) do not matter. What makes a workload a "dev" or a "production" workload are their respective configuration and the way they differ, _not_ the name of the "environment" they run in. What makes a workload a "dev" workload is dictated by its configuration (which database host it talks to for example). When the environment is being coupled in the configuration of your workloads, inevitably a developer will end up writing code like: if env == 'dev' then use_database("dev.example.com") This won't work at all at scale as people start adding new environments (imagine, "qa","test", "dev_1", "alphonso's_test", "etc") as developer will start adding more and more conditions: if env == 'dev' then use_database("dev.example.com") if env == 'qa' then use_database("qa.example.com") if env == 'dev_1' or env == 'alphonso' then use_database("dev_00.example.com") // ... add more and more and more conditions Instead, if your "dev" environment must talk to a "dev.example.com" database, create a variable called "DATABASE_HOST". And for each environment, set the "DATABASE_HOST" to the value of the database this specific environment needs to talk to. For example, for your "dev" environment DATABASE_HOST = "dev.example.com", and in your prod environment DATABASE_HOST = "prod.example.com". Here we clearly have a "dev" and a "prod", yet "dev" and "prod" are merely a "labels" for us humans to differentiate them, but the _configuration_ of these environments is really what defines them. The code above then simply becomes: use_database(DATABASE_HOST) and _this_ ^ will scale with an infinite amount of environments. _Configuration_ defines the "environment" _not_ the name of the environment. edit: I realize the article is talking about your cloud provider resources and people might be running multiple "environment" resources in a single account. The above applies to "workloads" talking to these "cloud provider resources", not to the resources themselves, since, of course, you can't have 2 DBs named the same under one single account (obviously the names would collide).