WIP: task 6-7 -- 7 under way

README.md

@@ -286,6 +286,9 @@ lcl$ terraform show | grep instance_state
     instance_state                       = "stopped"
 ```
 
+:warning: Apply was run in `-auto-approve` (non interactive) mode which
+assumes "yes" to all questions. Use with care!
+
 From the above commands' output we see that
   * the local state is refreshed before doing anything,
   * no changes are applied, and
@@ -400,7 +403,7 @@ resource "aws_instance" "app_server" {
 }
 ```
 
-Apply the change:
+Apply the changes:
 ``` shell
 lcl$ terraform apply -auto-approve
 aws_instance.app_server: Refreshing state... [id=i-0470db35749548101]
@@ -427,7 +430,77 @@ Plan: 0 to add, 1 to change, 0 to destroy.
 Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
 ```
 
-:bulb: Input variables can also be passed on the `apply` command line. **As an
-exercise**, find how to do that with another different value for
-`instance_name`. :question: Would that last change be persistent if we rerun a
+:bulb: **Exercise:** input variables can also be passed on the `apply` command
+line. Find how to do that with another different value for the variable
+`instance_name`. :question: Would this last change be persistent if we rerun a
 plain `terraform apply`?
+
+
+### Task #6: queries with outputs ###
+
+**Goal:** use output values to query a provisioned infrastructure.
+
+We have seen in the previous tasks that the infrastructure's status can be
+displayed via `terraform show`: a rather clumsy way, if you just want to
+extract some specific information. A better programmatic way of querying your
+infrastructure makes use of "outputs". Put the following in a file called
+`~/terraform/AWS/outputs.tf`:
+
+``` hcl
+output "instance_id" {
+  description = "ID of the EC2 instance"
+  value       = aws_instance.app_server.id
+}
+
+output "instance_public_ip" {
+  description = "Public IP address of the EC2 instance"
+  value       = aws_instance.app_server.public_ip
+}
+```
+
+We have declared two outputs. As usual with TF, before querying their
+associated values, we need to apply the changes:
+
+``` shell
+lcl$ terraform apply -auto-approve
+...
+
+Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
+
+Outputs:
+
+instance_id = "i-0470db35749548101"
+instance_public_ip = "34.201.252.63"
+instance_tags = tomap({
+  "Name" = "AnotherAppServerInstance"
+})
+```
+
+So, we already got the needed information, but, within a workflow, it is more
+practical to do something like:
+
+``` shell
+lcl$ terraform output -json instance_tags
+{"Name":"AnotherAppServerInstance"}
+```
+
+:question: What if the `Name` tag is changed outside TF? Try it.
+
+:question: What must be done to have TF respect that external change?
+
+:question: How to revert an external change via TF?
+
+
+### Task #7: SSH provisioning with Cloud-Init ###
+
+**Goal:** use Cloud-Init to provision an SSH access to your TF-managed
+instance.
+
+Did you try to SSH into the instance you created via TF? It cannot work,
+because we did not instructed TF about users, keys or anything else. **This is
+left entirely to you as an exercise.** You need to:
+
+  0. Destroy your infrastructure. There's a special TF command for that.
+  1. Create an SSH key pair.
+  2. Extend the `main.tf` with a `data` block referencing
+  ...