Bird
Raised Fist0
Terraformcloud~30 mins

Connection blocks for SSH in Terraform - Mini Project: Build & Apply

Choose your learning style10 modes available
Connection blocks for SSH
📖 Scenario: You are setting up a Terraform configuration to manage a virtual machine in the cloud. To apply changes remotely, you need to configure SSH connection details so Terraform can connect to the VM securely.
🎯 Goal: Build a Terraform configuration that defines an SSH connection block with the correct parameters to connect to a remote server.
📋 What You'll Learn
Create a resource block for a virtual machine named example_vm.
Add a connection block inside the resource with SSH details.
Use the exact variable names and values as specified.
Ensure the connection block includes type, host, user, and private_key.
💡 Why This Matters
🌍 Real World
Terraform uses connection blocks to securely connect to remote servers for provisioning and configuration management.
💼 Career
Understanding connection blocks is essential for infrastructure engineers and DevOps professionals managing cloud resources with Terraform.
Progress0 / 4 steps
1
Create a Terraform resource block for a virtual machine
Write a Terraform resource block named example_vm of type aws_instance with the ami set to "ami-12345678" and instance_type set to "t2.micro".
Terraform
Hint

Use the resource keyword followed by the resource type and name. Set the ami and instance_type attributes exactly as shown.

2
Add a connection block with SSH type
Inside the example_vm resource block, add a connection block with type set to "ssh".
Terraform
Hint

The connection block goes inside the resource block. Set type = "ssh" exactly.

3
Add host, user, and private_key to the connection block
Inside the connection block, add host set to "${self.public_ip}", user set to "ubuntu", and private_key set to file("~/.ssh/id_rsa").
Terraform
Hint

Use host = "${self.public_ip}" to refer to the instance's public IP. Set user and private_key exactly as shown.

4
Add a provisioner block using the connection
Add a provisioner block of type remote-exec inside the example_vm resource. Use the existing connection block and add a inline command to run echo Hello, Terraform!.
Terraform
Hint

The provisioner block runs commands on the remote machine. Use inline with the exact echo command.

Practice

(1/5)
1. What is the main purpose of a connection block in Terraform when using SSH?
easy
A. To specify the Terraform backend storage
B. To define how Terraform connects to remote machines for running commands or copying files
C. To configure the cloud provider credentials
D. To create a new SSH key pair automatically

Solution

  1. Step 1: Understand the role of connection blocks

    Connection blocks specify how Terraform connects to remote machines, typically using SSH, to run commands or transfer files during provisioning.
  2. Step 2: Differentiate from other configurations

    SSH key creation, cloud credentials, and backend storage are configured elsewhere, not in connection blocks.
  3. Final Answer:

    To define how Terraform connects to remote machines for running commands or copying files -> Option B
  4. Quick Check:

    Connection block purpose = Define SSH connection [OK]
Hint: Connection blocks set SSH details for remote commands [OK]
Common Mistakes:
  • Confusing connection block with SSH key creation
  • Mixing connection block with cloud provider config
  • Thinking connection block manages backend storage
2. Which of the following is the correct syntax to specify an SSH connection block in Terraform?
easy
A. connection { type = "winrm" user = "ubuntu" host = self.public_ip private_key = file("~/.ssh/id_rsa") }
B. connection { protocol = "ssh" username = "ubuntu" address = self.public_ip key = file("~/.ssh/id_rsa") }
C. connection { ssh_user = "ubuntu" ssh_host = self.public_ip ssh_key = file("~/.ssh/id_rsa") }
D. connection { user = "ubuntu" host = self.public_ip private_key = file("~/.ssh/id_rsa") }

Solution

  1. Step 1: Recall Terraform connection block syntax

    The correct keys are user, host, and private_key. The type key is not required for SSH as it is the default.
  2. Step 2: Identify the valid syntax

    connection { user = "ubuntu" host = self.public_ip private_key = file("~/.ssh/id_rsa") } uses correct keys without unnecessary or incorrect ones like type or protocol.
  3. Final Answer:

    connection { user = "ubuntu" host = self.public_ip private_key = file("~/.ssh/id_rsa") } -> Option D
  4. Quick Check:

    Correct keys = user, host, private_key [OK]
Hint: Use user, host, private_key keys in connection block [OK]
Common Mistakes:
  • Adding unnecessary 'type' or 'protocol' keys
  • Using wrong key names like ssh_user or username
  • Omitting required keys like user or host
3. Given this Terraform snippet, what will happen when Terraform tries to connect?
connection {
  user = "admin"
  host = aws_instance.example.public_ip
  private_key = file("~/.ssh/id_rsa")
  timeout = "2m"
}
medium
A. Terraform will connect but ignore the timeout setting
B. Terraform will fail because timeout must be a number, not a string
C. Terraform will connect using SSH as user 'admin' with a 2-minute timeout
D. Terraform will connect using default user instead of 'admin'

Solution

  1. Step 1: Analyze connection block fields

    The block correctly sets user, host, private_key, and timeout. Timeout accepts a duration string like "2m".
  2. Step 2: Understand Terraform SSH connection behavior

    Terraform uses these values to connect via SSH as user 'admin' with a 2-minute timeout for connection attempts.
  3. Final Answer:

    Terraform will connect using SSH as user 'admin' with a 2-minute timeout -> Option C
  4. Quick Check:

    Timeout string '2m' is valid duration [OK]
Hint: Timeout accepts duration strings like '2m' for SSH connections [OK]
Common Mistakes:
  • Thinking timeout must be numeric only
  • Assuming default user is used ignoring 'user' key
  • Believing timeout is ignored by Terraform
4. Identify the error in this Terraform connection block:
connection {
  user = "ec2-user"
  host = aws_instance.web.public_ip
  private_key = "~/.ssh/id_rsa"
}
medium
A. private_key should use file() function to read the key content
B. host should be a static IP, not a resource attribute
C. user must be 'ubuntu' for AWS instances
D. Missing 'type = "ssh"' in connection block

Solution

  1. Step 1: Check private_key value type

    The private_key must contain the actual key content, not just the file path string. Using file("~/.ssh/id_rsa") reads the key content.
  2. Step 2: Validate other fields

    Host can be a resource attribute, user can be 'ec2-user' for Amazon Linux, and 'type' defaults to SSH so it's optional.
  3. Final Answer:

    private_key should use file() function to read the key content -> Option A
  4. Quick Check:

    private_key needs file() to read key [OK]
Hint: Use file() to load private_key content, not just path string [OK]
Common Mistakes:
  • Assigning private_key a file path string directly
  • Assuming host cannot be a resource attribute
  • Forcing user to 'ubuntu' regardless of OS
5. You want to run a remote command on an AWS instance using Terraform. Which connection block setup is best practice to ensure a reliable SSH connection?
hard
A. connection { user = "ec2-user" host = aws_instance.app.public_ip private_key = file("~/.ssh/id_rsa") timeout = "5m" agent = true }
B. connection { user = "ec2-user" host = aws_instance.app.public_ip private_key = file("~/.ssh/id_rsa") timeout = "1m" agent = false }
C. connection { user = "ec2-user" host = aws_instance.app.private_ip private_key = file("~/.ssh/id_rsa") timeout = "5m" agent = true }
D. connection { user = "ubuntu" host = aws_instance.app.public_ip private_key = file("~/.ssh/id_rsa") timeout = "30s" agent = false }

Solution

  1. Step 1: Choose correct user and host

    For AWS Amazon Linux, user is usually 'ec2-user'. Public IP is needed for SSH from outside the VPC.
  2. Step 2: Set appropriate timeout and agent

    A longer timeout like "5m" helps with slow connections. Using SSH agent forwarding (agent = true) can improve key management.
  3. Step 3: Compare options

    connection { user = "ec2-user" host = aws_instance.app.public_ip private_key = file("~/.ssh/id_rsa") timeout = "5m" agent = true } uses correct user, public IP, sufficient timeout, and enables agent forwarding, matching best practices.
  4. Final Answer:

    connection { user = "ec2-user" host = aws_instance.app.public_ip private_key = file("~/.ssh/id_rsa") timeout = "5m" agent = true } -> Option A
  5. Quick Check:

    Public IP, correct user, timeout 5m, agent true = best practice [OK]
Hint: Use public IP, correct user, 5m timeout, and agent true for reliability [OK]
Common Mistakes:
  • Using private IP when public IP is needed
  • Setting too short timeout causing failures
  • Disabling agent forwarding unnecessarily
  • Using wrong user for the OS
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard