If you do not understand how to combine Terraform with third-party tools like Ansible or Chef on AWS, you will end up manually clicking through the AWS console every time you need to update a server, wasting hours and risking human error. This chapter explains how to automate the whole process by using Terraform to create the cloud resources (servers, databases, networks) and then letting other tools configure the software inside those resources. For the DOP-C02 exam, you must know how to make these tools work together – the exam tests exactly this integration pattern.
Jump to a section
A simple way to picture Using Terraform and Third-Party IaC Tools on AWS
A dusty construction site in a residential neighbourhood. The homeowner wants a new conservatory, a smart heating system, and solar panels on the roof. But the original house plans are incomplete, and the architect has left the project.
The homeowner hires three specialists: a plumber, an electrician, and a solar installer. Each specialist speaks a different trade language – the plumber uses pipe schematics, the electrician uses wiring diagrams, and the solar installer uses power-flow charts. The homeowner needs a single master plan that describes the whole renovation in a way all trades can follow. This master plan is like Terraform. It is a tool that defines the entire desired house (your AWS infrastructure) in one set of blueprints (code).
But the trades each use their own tools to do the actual work. The plumber uses a wrench to fit pipes (like Ansible configures software on a server). The electrician uses a multimeter to check circuits (like Chef manages application settings). The solar installer uses a torque wrench to secure panels (like Puppet enforces system state). These third-party tools are the specialist’s own toolkits – they handle the detailed, device-level work.
The master plan (Terraform) tells each trade what to do and in what order: “First the plumber installs the pipe for the underfloor heating, then the electrician wires the thermostat, then the solar installer connects the power feed.” The trades then use their own specialised tools to execute their part. If the homeowner later decides to move a wall, they update the master plan, and Terraform recalculates the entire sequence, asking each trade to adjust their work without breaking what’s already built.
Imagine you are building a house. You need two things: the structure of the house (walls, roof, doors) and the interior decoration (paint, furniture, curtains). In cloud computing, these two tasks are handled by different tools. Terraform is the tool that builds the structure. Third-party configuration management tools like Ansible, Chef, or Puppet are the decorators that set up the software inside the servers.
What is Infrastructure as Code (IaC)? Infrastructure as Code means writing code that describes your cloud resources (servers, networks, databases) just like you write code for a website. Instead of logging into the AWS console and clicking buttons to create a server, you write a text file. When you run that file, AWS automatically creates the server exactly as you specified. This is faster, repeatable, and less error-prone than clicking. Terraform is one of the most popular IaC tools. It is not owned by AWS – it is a third-party tool (made by HashiCorp) that works with many cloud providers, including AWS, Azure, and Google Cloud.
What are third-party configuration management tools? Configuration management tools are used to install software, set up services, and enforce settings inside servers after those servers exist. - Ansible: Uses simple YAML files (playbooks) to describe what a server should look like – for example, “install Nginx, create a user, open port 80.” Ansible pushes the configuration to servers over SSH (a secure connection). - Chef: Uses Ruby-based cookbooks. It runs an agent (a small program) on each server that pulls configuration from a central server. - Puppet: Similar to Chef, uses a declarative language and an agent model to enforce desired state.
How do they work together on AWS? The typical pattern is: 1. Terraform creates the infrastructure: You write Terraform code that defines an AWS EC2 instance (a virtual server), including its size, the security group (firewall rules), and its IP address. Terraform also creates any other required resources like a load balancer or database. 2. Terraform calls the configuration management tool: After the server is created, Terraform can run a script that installs Ansible, Chef, or Puppet. It does this using a provisioner (a feature in Terraform that runs commands on a newly created server). The provisioner could be a simple shell script or it could directly invoke Ansible. 3. The third-party tool configures the server: Ansible takes over and installs the software, copies files, and restarts services.
Why not just use Terraform for everything? Terraform is excellent at building infrastructure (the house structure) but it is not designed to manage software inside a server (the interior decoration). Terraform creates the blank server. You need a different tool, like Ansible, that understands how to install and configure software packages. Trying to use Terraform alone would require writing messy scripts; the dedicated configuration tools are much more powerful and easier to maintain.
Key AWS services for integration: - AWS Systems Manager: You can use Systems Manager documents (run commands) instead of SSH keys to remotely execute scripts – often more secure. - EC2 Instance Connect: Another way to access instances securely. - AWS CodeDeploy, CodePipeline: If you are using Ansible inside a CI/CD pipeline, these services help orchestrate the deployment.
The “Immutable Infrastructure” pattern: In modern setups, many engineers prefer not to configure servers after creation. Instead, they create a pre-built machine image (Amazon Machine Image – AMI) with all software pre-installed. Terraform then simply deploys that image. This is called immutable infrastructure (you never change a running server; you replace it with a new one). However, the DOP-C02 exam still tests the mutable approach (build server, then configure it) because many legacy systems use it.
How the tools talk to AWS: Terraform uses the AWS API (an application programming interface – a set of commands that allows software to talk to AWS). When you run terraform apply, Terraform sends HTTP requests to AWS endpoints to create resources. Ansible also communicates with AWS API to gather information (like fetching a list of servers) but it mainly uses SSH or WinRM to connect directly to the servers.
State management: Terraform keeps a state file (a JSON file) that records what resources it created. This file is crucial for Terraform to know what exists and what needs updating. You should store this state file remotely (e.g., in an S3 bucket) so you do not lose it. Configuration management tools like Ansible do not keep a central state file – they query the current state of the server at runtime.
Common exam scenario: You might be asked to design a solution where Terraform creates an EC2 instance, and then an Ansible playbook installs a web server and updates the server’s configuration. The exam will test whether you know the correct order: infrastructure first, then configuration. It will also test that you understand the limitations – Terraform provisioners are a last resort (HashiCorp officially discourages using them for complex logic, recommending that you use separate configuration management tools instead).
Write Terraform configuration code
You create a .tf file that defines the AWS resources you need – for example, an EC2 instance, a security group, and an S3 bucket. This code is declarative: you specify the desired end state, not the steps to get there.
Run terraform init and terraform plan
You run `terraform init` to download the provider plugins and set up the backend for state storage. Then `terraform plan` shows you what changes Terraform will make before actually applying them – like a preview.
Run terraform apply to create infrastructure
You run `terraform apply` to execute the plan. Terraform calls the AWS API to create the EC2 instance, security group, and other resources. This step outputs public IP addresses and other details needed for the next step.
Trigger the third-party configuration tool via a provisioner or separate process
After the server is created, you can use a Terraform provisioner (like `remote-exec` or `local-exec`) to run an Ansible playbook. Alternatively, you can use AWS Systems Manager to run the playbook without SSH. The configuration tool then connects to the server and installs software.
Verify the configuration and test the application
The configuration tool reports success or failure. You then test the application by accessing the public endpoint of the server. If something fails, you inspect the logs from Ansible or the server's system log.
Store and lock the Terraform state file
After the apply completes, Terraform updates its state file with the new resource IDs. This state file must be stored in a remote location like S3 (Amazon Simple Storage Service) with DynamoDB locking to prevent conflicts when multiple team members run Terraform.
A typical infrastructure engineer at a mid-sized e-commerce company needs to deploy a new customer-facing application. The application requires a web server (Nginx), a Node.js runtime, and a connection to a MySQL database. The company already uses Terraform to manage all its AWS resources and Ansible to configure its servers.
Step-by-step walkthrough:
1. The engineer writes a new Terraform configuration file (called main.tf) that defines a new EC2 instance. The file specifies the Amazon Machine Image (AMI) – a base Linux image – the instance type (t3.medium), security group rules (allow HTTP and HTTPS traffic from the internet), and tags (e.g., Name: web-app).
2. The engineer also writes a Terraform resource for a security group rule that allows the new server to connect to the existing MySQL database (by creating a rule that accepts traffic from the security group of the EC2 instance).
3. The engineer writes an Ansible playbook called configure_web.yml. This playbook uses YAML to describe tasks:
- Install Nginx.
- Copy a custom configuration file for Nginx.
- Install Node.js using the package manager.
- Clone the application code from a private GitHub repository.
- Start the Node.js application.
4. In the Terraform code, the engineer adds a provisioner block to run the Ansible playbook after the EC2 instance is created. This is done by using the remote-exec provisioner which runs a command on the new server: ansible-playbook -i localhost, configure_web.yml.
5. The engineer runs terraform plan to preview the changes, then terraform apply. AWS creates the EC2 instance. Once the instance is running, Terraform’s provisioner connects to it via SSH (using the key pair the engineer specified) and executes the command that runs Ansible.
6. Ansible connects to the local server (the instance itself) and runs through the playbook tasks. It installs Nginx, copies files, installs Node.js, and starts the application.
7. The engineer tests the application by visiting the public DNS of the EC2 instance in a browser. The web page loads successfully.
8. Later, the company decides to scale the application. The engineer updates the Terraform code to use an Auto Scaling group (a group of identical EC2 instances that can grow or shrink automatically) and a load balancer. The Ansible playbook remains the same – Terraform triggers it on each new instance that launches.
Common real-world tools used: - HashiCorp Packer: Used to create pre-baked AMIs with all software installed, reducing the need for post-creation configuration. - AWS CodeBuild: Can run Terraform and Ansible as part of a CI/CD pipeline to automatically deploy changes when new code is pushed to GitHub. - Terraform Cloud: A managed service for running Terraform remotely, storing state, and integrating with other tools.
Why professionals prefer this integration: Manual configuration is slow and error-prone. If you have 50 servers, you cannot SSH into each one and type commands. Automating with Terraform and Ansible means you can rebuild your entire infrastructure (from scratch) in minutes. It also ensures every server is identical – no configuration drift (where servers gradually become different from each other over time).
The DOP-C02 exam tests your ability to design and integrate third-party IaC tools with AWS. You will not be asked to write Terraform code from memory, but you must understand the architecture and the limitations.
Key exam topics: - Terraform Provisioners: The exam loves to test when to use provisioners and when not to. The correct answer is: use them only for simple setup tasks (like running a shell script to install a monitoring agent) – do not use them for complex configuration management. Instead, use dedicated tools like Ansible, Chef, or Puppet. - State management: You must know that Terraform stores state locally by default, but for team use it should be stored remotely (e.g., S3 with DynamoDB locking). The exam may present a scenario where an engineer cannot apply changes because another team member is locking the state file – the solution is S3 + DynamoDB. - Configuration management vs. Infrastructure provisioning: The exam expects you to distinguish between tools that provision infrastructure (Terraform, CloudFormation) and tools that configure software (Ansible, Chef, Puppet). A question might describe a task like “install Apache on an EC2 instance” and you must choose the appropriate tool – it will be Ansible, not Terraform. - AWS Systems Manager integration: The exam may ask how to execute configuration management without opening SSH ports. The answer is to use AWS Systems Manager Run Command or Session Manager, which works through the AWS API without needing SSH keys. - Immutable vs. mutable infrastructure: You must know the advantages of immutable (using Packer to build AMIs, then deploying with Terraform) over mutable (Terraform + Ansible). The exam may favour immutable for security and reliability. - Third-party tools supported by AWS: AWS provides some official integrations (e.g., AWS Service Catalog with Terraform, using Terraform on AWS CodeBuild). Questions might test which AWS services can orchestrate third-party IaC execution – the answer is CodePipeline, CodeBuild, and Systems Manager.
Trap patterns to watch for:
The question describes a need to “configure a server’s operating system settings” and offers both Terraform and Ansible as options. Novices often pick Terraform because it is the default IaC tool in the example. The correct answer is Ansible.
The question says “avoid using SSH keys for security reasons” – many candidates think of Bastion hosts. The correct answer is Systems Manager Session Manager, which does not require SSH.
The question mentions “distributed team wanting to run Terraform” – the trap is to suggest storing state files in a shared network drive. The correct answer is S3 with DynamoDB for locking.
The question says “short-lived application that runs once every hour using Terraform” – candidates might suggest creating a long-running EC2 instance. The correct answer is use AWS Lambda to run Terraform as code (using the Terraform AWS provider).
Definitions to memorise: - Terraform: An IaC tool that creates and manages cloud resources declaratively. - Provisioner: A block in Terraform that runs scripts or commands on a resource after creation. - Configuration Management: Tools that install and manage software on existing servers (e.g., Ansible). - State File: A file recording the current state of resources managed by Terraform. - Immutable Infrastructure: The practice of replacing servers rather than updating them in place.
How the exam presents the topic: Expect scenario-based multiple-choice questions with three correct approaches and one wrong one. You must eliminate the approach that violates best practices (e.g., using Terraform to run complex Ansible logic inside a provisioner, or not locking the state file). You may also see a matching question where you pair tools with their correct use case – for example, match Terraform to provisioning resources, and match Ansible to configuring them.
Terraform provisions AWS infrastructure (servers, networks); Ansible configures software on those servers – they are complementary, not interchangeable.
Use Terraform provisioners only as a last resort; always prefer dedicated configuration management tools for installing and managing software.
Terraform stores state files that track created resources; always store state remotely in S3 with DynamoDB locking for team collaboration.
AWS Systems Manager Session Manager can replace SSH for secure, keyless remote execution of configuration management scripts.
Immutable infrastructure (creating pre-baked AMIs with Packer) is often preferred over mutable (provisioners) for security and reliability in production.
The DOP-C02 exam expects you to sequence correctly: create infrastructure with Terraform first, then configure software with third-party tools like Ansible.
Third-party IaC tools like Terraform are fully supported on AWS and can be orchestrated via CodePipeline, CodeBuild, and Systems Manager.
Terraform itself is a third-party tool – it is not owned by AWS, and it works with multiple cloud providers, which the exam views as a strength.
These come up on the exam all the time. Here's how to tell them apart.
Terraform
Provisions infrastructure: servers, networks, databases.
Declarative: you describe the desired end state.
Requires state file to track resources.
Ansible
Configures software inside existing servers.
Procedural/playbooks: you describe tasks to execute.
No central state; queries server at runtime.
Terraform Provisioners
Simple command execution on a resource after creation.
Not idempotent: re-running can cause errors.
Only useful for small, one-off setup tasks.
Dedicated Configuration Management (e.g., Ansible)
Full configuration automation: installs, configures, restarts services.
Idempotent: safe to run multiple times.
Rich ecosystem of modules and version control.
Immutable Infrastructure (Packer + Terraform)
Pre-baked AMI contains all software and configurations.
Faster to deploy: no runtime configuration.
Easier to roll back: deploy an older AMI.
Mutable Infrastructure (Terraform + Ansible)
Base AMI is generic; software installed after boot.
Slower to deploy due to runtime tasks.
Configuration drift possible over time.
Mistake
Terraform and Ansible do the same thing – you can use either for both creating servers and installing software.
Correct
Terraform is designed to provision infrastructure (servers, networks, databases) while Ansible is designed to configure the software inside those servers. They complement each other but are not interchangeable for primary use cases.
Beginners often see both tools used in YAML-like languages and assume the overlap is complete, not realising their strengths and purposes are distinct.
Mistake
Terraform provisioners are the best and recommended way to install software on servers.
Correct
HashiCorp, the maker of Terraform, explicitly states that provisioners should be a last resort. They are not idempotent (re-running them may cause errors) and are difficult to debug. Dedicated configuration management tools like Ansible are far better.
New learners see provisioners as the direct way to run commands and think they are the intended pattern, not knowing that the tool makers advise against using them heavily.
Mistake
You cannot use third-party configuration management tools like Ansible with AWS – you must use AWS-native tools like OpsWorks or CodeDeploy.
Correct
AWS fully supports third-party tools. You can run Ansible, Chef, and Puppet on EC2 instances just as you would on physical servers. AWS even provides official documentation and Quick Start templates for integrating them.
Beginners often think AWS requires its own proprietary tools exclusively, due to marketing and the prevalence of AWS-specific services in exam guides.
Mistake
When using Terraform and Ansible together, you should run Ansible first to configure the server, then Terraform to create the infrastructure around it.
Correct
The correct order is always: Terraform creates the infrastructure first, then Ansible configures the software on the already-running server. You cannot configure a server that does not exist.
The mental model of 'configuration first, then infrastructure' comes from traditional IT where servers already exist and you install software on them, but in the cloud you build the server first.
Mistake
Terraform state files are optional; you can skip them if you don't want to manage them.
Correct
State files are essential for Terraform to function correctly. Without them, Terraform cannot track what it has created, and subsequent runs will fail or recreate resources. You must manage them (store remotely, lock for concurrency).
Beginners skip over state as an esoteric detail, but it is a core requirement – failing to manage state is a common exam trap.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, you must have a server (or other infrastructure) running before you can configure it with Ansible. Terraform creates the server first, then Ansible configures it. You could run Ansible against an existing server, but Terraform's provisioning step still requires the server to exist.
Yes, Terraform itself is open-source and free. You only pay for the AWS resources it creates (like EC2 instances, S3 buckets) and any Terraform Cloud costs if you use the managed service. There is no additional AWS licensing fee for Terraform.
No, you typically run Ansible from a central control machine (like your laptop or a build server). The control machine connects to the EC2 instances using SSH or WinRM. You do need Python on the target instances (which is included by default in most Linux distributions).
A provisioner is a simple command that runs inside Terraform. It is not idempotent (running it multiple times may cause errors). An Ansible playbook is a robust, idempotent script that checks the current state and makes only necessary changes. Playbooks are the professional way to configure servers.
Yes, you can run Terraform as part of a CodePipeline. You can use AWS CodeBuild to execute `terraform apply` as a build step. This automates the entire workflow: when you push code to GitHub, CodePipeline triggers CodeBuild, which runs Terraform to create infrastructure, then runs Ansible to configure it.
Losing your state file means Terraform does not know which resources it owns. Running `terraform apply` may try to create duplicates, or you may have to manually import existing resources into a new state file. Always store the state file remotely and back it up.
You've finished Using Terraform and Third-Party IaC Tools on AWS. Continue through the DOP-C02 study guide to build a complete picture of the exam.
Done with this chapter?