This article covers the --preview feature in Cloud Deployment Manager: what it does, the gcloud command to use it, why simulating a deployment before applying it is the right default for production work, and how the Associate Cloud Engineer exam tests it.
It does not cover the rest of Deployment Manager (configuration files, templates, the comparison with Terraform). Those are separate articles. The focus here is one feature, narrowly.
When you create a deployment in Cloud Deployment Manager normally, it actually creates the resources. VMs come up, networks get configured, IAM bindings are applied. Real changes happen in your project.
With the --preview flag, that does not happen. Instead, Deployment Manager analyzes your configuration, figures out what would change, and generates a plan. The plan tells you what resources would be created, modified, or deleted if you ran the deployment for real. No actual resources are touched.
Then, if the plan looks good, you can run the deployment without --preview to apply the changes. If the plan looks wrong, you fix the configuration first.
The standard form is straightforward:
gcloud deployment-manager deployments create my-deployment \
--config my-config.yaml \
--previewWhat each piece does. "deployments create my-deployment" tells Deployment Manager to set up a deployment with that name. "--config my-config.yaml" points to the configuration file that describes the resources. "--preview" is the flag that activates simulation mode.
To then apply the previewed deployment, you run:
gcloud deployment-manager deployments update my-deploymentThis commits the changes that were previewed. You can also abandon the preview if you decide not to apply it.
Production infrastructure deserves caution. The cost of accidentally deleting a database, recreating a VM that should have stayed put, or unintentionally modifying a network configuration is high. Even small changes can have ripple effects you did not anticipate.
Preview gives you a chance to read what is about to happen before it happens. It catches mistakes that would otherwise become outages. It is the dress rehearsal before the live show.
For non-production environments, you can probably skip the preview and just apply changes directly. You will catch problems quickly because nothing important breaks. For production, preview should be the default, and skipping it should be a deliberate decision, not an accident.
This is the part that matters more than the syntax. The mindset of "preview, review, then apply" is what good infrastructure operations looks like, and the --preview flag in Deployment Manager is the GCP-native way to do it. Terraform's "terraform plan" is the analogous feature, and the discipline is the same in both tools.
When you run a preview, Deployment Manager generates a deployment manifest that lists every resource. For each one, it tells you whether the resource would be created, modified, or deleted. For modifications, it will indicate what fields are changing.
You read through the manifest, confirm that each change matches what you intended, and then commit. If you see a deletion you did not expect, that is your signal to stop and check the configuration before applying anything.
The exam tests --preview in a specific pattern. A question describes a team that is about to make a significant change to their GCP infrastructure with Deployment Manager and wants to verify the impact before any resources are actually touched. The answer is the --preview flag.
If you see in the question simulating a deployment, dry run, previewing infrastructure changes, or "verify what would happen before applying," think --preview. The question may show the gcloud command, with the flag missing or correctly placed, and ask which option does the simulation.
The exam is not subtle here. If Deployment Manager is the tool and the goal is to see the change before it happens, --preview is the answer.
The --preview flag in Cloud Deployment Manager simulates a deployment without actually applying it. You run gcloud deployment-manager deployments create with --preview, review the generated plan, and then commit if everything looks right. It is the GCP-native way to dress-rehearse an infrastructure change, and it is the right default for production work.
For the Associate Cloud Engineer exam, recognize the --preview flag, the gcloud command structure, and the scenario pattern of "simulate before deploying." That covers what gets tested.
My Associate Cloud Engineer course covers --preview alongside the rest of Cloud Deployment Manager, including configuration files and updating existing deployments, in the IaC section relevant to the ACE exam.
