GCP Deployment Manager vs Terraform - Honest Comparison
A GCP shop has to pick an infrastructure-as-code tool, and the interviewer wants to know if you understand the tradeoff between native tooling and portability. This question comes up constantly in GCP-focused DevOps and platform interviews because it's a fast way to check whether you think about long-term maintenance costs, not just what works today.
The answer interviewers want
Deployment Manager is GCP's native IaC tool. It has tight integration with GCP services and zero setup overhead since it's built into the platform. Terraform works across every major cloud, but it requires more upfront setup and ongoing overhead compared to a native tool.
In practice, most teams choose Terraform. The reasons come down to ecosystem, not raw feature count: a larger community, more learning resources and modules available, and consistent syntax whether you're working in GCP, AWS, or Azure.
The honest rule of thumb: use Deployment Manager only if you're certain the organization is 100% GCP, forever, with no plausible multi-cloud or cloud-migration future. In every other case, Terraform saves you pain later, because you won't be rewriting your IaC from scratch if the cloud strategy changes.
Why interviewers ask this
They're checking whether you default to the trendiest tool or whether you can reason about tradeoffs like vendor lock-in, team portability of skills, and ecosystem maturity. A candidate who says "always use Terraform" without conditions sounds like they're reciting a trend rather than thinking. The ideal answer names a real scenario where the native tool is actually fine, then explains why that scenario is rare.
Follow-ups to expect
"When would Deployment Manager actually be the better choice?" Only when the organization has a firm, long-term, single-cloud commitment to GCP, so the lock-in risk that Terraform avoids simply doesn't apply.
"What's the real cost of choosing Terraform over Deployment Manager?" More setup and operational overhead up front, state management, provider versioning, and the learning curve of HCL, versus a tool that's ready to go with zero configuration.
"How do you justify Terraform to a team that's GCP-only today?" Point to the ecosystem advantages: a bigger community, more existing modules and documentation, and consistent syntax if the organization ever adds another cloud, migrates workloads, or acquires a team that uses something else.
The common wrong answer
Candidates either default to "always Terraform" with no justification, which sounds like cargo-culting a popular tool, or they argue Deployment Manager is better purely because of tighter integration and zero setup, ignoring that most organizations don't stay single-cloud forever. The strong answer frames this as a bet on the future: pick the native tool only when you're confident there's no future multi-cloud or migration scenario, and default to Terraform otherwise because rewriting IaC later is expensive.