You usually end up with a more imperative part to execute a check or to pull data and push it to a monitoring system. "Call this API / read this file. For each line / json key, mangle into monitoring format. Add in missing metadata. Push all resulting lines to monitoring ingress host".
Beyond that, our icinga has a very declarative config file. "This is host foo.local, it runs a tomcat with application X and a mysql and backups". The system then goes ahead and figures out what kind of checks might be necessary for an application X, or backups.
- Wash the rice - Boil the rice gently for 20 mins - Whilst the rice is cooking, sauté the finely diced onions.. - Before they've turned brown...
And then at the next level up is complete base recipes, like "this is essentially a bearnaise except with _____" or "you start with a ______ but instead of _____ you _____". So the recipes are expressed with combinators over modifiers and existing recipes.
[1] http://www.cookingforengineers.com/
[2] http://www.cookingforengineers.com/recipe/172/Pan-Pizza/trn
Cooking recipes are good examples of imperative "scripts", and for the most part it would be silly to try to write them in a declarative style. But note that they too often contain declarative formulas, like "if the pancakes stick to the pan, use more butter". It's the most natural thing in the world to add such regulative rules. There is no mention of exactly when this rule should be applied, in the sense of where it fits into a sequence, and trying to formulate it that way would be cumbersome.
It's a big drawback for the industry languages you allude to (and for the software industry as a whole) that there is no simple way to integrate such rules into programs. (I suppose aspect oriented programming is/was an attempt at that.)
You can also read through the rules for any board game. They typically consist of a mix of imperative, sequential instructions, regulative rules, and constraints. Why? Because that is the most natural thing.