The earlier incarnations of Hiera (version 3 or earlier) used a single, entirely global hiera.yaml. Since its hierarchy is entirely global, it's not actually possible to change it without changing all environments simultaneously. Environments are usually used to control code changes, so this really makes a single hiera.yaml file quite inappropriate. Hiera 5 uses three layers of configuration and data: 

• Global layer:
  • In Hiera 3, this was the only layer
  • Useful for very temporary overrides, for example, when your operations team must bypass regular change processes
  • The legacy Hiera 3 backends are still supported—so it can be used while migrating to Hiera 5
  • This layer should generally now be avoided. All regular data should now be specified in the environment layer
• Environment layer:
  • The environment layer is now where most of the Hiera data definition happens
  • Available across all modules in the environment
  • Overrides the module layer
• Module layer:
  • As we discussed in Chapter 1, Authoring Modules, the module layer can now configure default values and merge behavior for a module's class parameters. It is a handy alternative to using the params.pp pattern.
  • To get the identical behavior, as we are used to with the params.pp pattern, the default_hierarchy setting is advisable, as those bindings aren't in merges.
  • Data set in the environment layer overrides the default data configured by the author of the module.