diff --git a/SwitchEngines/README.md b/SwitchEngines/README.md
index d8ec993df2c732b86b4d7b4302bbf4110b7ea17a..e8b7ea95d8edacda6e2beb0a8a55fa8ad14b87af 100644
--- a/SwitchEngines/README.md
+++ b/SwitchEngines/README.md
@@ -862,6 +862,12 @@ The solution might be something like:
 
 ``` hcl
 resource "terraform_data" "kind_cluster" {
+  # run only when a given resource processing has terminated
+  depends_on = [...]
+
+  # rerun when something else has changed, e.g., a conf file
+  triggers_replace = [...]
+
   connection {
     type        = "ssh"
     user        = ...
@@ -880,11 +886,20 @@ resource "terraform_data" "kind_cluster" {
 
   provisioner "remote-exec" {
     inline = [
-	  "shell command",
-	  ...
+	  # force the script to terminate at the first failure
+	  "set -o errexit",
+	  "other shell command",
+	  ...,
+	  # allow background jobs (Docker, kernel, etc.) to terminate
+	  "sleep 30"
     ]
   }
 }
+
+resource "terraform_data" "metallb_service" {
+  # same structure as above
+  ...
+}
 ```
 
 :bulb: Please mind that:
@@ -896,18 +911,18 @@ can test the creation of the two resources separately.
 - Since the lines of a `remote-exec` are merged into a script, it is wise to
   start it with the command `set -o errexit`, so that the whole script exits
   at the first error.
-
-:warning: You will probably hit some thorny issues:
-
-- Depending on how you code the `terraform_data` block(s), the resource(s)
-  might get processed too soon or in the wrong order. So, be sure of using
-  *variable references* so as to induce indirect dependencies. You might also
-  need to explicitly declare a `depends_on` list.
+- Using *variable/resource references* imposes implicit processing of changed
+  resources. However, to ensure the correct processing flow, some dependencies
+  should be explicitly imposed via arguments `depends_on` and
+  `triggers_replace`. Failing to do so might cause the `terraform_data`
+  resource processing to start before the `app_server` has been finalized.
 - Before doing anything, you must wait for Cloud-init to finish its tasks:
-  this can take several minutes (at least 4-5).
+  this can take several minutes (at most 4-5). You can probe it with a
+  remote-exec command `cloud-init status --wait`.
 - KinD and K8s are very complex and, during set up, might fail in unexpected
   ways, chiefly because of system/network issues. Thus, it is wise to wait a
-  bit (at least 20-30 seconds) after each `kind/kubectl` command.
+  bit (at least 20-30 seconds) after each `kind/kubectl` command (use `sleep
+  ...`).
 
 
 <!--