Deployment Manager as native IaC in GCP - Step-by-Step Execution

Process Flow - Deployment Manager as native IaC

Write YAML/Template config

↓

Run deployment command

↓

Deployment Manager parses config

↓

Creates/Updates GCP resources

↓

Deployment state stored

↓

User verifies deployment status

Deployment Manager takes your config files, reads them, creates or updates resources in GCP, and keeps track of the deployment state.

Execution Sample

GCP

resources:
  - name: my-vm
    type: compute.v1.instance
    properties:
      zone: us-central1-a
      machineType: zones/us-central1-a/machineTypes/n1-standard-1
      disks:
        - deviceName: boot
          type: PERSISTENT
          boot: true
          autoDelete: true
          initializeParams:
            sourceImage: projects/debian-cloud/global/images/family/debian-10

This YAML defines a VM instance resource to be created in GCP.

Process Table

Step	Action	Input/Config	Result/State Change
1	Read YAML config	resources: my-vm VM definition	Parsed resource definition stored
2	Validate config	Check resource types and properties	Validation successful
3	Send create request	Create VM instance in zone us-central1-a	API call sent to GCP
4	GCP creates VM	VM creation in progress	VM instance created and running
5	Store deployment state	Record resource and status	Deployment state saved
6	User checks status	gcloud deployment-manager deployments describe	Shows VM created and active
7	Exit	All resources created successfully	Deployment complete

💡 All resources created and deployment state saved; deployment is complete.

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	Final
deployment_state	empty	parsed config loaded	create request sent	resources created	deployment complete
resource_status	none	defined	pending creation	created	active

Key Moments - 3 Insights

Why does Deployment Manager need a config file before creating resources?

The config file tells Deployment Manager what resources to create and their settings. Without it, Deployment Manager doesn't know what to build. See execution_table step 1.

What happens if the config has an invalid resource type?

Deployment Manager will fail validation and stop before creating resources. This is shown in execution_table step 2 where validation must succeed.

How does Deployment Manager keep track of created resources?

It stores deployment state after resource creation (step 5), so it knows what exists and can update or delete later.

Visual Quiz - 3 Questions

Look at the execution_table, what is the deployment_state after step 3?

A deployment complete

B resources created

C create request sent

D parsed config loaded

💡 Hint

Check variable_tracker row 'deployment_state' column 'After Step 3'

At which step does Deployment Manager validate the config?

A Step 2

B Step 1

C Step 4

D Step 5

💡 Hint

See execution_table step with action 'Validate config'

If the VM creation fails, which step would not complete successfully?

A Step 3

B Step 4

C Step 5

D Step 6

💡 Hint

Step 4 is where GCP creates the VM; failure happens here

Concept Snapshot

Deployment Manager uses YAML or templates to define GCP resources.
Run deployment commands to apply configs.
It validates configs, creates resources, and tracks state.
You can update or delete resources via updated configs.
Deployment state helps manage resource lifecycle.

Full Transcript

Deployment Manager is a tool in Google Cloud that lets you define your infrastructure using configuration files, usually in YAML. You write what resources you want, like virtual machines, and their settings. When you run the deployment command, Deployment Manager reads your config, checks it for errors, and then tells Google Cloud to create those resources. It keeps track of what it created so you can update or delete them later. This process helps automate and manage your cloud infrastructure easily and reliably.

Practice

1. What is the main purpose of Google Cloud Deployment Manager?

easy

A. To define and manage cloud resources using code

B. To manually create resources through the console

C. To monitor cloud resource usage in real-time

D. To provide a graphical interface for cloud billing

Solution

1. Step 1: Understand Deployment Manager's role

   Deployment Manager lets you write code to define cloud resources instead of manual setup.

2. Step 2: Compare options

   Only To define and manage cloud resources using code describes defining and managing resources using code, which matches Deployment Manager's purpose.

3. Final Answer:

   To define and manage cloud resources using code -> Option A

4. Quick Check:

   Deployment Manager = Infrastructure as Code [OK]

Hint: Deployment Manager = write code for cloud setup [OK]

Common Mistakes:

• Confusing Deployment Manager with monitoring tools
• Thinking it is a manual console tool
• Mixing it with billing or cost tools

2. Which of the following is the correct way to start a Deployment Manager YAML configuration file?

easy

A. services:

B. resources:

C. instances:

D. deployments:

Solution

1. Step 1: Recall YAML structure for Deployment Manager

   The root key to list cloud resources is resources:.

2. Step 2: Check other options

   Options like deployments:, instances:, and services: are not valid root keys in Deployment Manager YAML.

3. Final Answer:

   resources: -> Option B

4. Quick Check:

   YAML starts with resources: [OK]

Hint: Deployment Manager YAML always starts with resources: [OK]

Common Mistakes:

• Using wrong root keys like deployments or instances
• Confusing resource types with YAML structure
• Starting with service names instead of resources

3. Given this Deployment Manager snippet:

resources:
- name: my-vm
  type: compute.v1.instance
  properties:
    zone: us-central1-a
    machineType: zones/us-central1-a/machineTypes/n1-standard-1

What resource is being created?

medium

A. A network firewall rule

B. A storage bucket in us-central1-a

C. A SQL database instance

D. A virtual machine instance in zone us-central1-a

Solution

1. Step 1: Identify resource type

   The type compute.v1.instance means a virtual machine (VM) instance.

2. Step 2: Check properties

   The zone and machineType confirm it's a VM in zone us-central1-a with a standard machine type.

3. Final Answer:

   A virtual machine instance in zone us-central1-a -> Option D

4. Quick Check:

   compute.v1.instance = VM instance [OK]

Hint: compute.v1.instance means VM instance [OK]

Common Mistakes:

• Confusing instance with storage or database
• Ignoring the type field
• Assuming default zone without checking properties

4. You wrote this Deployment Manager YAML:

resources:
- name: my-vm
  type: compute.v1.instance
  properties:
    zone: us-central1-a
    machineType: n1-standard-1

Why does deployment fail?

medium

A. name property cannot be my-vm

B. zone property is invalid

C. machineType property is missing zone prefix

D. type compute.v1.instance is deprecated

Solution

1. Step 1: Check machineType format

   machineType must include full path with zone prefix like zones/us-central1-a/machineTypes/n1-standard-1.

2. Step 2: Validate other fields

   zone is valid, name is allowed, and type is current. Only machineType format is wrong.

3. Final Answer:

   machineType property is missing zone prefix -> Option C

4. Quick Check:

   machineType needs full path [OK]

Hint: machineType needs full zone path like zones/zone/machineTypes/type [OK]

Common Mistakes:

• Using short machineType without zone prefix
• Changing name to fix error
• Assuming type is deprecated

5. You want to create two VM instances in Deployment Manager using one YAML file. Which approach is best?

hard

A. List two separate resource entries under resources with different names

B. Create one resource with two names separated by commas

C. Use a loop inside YAML to repeat the resource

D. Write two separate YAML files and deploy them separately

Solution

1. Step 1: Understand YAML resource listing

   Deployment Manager YAML supports multiple resources by listing each with a unique name under resources:.

2. Step 2: Evaluate options

   List two separate resource entries under resources with different names correctly lists two resources separately. Create one resource with two names separated by commas is invalid syntax. Use a loop inside YAML to repeat the resource is not supported natively in YAML. Write two separate YAML files and deploy them separately works but is less efficient and not best practice.

3. Final Answer:

   List two separate resource entries under resources with different names -> Option A

4. Quick Check:

   Multiple resources = multiple entries [OK]

Hint: Multiple resources = multiple entries under resources: [OK]

Common Mistakes:

• Trying to name one resource with multiple names
• Expecting loops inside YAML
• Splitting into multiple files unnecessarily