A more complete hierarchy

We are just handling simple hierarchies, so instead of programming a complex conditional statement in Puppet DSL to determine how a DNS resolver gets resolved, we can build a hierarchy that best represents our infrastructure, such as the following:

This example hierarchy would be represented with the following hiera.yaml:

---
version: 5
  hierarchy:
    - name: "Per-node data"
      path: "nodes/%{trusted.certname}.yaml"
 
    - name: "Per application data"
      path: "%{facts.application}.yaml"
 
    - name: "Per environment data"
      path: "%{server_facts.environment}.yaml"
 
    - name: "Per datacenter data"
      path: "%{facts.datacenter}.yaml"
 
    - name: "Common data"
      path: common.yaml

The facts, trusted, and server_facts hashes are the most useful hashes to...