generally speaking, the CheckCommand objects provided inside the Icinga Template Library are provided by the Icinga 2 package. These command objects cannot be modified by the user, they serve as ready-to-use templates. These are maintained and updated by community members and developers, and each new Icinga feature release updates these commands in a non-breaking way.
That being said, each Icinga installation has these command definitions on its own, so it is not necessary to redistribute them to cluster zones. Also, it is not necessary to re-create them inside the Director and deploy them.
In order to work with these CheckCommand objects inside the Director, it imports them via the REST API inside the kickstart wizard. The import marks them as external objects being read-only. This allows you to define fields used in templates, objects, apply rules and service sets inside the Director.
In terms of external templates, this unfortunately doesn’t work. Mainly for two reasons - the Icinga 2 API cannot return these non-objects at runtime in full scope, and the Director also builds a template inheritance tree where all of them need to exist in the Director backend.
That being said, the Director pre-validates the configuration before deployments, and only allows to import templates it knows about (and all of its attributes).
I don’t know whether these templates can be created with the CLI or API inside the Director, but if such do not change much, it is common best practice to define them inside the Director.
In terms of apply rules, they can be managed outside the Director in their respective static config files. The Director doesn’t know about them, so each rule needs to match conditions defined and changed in the Director. This creates an overload in maintenance with editing two locations in the worst case.
It works e.g. with writing a rather complex notification rule which just notifies a ticket system instead of users, or other scenarios where advanced DSL code is necessary. Before going this route, you should ask yourself though whether this problem really cannot be solved in another way fitting into the Director’s scope.