How do you make sure a complex network with hundreds of routers, firewalls, and switches never breaks because someone accidentally clicked the wrong button? That is the problem Infrastructure as Code (IaC) solves: it treats your entire network setup as a set of text files that can be reviewed, tested, and deployed automatically, eliminating the human errors that plague manual configuration. For the ANS-C01 exam, you need to understand how to automate network operations using AWS CloudFormation, Terraform, and the AWS SDKs — and more importantly, why these tools are essential for building reliable, repeatable, and secure networks at scale.
Jump to a section
A simple way to picture Automating Network Operations with Infrastructure as Code
Have you ever watched someone build a garden shed in their back garden, only to realise later they forgot to leave space for the door to open fully? That frustration of fixing a mistake after the concrete is poured is exactly what Infrastructure as Code (IaC) eliminates for network engineers.
Imagine you want to build a small house extension. The old way would be to hire a builder who shows up with a hammer and starts framing walls based on a rough sketch on a napkin. Every wall, every window, every electrical socket is built by hand, by memory. If the builder makes a mistake — say, puts a load-bearing wall where the sliding doors should go — you only discover it when the roof starts sagging. To fix it, you tear down the wall, rebuild it, and hope the next bit of the structure doesn't collapse. This is how network engineers used to configure routers and firewalls: they logged into each device one by one and typed commands. One wrong command could bring the whole network down, and nobody had a complete blueprint of what was actually running.
Now imagine the same extension, but this time you write a detailed digital blueprint before any wood is cut. That blueprint specifies exactly where every stud goes, what type of insulation goes in each cavity, and which way the door swings. You give this blueprint to a machine that reads it and builds the entire extension without a single human swinging a hammer. If you want to change the window size, you edit the blueprint and the machine rebuilds the wall perfectly. That is Infrastructure as Code. You write a text file — your "blueprint" — that describes every network component (virtual private clouds, subnets, route tables, security groups) in a programming language like JSON or YAML. Tools like AWS CloudFormation or Terraform read that file and create, update, or delete all the resources automatically. No manual clicks, no forgotten steps, no midnight panics because someone typed "allow all" instead of "deny all".
The real magic is version control. Just like you keep old versions of your house blueprint in a folder, IaC lets you store your network configuration in a system like Git. You can see who changed what, when, and why. If a change breaks the network, you can instantly roll back to yesterday's working blueprint. This is the difference between a builder working from memory and a builder working from a checked-in, tested, and approved architectural plan.
Infrastructure as Code (IaC) is the practice of managing and provisioning computing infrastructure — including networks, servers, and storage — through machine-readable definition files, rather than through manual processes or interactive configuration tools. The core idea is simple: you write a text file that describes what your network should look like, and a tool makes that network a reality. This replaces the old method where an engineer would log into each device using a terminal (a text-based interface) and type commands one by one.
Let's break down the key components. A CloudFormation template is a JSON or YAML file that declares every AWS resource you want. For example, you might declare a Virtual Private Cloud (VPC), which is your private section of the AWS cloud. Inside that VPC, you declare subnets (smaller segments of the VPC), an Internet Gateway (a door to the internet), route tables (signs directing traffic), and security groups (a list of rules that act like a bouncer at a club, deciding what traffic is allowed in and out). You write all of this in a single file, and when you "run" the template, CloudFormation creates everything in the correct order — it knows it must create the VPC before the subnets, and the subnets before the security groups. If something fails, CloudFormation automatically rolls back all changes, leaving your network exactly as it was before.
Terraform is similar but works across multiple cloud providers, not just AWS. It uses its own language called HashiCorp Configuration Language (HCL). While CloudFormation is AWS-native (tightly integrated with other AWS services), Terraform is provider-agnostic, meaning you can use the same tool to manage resources on AWS, Google Cloud, and Azure. For the ANS-C01 exam, you need to know both tools exist, but focus on CloudFormation because the exam is AWS-specific.
Why does this matter for network automation? Consider a typical manual task: adding a new subnet to a VPC. In the old way, you log into the AWS Management Console (a web interface), navigate several menus, click "Create subnet", fill in a form, and click "Save". That takes two minutes. But when you need to add ten subnets across five different VPCs, the manual approach becomes error-prone — you might forget to update a route table or mis-type a CIDR block (the IP address range assigned to a subnet). With IaC, you edit one line in a CloudFormation template, run the template, and all ten subnets appear, complete with correct route tables and security groups. The machine never gets distracted or tired.
There are three main models of IaC: declarative and imperative. Declarative means you say what you want the final state to be — for example, "I want a VPC with two subnets" — and the tool figures out how to get there. Both CloudFormation and Terraform are declarative. Imperative means you write step-by-step instructions for how to create the resources — "first create the VPC, then create subnet A, then attach it to the route table". The exam tests declarative IaC overwhelmingly.
The AWS SDKs (Software Development Kits) are another way to automate network operations. SDKs are libraries that let you write code in programming languages like Python, JavaScript, or Java to directly call AWS API (Application Programming Interface) operations. For example, you could write a Python script using the boto3 library (the AWS SDK for Python) that programmatically creates a VPC, then attaches an Internet Gateway, then launches an EC2 instance (a virtual server) inside that VPC. This is more flexible than CloudFormation because you can add logic — for instance, "if the VPC is in the us-east-1 region, use this CIDR block; otherwise use this other CIDR block." However, it requires programming knowledge and is more complex to maintain.
The key exam concept is "desired state management." With CloudFormation and Terraform, you define the desired end state of your network in a template. The tool compares the current state (what actually exists) with the desired state (what your template says) and makes changes to reconcile them. If someone manually deletes a subnet, the tool will recreate it when you run the template again. This self-healing property is one of the biggest advantages of IaC.
Define the Network Requirements
Before writing any code, identify what your network needs: how many VPCs, what IP ranges (CIDR blocks), how many subnets (public and private), and what security rules (e.g., allow HTTP from the internet, allow SSH only from a specific management IP). Write these down as a requirements document.
Write the CloudFormation Template in YAML or JSON
Create a text file that declares each resource: a VPC resource, subnet resources, an Internet Gateway, route tables, and security groups. Use parameters for variable values (like VPC CIDR) so the template is reusable. Define dependencies between resources where CloudFormation cannot infer them automatically.
Validate the Template
Use the AWS CloudFormation console or the CLI command `aws cloudformation validate-template` to check for syntax errors and missing required properties. The validation step catches typos and structural issues before you attempt to create the stack.
Create a Change Set (Optional but Recommended)
Run `aws cloudformation create-change-set` to generate a preview of what resources will be created, modified, or deleted. Review the change set to confirm that the VPC CIDR range is correct and that no existing resources will be accidentally replaced. This is especially important when updating an existing stack.
Execute the Stack Creation or Update
Run the CloudFormation stack (via the console, CLI, or API). CloudFormation provisions resources in the correct order, creating the VPC first, then subnets, then gateways, then security groups. Monitor the stack events in the console to see each resource's creation status. If a resource fails (e.g., you hit a VPC limit), CloudFormation rolls back all resources.
Verify the Network Configuration
After the stack is in the CREATE_COMPLETE or UPDATE_COMPLETE state, log into the AWS console and manually verify that the subnets are correctly associated with route tables, that the Internet Gateway is attached, and that security group rules are as expected. Use the AWS CLI to run commands like `aws ec2 describe-subnets` to confirm.
Store the Template in Version Control and Document
Commit the template to a Git repository with a clear commit message describing the network change. Add a README explaining what the template does, what parameters are required, and how to deploy it. This ensures the network configuration is auditable and can be recreated by any team member.
Imagine you work as a network engineer for a medium-sized company called "GadgetCo" that sells smart home devices. GadgetCo runs its entire e-commerce website on AWS. You have a production environment (where the live website runs) and a development environment (where developers test new features). Currently, both environments were set up manually by a previous engineer who left no documentation. The network consists of:
A VPC with the IP range 10.0.0.0/16.
A public subnet (accessible from the internet) for the web servers.
A private subnet (not accessible from the internet) for the database servers.
A NAT Gateway (allows private instances to access the internet for updates).
Security groups that control traffic between the web and database tiers.
One Monday morning, the CEO announces that GadgetCo is launching a new product line next week, which will triple the website traffic. The development team needs a clone of the production network — identical subnets, routing, and security — to test the new features. The old way would require you to spend three days manually clicking through the AWS console, trying to remember every setting from the original setup. You would probably miss something, like allowing traffic on port 3306 (MySQL) from the web servers to the database servers. A mistake there would cause the test site to crash, and you would spend hours debugging.
With IaC, you proceed like this:
Step 1: You locate the CloudFormation template that was originally used to create the production network. If the previous engineer didn't create one, you can use a tool called "AWS CloudFormer" or manually create a template by inspecting the existing resources using the AWS CLI (Command Line Interface), a text-based tool for interacting with AWS.
Step 2: You copy the template and edit the parameters. You change the CIDR block from 10.0.0.0/16 to 10.1.0.0/16 (a different IP range so they don't conflict) and rename the resources to "DevVPC" instead of "ProdVPC".
Step 3: You run the CloudFormation stack creation. The tool creates the entire development network — VPC, subnets, Internet Gateway, route tables, security groups — in about five minutes. Every resource is configured identically to production, but with the new IP range.
Step 4: You test the setup by launching a test web server and database server in the new VPC. Because the security groups are exact copies of production, the test application works immediately.
Step 5: You store the template in a Git repository (a version control system). Next month, when someone needs a staging environment for a different project, you — or anyone on the team — can create it in minutes by editing a few variables in the template. No tribal knowledge required.
This is the reality of IaC in the workplace. Network engineers spend less time clicking and more time designing templates, reviewing peer changes through pull requests (code reviews), and writing automated tests that verify the network will work before it is deployed. The AWS Certified Advanced Networking Specialty exam expects you to know how to use CloudFormation to automate network tasks such as creating VPN connections, configuring Direct Connect (a dedicated private link from your data centre to AWS), and setting up transit gateways (central hubs that connect multiple VPCs).
The ANS-C01 exam tests your ability to automate network operations using CloudFormation, Terraform, and AWS SDKs in specific, practical scenarios. You will not be asked to write a full CloudFormation template from scratch — you will need to read and interpret partial templates, identify errors, and choose the correct automation approach for a given requirement.
Here are the exact concepts the exam loves to test:
Resource dependencies: CloudFormation automatically determines the order in which resources are created based on the Ref and DependsOn attributes. The exam frequently presents a template where resources are defined in the wrong order (e.g., a subnet before the VPC) and asks you to fix it. Remember that CloudFormation uses implicit dependencies (if one resource references another via Ref, it creates the referenced resource first) and explicit dependencies (using DependsOn). The trap is that sometimes resources do not have an obvious dependency, but they need one — for example, an InternetGatewayAttachment must explicitly depend on the Internet Gateway and the VPC, even if no Ref is used.
Stack updates and drift detection: The exam tests what happens when you update a CloudFormation stack. A common trap question: "You update a security group rule in a CloudFormation template but the change does not apply. What is the likely cause?" The answer is usually that you changed the property of an existing resource in a way that requires a replacement (physical ID changes), but you performed a stack update that only modifies the resource, not recreates it. You need to understand the difference between "update with no interruption", "update with some interruption", and "replacement". For network resources like VPCs and subnets, many changes require replacement — you cannot change the CIDR block of an existing VPC, so CloudFormation must destroy and recreate it.
Nested stacks and cross-stack references: The exam tests how to reuse common network patterns. A nested stack is a CloudFormation template that is launched inside another template (like a parent-child relationship). The exam will ask: "How do you share a VPC ID from a network stack to an application stack?" The answer is to use CloudFormation outputs and the Fn::ImportValue function. The trap is using hard-coded values or SSM Parameter Store, which works but is not the CloudFormation-native way that the exam considers "best practice".
Atomics vs. batch updates: Terraform uses a different state management model than CloudFormation. The exam may contrast how CloudFormation uses a "stack" concept (a collection of resources managed as a single unit) versus how Terraform uses a "state file" (a local or remote file that tracks the current real-world resources). A common question: "What happens if a CloudFormation stack creation fails?" The answer is that CloudFormation rolls back all successfully created resources by default (unless you disable rollback on failure). For Terraform, the equivalent is that Terraform leaves the created resources in place — you must manually run terraform destroy or use a different workflow.
AWS SDKs for automation: The exam tests scenarios where you need to automate network tasks that are not easily described in CloudFormation — for example, dynamically adjusting route tables based on the number of running EC2 instances. The correct approach is to write a Lambda function (a serverless compute service) using the AWS SDK, triggered by a CloudWatch event (a monitoring service). The exam loves to ask: "Which service should you use to run code in response to a VPC peering connection request?" The answer is AWS Lambda with the SDK, not CloudFormation.
Policy-as-code: Service Control Policies (SCPs) and IAM policies are not strictly IaC for networks, but the exam tests how you can use CloudFormation to enforce network security rules. For example, you might create a CloudFormation template that deploys a VPC with mandatory encryption and logging, and then use an SCP to prevent anyone from disabling those features. The exam question might ask: "How do you ensure that all VPCs created in an AWS account have flow logs enabled?" The answer is to use a CloudFormation StackSet (a tool that deploys templates across multiple accounts and regions) with a service-linked role.
Finally, memorise the following key facts:
CloudFormation uses JSON or YAML templates.
Terraform uses HCL (HashiCorp Configuration Language).
The maximum size of a CloudFormation template is 1 MB.
CloudFormation supports change sets, which let you preview changes before applying them.
AWS CloudFormation is the only IaC tool that natively integrates with AWS services like Lambda-backed custom resources.
CloudFormation and Terraform are declarative IaC tools: you define the desired end state, and the tool handles the steps to reach it.
Resource dependencies in CloudFormation can be implicit (via Ref) or explicit (via DependsOn) — the exam tests both.
When a CloudFormation stack creation fails, it rolls back automatically by default, removing all resources it created during the failed attempt.
Terraform uses a state file to track real-world resources, while CloudFormation uses a stack concept managed by the AWS API.
The AWS SDKs let you write code (e.g., Python with boto3) to automate network tasks that require conditional logic, such as adjusting route tables based on load.
Nested stacks in CloudFormation let you reuse common network patterns (e.g., a base VPC) across multiple application stacks using cross-stack references with Fn::ImportValue.
Change sets in CloudFormation allow you to preview the effect of a template update before applying it, reducing the risk of unintended changes.
You can use CloudFormation StackSets to deploy a network template across multiple AWS accounts and regions simultaneously, enforcing a consistent network baseline.
These come up on the exam all the time. Here's how to tell them apart.
CloudFormation
AWS-native service, tightly integrated with AWS APIs and services like CloudTrail.
Uses JSON or YAML templates; managed as a 'stack' with automatic rollback on failure.
Supports cross-stack references using Fn::ImportValue and nested stacks.
Does not support multiple cloud providers natively.
Terraform
Third-party tool, supports AWS, Azure, Google Cloud, and many others.
Uses HCL (HashiCorp Configuration Language); manages resources via a state file.
Uses Terraform modules and remote state for sharing configurations.
Multi-cloud by design; same language for all providers.
Imperative IaC
You write step-by-step instructions for how to create each resource.
The tool follows your exact sequence; you must handle dependencies manually.
Examples include AWS CLI scripts or SDK code that calls APIs in order.
More flexible but harder to maintain and audit for large networks.
Declarative IaC
You define the desired end state (e.g., 'I want a VPC with subnets X and Y').
The tool determines the order of operations and handles dependencies automatically.
Examples include CloudFormation templates and Terraform configurations.
Easier to maintain, review, and version-control; the exam focuses on this approach.
CloudFormation Stack Update
Modifies existing resources in place where possible (e.g., updating a security group rule).
Can cause rolling replacement for resources that cannot be updated (e.g., changing a VPC CIDR).
Preserves the logical resource IDs (physical IDs may change for replaced resources).
CloudFormation Stack Recreation
Deletes the entire stack and creates a new one from the same or updated template.
All resources get new physical IDs, which may break dependencies in other stacks.
Used when the update requires extensive changes that are safer to rebuild entirely.
Mistake
Infrastructure as Code means you write code to replace the AWS Management Console entirely, so you never need to look at the console again.
Correct
IaC automates the creation and management of infrastructure, but the console is still used for monitoring, troubleshooting, and one-off debugging. The goal is to reduce manual configuration, not eliminate the console entirely.
Beginners often assume that IaC makes the console obsolete, but in reality, both are used together — IaC for provisioning and changes, the console for read-only visibility and unexpected issues.
Mistake
CloudFormation and Terraform do the same thing, so you only need to learn one for the ANS-C01 exam.
Correct
The exam tests both tools because the question scenarios often specify which tool is already in use. CloudFormation is deeply integrated with AWS and is the native choice, while Terraform is used in multi-cloud environments. You need to know the differences in state management, syntax, and rollback behaviour.
Because the exam objectives explicitly name both tools, candidates sometimes focus only on CloudFormation and lose marks on Terraform-specific questions about state files and remote backends.
Mistake
If you write a CloudFormation template correctly, it will never fail when you run it.
Correct
CloudFormation can fail for many reasons beyond template errors: service limits (e.g., you hit the VPC limit per region), API rate limiting, or dependencies on resources in other accounts. The exam tests your knowledge of how to handle stack failures using rollback triggers and wait conditions.
New learners often think of templates as 'write once, run forever' scripts, but real-world cloud infrastructure has dynamic constraints (quotas, regional availability) that cause failures even with perfect syntax.
Mistake
Infrastructure as Code is only useful for large companies with hundreds of engineers.
Correct
IaC is valuable for any size of organisation because it provides a single source of truth for your network configuration, prevents configuration drift, and enables disaster recovery by recreating environments from templates. Even a solo developer running a single VPC benefits from being able to rebuild it in a different region in minutes.
This misconception arises because IaC tools are often marketed at enterprise scale, but the practical benefits — repeatability, documentation, and rollback — apply equally to small setups.
Mistake
CloudFormation templates and Terraform configurations are interchangeable — you can convert one to the other with a simple tool.
Correct
While there are third-party tools to convert between formats, they are unreliable because the underlying resource models differ. CloudFormation treats resources as a 'stack' with automatic rollback, while Terraform manages resources through a state file with a different reconciliation cycle. The exam expects you to recognise that conversion is not trivial and often requires manual re-architecture.
This misconception comes from the fact that both tools use declarative syntax and similar resource types, but the execution models and error handling are fundamentally different, leading to failed conversions.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CloudFormation is an AWS-native IaC service that uses JSON or YAML templates and manages resources as a 'stack' with automatic rollback. Terraform is a third-party tool from HashiCorp that uses HCL and works across multiple cloud providers, managing resources via a state file.
You need to understand what AWS SDKs can do (e.g., automate tasks using Lambda), but the exam does not require you to write code. You should be able to identify the correct SDK approach for a given scenario.
A change set is a preview of the changes that will be made when you update a stack. It shows which resources will be added, modified, or replaced, allowing you to review and approve changes before they are applied, reducing the risk of unintended modifications.
Yes, you can 'adopt' existing resources into a CloudFormation stack using the resource import feature. This allows you to manage resources that were created manually as part of an IaC workflow.
CloudFormation will create the new VPC first, then update the references to point to the new VPC, and then delete the old VPC. During this process, there may be a brief interruption to network connectivity. You can use change sets to see if replacement is required before applying.
Terraform is better for multi-cloud because it supports many providers (AWS, Azure, Google Cloud, etc.) with the same language and workflow. CloudFormation is AWS-only and tightly integrated with AWS services like CloudTrail and AWS Config.
You've finished Automating Network Operations with Infrastructure as Code. Continue through the ANS-C01 study guide to build a complete picture of the exam.
Done with this chapter?