Exam domain 5.2 of the Google Professional Cloud DevOps Engineer exam is about provisioning and managing infrastructure using Infrastructure as Code (IaC) tools like Deployment Manager and Terraform. These tools solve the problem of manual infrastructure setup, which is slow, error-prone, and impossible to scale. For someone studying the PCDOE, understanding these tools is essential because the exam will test your ability to choose the right tool, write declarative configuration files, and manage infrastructure changes safely.
Jump to a section
A simple way to picture Infrastructure as Code with Cloud Deployment Manager and Terraform
The architect draws the blueprint for a house. The blueprint shows every wall, window, door, and electrical outlet. The architect does not hammer a single nail. That is the job of the building contractor. The architect hands the blueprint to the contractor. The contractor reads the blueprint and builds exactly what the blueprint says. If the client wants a bigger kitchen, the architect changes the blueprint. The contractor then demolishes the old wall and builds the new one. The entire project is managed through that one central document, the blueprint. If the contractor loses the blueprint, the project stops. If the architect hands a blueprint with errors, the contractor builds a flawed house. Everything depends on that blueprint being accurate and complete.
Now replace the architect with a DevOps engineer. Replace the blueprint with a configuration file written in Terraform or Cloud Deployment Manager. Replace the contractor with Google Cloud's infrastructure engine. The engineer writes a configuration file that describes exactly what infrastructure they want: a virtual machine with certain memory, a network with certain rules, a storage bucket with a specific name. The engineer then tells the cloud provider 'build this'. The cloud provider reads the configuration file and builds exactly that infrastructure. If the engineer later changes the configuration file and re-runs the command, the cloud provider updates the infrastructure to match the new blueprint. That is Infrastructure as Code. You write code, not deploy manually. The code is the single source of truth. It is repeatable, auditable, and version-controlled, just like an architect's blueprint.
Infrastructure as Code, or IaC, is the practice of managing and provisioning your cloud infrastructure through machine-readable configuration files, rather than through manual processes or interactive configuration tools. In the past, an IT administrator would log into a cloud console, click around, and manually create virtual machines, networks, and databases. That worked for one server. It does not work for a thousand. Manual setup is slow, inconsistent, and you cannot easily recreate an exact copy of your environment if something goes wrong. IaC fixes that.
There are two main IaC tools that you need to know for the Google PCDOE exam: Cloud Deployment Manager and Terraform. Both serve the same purpose, but they differ in how they work and where they are best used.
Cloud Deployment Manager is Google Cloud's own IaC tool. It is tightly integrated with Google Cloud. You write configuration files in YAML (a human-readable data-serialisation language) or Python. The file describes the resources you want, for example compute instances, networks, firewall rules, and storage buckets. You then run a command like 'gcloud deployment-manager deployments create my-deployment --config my-config.yaml' and Google Cloud reads that file and creates all the resources. The key concept here is declarative. You declare the desired end state, and Cloud Deployment Manager figures out the steps to get there. You do not write step-by-step instructions like 'create a VM, then attach a disk, then configure networking'. You just say 'I want a VM with an attached disk in this network'. Deployment Manager takes care of the order of operations automatically.
Terraform is a popular open-source IaC tool created by HashiCorp. Unlike Deployment Manager, Terraform is cloud-agnostic. You can use the same tool to manage infrastructure on Google Cloud, Amazon Web Services, Microsoft Azure, and even on-premise systems. You write configuration files in a language called HashiCorp Configuration Language (HCL). Terraform works by comparing your configuration file against the current state of your infrastructure. This comparison is called a plan. When you run 'terraform plan', Terraform shows you what changes it will make before it makes them. Then you run 'terraform apply' to execute those changes. Terraform maintains a state file (often stored in a cloud storage bucket) that tracks what resources it manages. This state file is critical for Terraform to know what already exists and what needs to change.
Why do these tools matter for the exam and for a real DevOps engineer? They replace manual clicking in the cloud console. Manual clicking leads to mistakes. You might click the wrong button, forget to attach a disk, or create security holes. With IaC, your infrastructure is defined in code. That code can be reviewed by teammates, stored in version control like Git, and tested just like application code. If you discover a bug in your configuration (e.g., you accidentally exposed a database to the public internet), you fix the code, re-run the tool, and the entire infrastructure gets updated consistently. This is called idempotency. Idempotency means that no matter how many times you run the same configuration, you get the same result. If the resources already exist and match the configuration, nothing changes. If they do not match, the tool corrects them.
Both tools use the concept of a desired state. You describe the ideal end state of your infrastructure. The tool then makes the real infrastructure match that state. If someone accidentally deletes a VM, the next time you run Terraform apply or re-deploy your Deployment Manager configuration, the tool will recreate that VM to match the desired state. This self-healing property is powerful.
Now, let's talk about the types of resources you manage with IaC. On Google Cloud, you can manage virtually every resource: virtual machines (Compute Engine instances), networks (VPC networks), firewall rules, storage buckets (Cloud Storage), load balancers, databases (Cloud SQL), and even IAM policies (who can access what). For example, you might have a Terraform configuration like this: 'resource google_compute_instance my-vm { name = my-vm machine_type = e2-medium zone = us-central1-a boot_disk { initialize_params { image = debian-cloud/debian-11 } } network_interface { network = default } }'. This tells Terraform to create a VM named my-vm with 2 vCPUs and 4GB of RAM, running Debian 11, on the default network.
How do you get started? First, you install the tool (Terraform CLI or gcloud CLI for Deployment Manager). Then you write a configuration file. For Terraform, you also need to configure the provider. A provider is a plugin that lets Terraform talk to a specific cloud. For Google Cloud, you use the 'google' provider. You set up authentication (usually a service account key). Then you run 'terraform init' to download the provider plugin, 'terraform plan' to see the changes, and 'terraform apply' to create the resources. For Deployment Manager, you write the YAML file and run 'gcloud deployment-manager deployments create'.
One important concept to understand is infrastructure state drift. In a complex environment, someone might manually change a resource through the cloud console. For example, they might resize a VM manually. The next time you run Terraform, it will detect that the real state (the manually-resized VM) does not match the desired state in your configuration file (the original size). Terraform will propose a change to resize the VM back to the desired state. This can be surprising, so you must use IaC as the sole method of making changes. If you need to change something, you update the configuration file, not the console.
For the exam, you must know the difference between deployment manager and terraform. Deployment Manager is Google-specific and uses YAML or Python. Whenever you see a question about managing resources purely on Google Cloud and the answer options include both, the correct answer might be Deployment Manager when the context is about native integration with Google Cloud services like Cloud IAM, Cloud Audit Logs, or Cloud Orchestration. Terraform is the better choice when you need to manage multi-cloud infrastructure or when you need a more mature community ecosystem and a large registry of pre-built modules. The exam occasionally tests the concept of state locking: when multiple team members run Terraform at the same time, how do you prevent conflicts? The answer is to use a remote backend with state locking, such as Cloud Storage with object versioning and a state locking mechanism.
Write the Configuration File
You create a file (e.g., main.tf for Terraform or config.yaml for Deployment Manager) that describes the exact infrastructure you want. For a Google Compute Engine instance, you specify the machine type, boot disk image, zone, and network. This file is the blueprint for your infrastructure. It should be stored in Git for version control.
Initialise the IaC Environment
For Terraform, you run 'terraform init' to download the Google Cloud provider plugin. For Deployment Manager, you ensure the gcloud CLI is installed and authenticated. This step prepares the tool to communicate with Google Cloud. Without it, the tool does not know how to create resources.
Plan or Preview the Changes
For Terraform, you run 'terraform plan'. This compares your configuration against the current state of the infrastructure and shows you exactly what will be created, modified, or destroyed. For Deployment Manager, you use 'gcloud deployment-manager deployments create my-deployment --config my-config.yaml --preview'. This gives you a preview without making changes. This step is crucial for safety.
Apply the Configuration
For Terraform, you run 'terraform apply'. You may be prompted to confirm. For Deployment Manager, you run the same create command without the --preview flag, or you run 'gcloud deployment-manager deployments update' for existing deployments. This is the step where the tool actually creates or updates the cloud resources to match your desired state.
Verify and Document
After the apply, you verify in the Google Cloud console or using CLI commands that the resources exist and are configured correctly. You then commit the configuration file to your version control system with a meaningful commit message (e.g., 'Added Cloud SQL instance for user profiles'). This ensures an audit trail and makes it easy to roll back if needed.
Imagine you are the first DevOps engineer hired at a growing e-commerce company called 'ShopVerse'. The company started with one developer who manually set up everything in Google Cloud. Now they have five microservices, two databases, a Redis cache, and a load balancer. The original developer is about to go on holiday for two weeks. Any change to the infrastructure currently requires that developer to log in, click around, and remember what they did. The company is terrified that something will break while they are away.
Your first task is to bring Infrastructure as Code to ShopVerse. You decide to use Terraform because the company may later use Amazon Web Services for redundancy, and Terraform is cloud-agnostic. Here is what you do step by step.
You create a new Git repository called 'shopverse-infrastructure'. You create a directory structure with folders for each environment: 'dev', 'staging', 'production'. Inside each folder, you write Terraform configuration files. You start with the 'dev' environment because it is safe to experiment. You write a file called 'main.tf' that defines a virtual private cloud (VPC), a subnet, a firewall rule that allows traffic only on port 443, and a virtual machine running the web application. You also create a 'variables.tf' file where you define variables like the region and the machine type. This makes the configuration reusable. - You run 'terraform init' to download the Google Cloud provider. - You run 'terraform plan' to see what Terraform will create. It shows you that it will create a VPC, a subnet, a firewall rule, and a VM. - You show the plan to your team lead for review. They note that the firewall rule is too permissive. You update the configuration to restrict the source IP ranges to only the company's office IP. - You run 'terraform apply'. Terraform creates the infrastructure. You verify by logging into the Google Cloud console and seeing the resources exist.
Next, you migrate the production infrastructure. Here you must be careful. You cannot just run Terraform against existing resources without importing them. If you try to apply a configuration that describes a resource that already exists but is not tracked in Terraform's state file, Terraform will try to create a duplicate and fail. So you use 'terraform import' to bring the existing production resources into Terraform's state. For example, you run 'terraform import google_compute_instance.shopverse-website projects/shopverse-project/zones/us-central1-a/instances/shopverse-website-vm'. This tells Terraform 'this existing VM is now under my management'. After importing all resources, you run 'terraform plan' again. It shows no changes because the configuration matches the real state. Now the infrastructure is under IaC control.
A few weeks later, the development team asks for a new database for a feature. Instead of clicking around in the console, you add a few lines to your Terraform configuration file to define a Cloud SQL instance. You run 'terraform plan', review the changes, and apply. The database is created exactly as specified. The team now has a repeatable process.
Later, an audit reveals that one of the production VMs was accidentally deleted by a junior engineer who was experimenting in the console. You simply run 'terraform apply' on the production configuration. Terraform detects that the VM is missing from the real infrastructure but exists in its state file. It recreates the VM exactly as it was, with the same IP, same attached disk, and same configuration. The application is back online within minutes. The senior engineer is impressed.
For the PCDOE exam, the scenario you will likely face involves choosing between Deployment Manager and Terraform for a specific task. The exam might describe a scenario where the company already has a large investment in Terraform modules and a multi-cloud strategy. The correct answer will be to continue using Terraform. Alternatively, the exam might describe a scenario where the team is fully on Google Cloud and needs tight integration with other Google Cloud services like Deployment Manager's preview functionality or its ability to roll back a deployment. The correct answer there might be Deployment Manager. The exam loves to test your understanding of which tool is better for which context.
The PCDOE exam (domain 5.2) tests your ability to use Infrastructure as Code tools to provision and manage infrastructure. You will see 10-15% of the exam questions covering this area. The questions are not about memorising syntax. They are about knowing the concepts, the differences between the tools, and the best practises.
What specific concepts does the exam test? - The difference between declarative and imperative approaches. The exam will describe a scenario where an engineer writes step-by-step commands (imperative) versus describing the desired state (declarative). The correct answer will be declarative because IaC is declarative. - The concept of idempotency. A question might ask: 'What property of IaC ensures that running the same configuration multiple times produces the same result?' The answer: idempotency. - State management in Terraform. Questions will ask where to store the Terraform state file. The correct answer is a remote backend like Cloud Storage, not locally on a laptop, because you need team access and state locking. They might ask what happens if two team members run Terraform apply at the same time. The answer: state locking prevents conflicts and potential corruption. - The difference between Terraform and Cloud Deployment Manager. Key facts you must know: Deployment Manager is Google Cloud-native and uses YAML or Python. Terraform is cloud-agnostic and uses HCL. Deployment Manager supports previews (with the --preview flag) to show what will happen before making changes, similar to terraform plan. Deployment Manager does not have a state file like Terraform does; instead, it tracks resources as 'deployments'. - Resource dependencies. Both tools automatically determine the order of creation based on dependencies. For example, you cannot create a VM that uses a network until that network exists. The exam might test whether you need to specify the order manually. You do not; both tools handle that automatically. - The concept of 'drift' and how to detect and remediate it. The exam might present a situation where a security team notices that a firewall rule was changed outside of IaC. What should the DevOps engineer do? The correct answer is to re-apply the IaC configuration to bring it back to the desired state, then ensure that manual changes are prevented through IAM policies.
Typical question traps:
An answer option that suggests using the cloud console to make a one-off change. This is always wrong for an IaC-focused question. The exam wants you to update the configuration file.
An option that suggests using Terraform without a remote backend. The exam will penalise this because it is not a production-ready setup.
Confusing Deployment Manager's 'deployment' concept with Terraform's 'state' concept. Remember: Deployment Manager calls a collection of resources a deployment. Terraform uses a state file to track resources.
An option that suggests manually editing the Terraform state file. This is always wrong. The state file should only be modified by Terraform itself.
List of exact concepts to memorise:
Declarative vs imperative configuration.
Idempotency.
State file (Terraform).
Deployment (Deployment Manager).
Terraform plan and terraform apply.
Cloud Deployment Manager preview and gcloud deployment-manager deployments create/update.
Remote backend for state locking (Cloud Storage bucket).
Modules: reusable Terraform configurations.
Provider: plugin that connects Terraform to a cloud.
Importing existing resources into Terraform state.
Drift detection and remediation.
Infrastructure as Code best practise: store configuration in version control (Git).
Infrastructure as Code means managing cloud resources using declarative configuration files, not manual clicking in a console.
Terraform uses a state file to track resources and a plan-and-apply workflow to make changes safely.
Cloud Deployment Manager is Google Cloud-native and uses YAML or Python templates with a preview feature to see changes before applying them.
Idempotency ensures that applying the same configuration multiple times produces the same result with no unintended side effects.
Always store Terraform state in a remote backend (like Cloud Storage) with state locking to prevent team conflicts.
When you need to change infrastructure, always edit the configuration file, then apply it — never make manual changes through the cloud console if you want consistency.
Terraform is cloud-agnostic and better for multi-cloud environments; Deployment Manager is better for Google Cloud-only shops needing tight integration.
Drift occurs when someone changes infrastructure outside of IaC; the fix is to re-apply the IaC configuration to restore the desired state.
These come up on the exam all the time. Here's how to tell them apart.
Terraform
Cloud-agnostic: works with AWS, Azure, Google Cloud, and others.
Uses HashiCorp Configuration Language (HCL) for configuration files.
Maintains a separate state file that maps configurations to real-world resources.
Cloud Deployment Manager
Google Cloud-native: only works with Google Cloud.
Uses YAML or Python templates for configuration files.
Tracks resources under a 'deployment' name; no separate state file.
Declarative Configuration
You describe the desired end state, not the steps to get there.
The tool automatically determines the order of operations.
Idempotent: applying the same config multiple times yields the same result.
Imperative Configuration
You write step-by-step commands (e.g., create VM, then attach disk).
You must manually handle dependencies and error handling.
Not idempotent: running the same script twice may cause errors or duplicates.
Local State (Terraform)
Terraform state file stored on your local machine.
Risk of losing the state file if your laptop crashes.
Cannot be shared with team members; no state locking.
Remote State (Terraform)
State file stored in a shared backend like Cloud Storage bucket.
State is durable and accessible by the whole team.
Supports state locking to prevent concurrent updates.
Cloud Deployment Manager Deployment
A deployment is a named collection of resources managed as a unit.
You create, update, or delete an entire deployment at once.
No separate state file; the deployment itself contains the resource list.
Terraform State
A state file is a JSON document that maps configuration to resource IDs.
Resources can span multiple configurations and state files.
State file must be stored separately and managed carefully.
Mistake
Infrastructure as Code means you write scripts (shell scripts) that run commands to create infrastructure. That is IaC.
Correct
IaC uses declarative configuration files that describe the desired state, not step-by-step scripts. Scripts are imperative and fragile. Terraform and Deployment Manager are declarative.
Many beginners come from a scripting background and think writing a bash script that runs gcloud commands is the same thing. It is not, because scripts cannot manage state or handle dependencies automatically.
Mistake
Terraform and Cloud Deployment Manager do the same thing, so you can use either one interchangeably in any situation without any trade-offs.
Correct
They serve the same purpose but have different strengths. Deployment Manager is Google Cloud-native with tighter integration (e.g., previews and rollbacks). Terraform is cloud-agnostic and has a larger community with reusable modules.
Beginners hear both are IaC tools and assume they are identical. The exam tests your ability to choose the correct tool based on the scenario, so knowing their differences is critical.
Mistake
If I use Terraform, I never have to look at the cloud console again. Everything is fully automated and self-healing without any human intervention.
Correct
Terraform automates provisioning and can detect drift, but it does not automatically re-apply changes. You must run 'terraform apply' manually (or in a CI/CD pipeline) to remediate drift. It is not an always-running daemon.
The promise of self-healing is often overhyped. Beginners think IaC tools are like a thermostat that constantly adjusts temperature. In reality, they are more like a blueprint that you must deliberately apply.
Mistake
The Terraform state file is just a cache and can be safely deleted if I lose it, because I can just recreate it by running terraform plan again.
Correct
The state file is essential for Terraform to know what resources it manages. Deleting it means Terraform loses track of all resources. You would have to manually import every existing resource again or destroy and recreate everything.
State file management is a common blind spot. Beginners treat it like a temporary file because they do not understand that it maps configuration to real-world resource IDs. The exam tests this misunderstanding.
Mistake
Cloud Deployment Manager is the same as Terraform because both use templates to deploy resources.
Correct
Deployment Manager uses YAML or Python templates that are injected into a schema. Terraform uses HCL and a state file. Deployment Manager tracks resources under a deployment name; Terraform tracks them in a state file. They are architecturally different.
The superficial similarity (both are IaC tools) leads beginners to assume they work identically. The exam punishes this by offering answer choices that describe Terraform features as if they were Deployment Manager features.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, the exam does not test your ability to write syntax from memory. It tests your conceptual understanding of IaC, the differences between tools, and best practises. You should, however, be familiar with what YAML and HCL look like so you can recognise them in scenario questions.
Yes, Terraform is beginner-friendly. You install the Terraform CLI, set up a Google Cloud service account, and write a simple configuration file. The 'terraform init', 'terraform plan', and 'terraform apply' workflow is straightforward. For the exam, focus on understanding the workflow, not memorising commands.
Terraform will lose track of all the resources it manages. You will not be able to update or destroy them using Terraform. You would need to import each resource manually or destroy everything and recreate it. This is why state files must be stored securely in a remote backend like Cloud Storage.
No, Cloud Deployment Manager is still a supported Google Cloud service as of 2025. Google continues to develop it. However, the industry trend is moving toward Terraform due to its open-source ecosystem and multi-cloud support. The exam covers both tools equally.
Drift is when the real-world state of your infrastructure differs from the desired state defined in your configuration files. This usually happens when someone makes manual changes through the cloud console. The fix is to re-apply your IaC configuration, which will revert the changes and bring the infrastructure back to the desired state.
No, both tools automatically understand dependencies based on references in your configuration. For example, if a VM references a network by name, the tool knows to create the network first. You do not need to manually order the resources. This is one of the key benefits of declarative IaC.
You've finished Infrastructure as Code with Cloud Deployment Manager and Terraform. Continue through the PCDOE study guide to build a complete picture of the exam.
Done with this chapter?