Resource definitions for GCP - Step-by-Step Execution

Process Flow - Resource definitions for GCP

Start: Define Resource

↓

Specify Resource Type

↓

Set Resource Properties

↓

Validate Configuration

↓

Deploy Resource

↓

Resource Created in GCP

↓

Use Resource in Project

This flow shows how you define a GCP resource by specifying its type and properties, validate it, deploy it, and then use it in your project.

Execution Sample

GCP

resource "google_storage_bucket" "my_bucket" {
  name     = "my-unique-bucket"
  location = "US"
  labels = {
    env = "dev"
  }
}

Defines a Google Cloud Storage bucket named 'my-unique-bucket' in the US region with a label 'env' set to 'dev'.

Process Table

Step	Action	Resource Property	Value	Validation Result	Deployment Status
1	Start resource definition	-	-	Pending	Not Deployed
2	Set resource type	Type	google_storage_bucket	Valid	Not Deployed
3	Set resource name	Name	my-unique-bucket	Valid (unique)	Not Deployed
4	Set location	Location	US	Valid region	Not Deployed
5	Set labels	Labels	{"env":"dev"}	Valid	Not Deployed
6	Validate configuration	-	-	All properties valid	Not Deployed
7	Deploy resource	-	-	Deployment started	Deploying
8	Deployment complete	-	-	Resource created successfully	Deployed

💡 Resource is successfully created and ready to use in GCP project.

Status Tracker

Variable	Start	After Step 3	After Step 5	After Step 8
resource_type	-	google_storage_bucket	google_storage_bucket	google_storage_bucket
resource_name	-	my-unique-bucket	my-unique-bucket	my-unique-bucket
location	-	-	US	US
labels	-	-	{"env":"dev"}	{"env":"dev"}
deployment_status	Not Deployed	Not Deployed	Not Deployed	Deployed

Key Moments - 3 Insights

Why must the resource name be unique?

The resource name must be unique to avoid conflicts in GCP. As shown in step 3 of the execution_table, the name 'my-unique-bucket' is validated as unique before deployment.

What happens if the location is invalid?

If the location is invalid, validation fails at step 4 or 6 in the execution_table, and deployment will not proceed. Only valid GCP regions are accepted.

When does the deployment status change to 'Deployed'?

Deployment status changes to 'Deployed' at step 8 after the resource is successfully created, as shown in the execution_table and variable_tracker.

Visual Quiz - 3 Questions

Look at the execution_table, what is the deployment status at step 6?

A Deploying

B Not Deployed

C Deployed

D Failed

💡 Hint

Check the 'Deployment Status' column at step 6 in the execution_table.

At which step is the resource name validated as unique?

A Step 5

B Step 2

C Step 3

D Step 7

💡 Hint

Look at the 'Resource Property' and 'Validation Result' columns in the execution_table.

If the label 'env' was missing, which step would fail validation?

A Step 6

B Step 4

C Step 3

D Step 5

💡 Hint

Validation of all properties happens at step 6 in the execution_table.

Concept Snapshot

GCP resource definitions specify the resource type and properties.
Each resource must have a unique name and valid settings.
Configuration is validated before deployment.
Deployment creates the resource in your GCP project.
Labels help organize and identify resources.
Always validate region and naming rules.

Full Transcript

This visual execution trace shows how to define a Google Cloud Platform resource. First, you start by specifying the resource type, such as a storage bucket. Then you set the resource name, which must be unique across GCP. Next, you set properties like location and labels. The configuration is validated to ensure all values are correct. After validation, the resource is deployed to GCP. The deployment status changes from 'Not Deployed' to 'Deployed' once the resource is created successfully. This process ensures your resource is ready to use in your cloud project.

Practice

1. What is the main purpose of a resource definition in Google Cloud Platform (GCP)?

easy

A. To manually start and stop virtual machines

B. To write application code that runs on GCP

C. To monitor the usage of cloud resources

D. To tell GCP what cloud parts to create and how to configure them

Solution

1. Step 1: Understand the role of resource definitions

   Resource definitions specify what cloud resources to create and their settings.

2. Step 2: Compare options to the definition role

   Only To tell GCP what cloud parts to create and how to configure them describes creating and configuring cloud parts, which matches resource definitions.

3. Final Answer:

   To tell GCP what cloud parts to create and how to configure them -> Option D

4. Quick Check:

   Resource definitions = create and configure cloud parts [OK]

Hint: Resource definitions describe cloud parts to create [OK]

Common Mistakes:

• Confusing resource definitions with application code
• Thinking resource definitions monitor usage
• Believing resource definitions manually control VMs

2. Which of the following is the correct minimal structure for a GCP resource definition in YAML?

easy

A. resources:\n - name: my-vm\n type: compute.instance\n properties:\n location: us-central1-a

B. resources:\n - id: my-vm\n kind: compute.v1.instance\n settings:\n zone: us-central1-a

C. resources:\n - name: my-vm\n type: compute.v1.instance\n properties:\n zone: us-central1-a

D. resource_list:\n - name: my-vm\n type: compute.v1.instance\n properties:\n zone: us-central1-a

Solution

1. Step 1: Check the required keys in GCP resource definitions

   GCP expects 'resources' list with each item having 'name', 'type', and 'properties'.

2. Step 2: Validate each option

   resources:\n - name: my-vm\n type: compute.v1.instance\n properties:\n zone: us-central1-a uses correct keys and valid type 'compute.v1.instance'. Others use wrong keys like 'id', 'kind', or wrong root key 'resource_list'. resources:\n - name: my-vm\n type: compute.instance\n properties:\n location: us-central1-a uses incorrect type 'compute.instance'.

3. Final Answer:

   resources:\n - name: my-vm\n type: compute.v1.instance\n properties:\n zone: us-central1-a -> Option C

4. Quick Check:

   Correct keys and type = resources:\n - name: my-vm\n type: compute.v1.instance\n properties:\n zone: us-central1-a [OK]

Hint: Look for 'resources', 'name', 'type', 'properties' keys [OK]

Common Mistakes:

• Using 'id' instead of 'name'
• Using 'kind' instead of 'type'
• Wrong root key like 'resource_list'
• Incorrect resource type format

3. Given this resource definition snippet, what will be the zone of the created VM?

resources:
  - name: test-vm
    type: compute.v1.instance
    properties:
      zone: europe-west1-b
      machineType: n1-standard-1
      disks:
        - deviceName: boot
          boot: true
          autoDelete: true
          initializeParams:
            sourceImage: projects/debian-cloud/global/images/family/debian-11

medium

A. europe-west1-b

B. us-central1-a

C. asia-east1-a

D. No zone specified, deployment will fail

Solution

1. Step 1: Locate the zone property in the resource definition

   The 'zone' property is set to 'europe-west1-b' under 'properties'.

2. Step 2: Understand zone usage in VM creation

   The VM will be created in the specified zone 'europe-west1-b'.

3. Final Answer:

   europe-west1-b -> Option A

4. Quick Check:

   Zone property value = europe-west1-b [OK]

Hint: Check 'zone' under 'properties' for VM location [OK]

Common Mistakes:

• Assuming default zone if specified
• Confusing machineType with zone
• Thinking deployment fails without explicit zone

4. Identify the error in this resource definition snippet:

resources:
  - name: my-bucket
    type: storage.v1.bucket
    properties:
      location: us-east1
      storageClass: STANDARD
  - name: my-bucket
    type: storage.v1.bucket
    properties:
      location: us-west1
      storageClass: NEARLINE

medium

A. Invalid storageClass values used

B. Duplicate resource names cause deployment failure

C. Missing 'type' field in second resource

D. Location values are not allowed in bucket properties

Solution

1. Step 1: Check resource names for uniqueness

   Both resources have the same name 'my-bucket', which is not allowed.

2. Step 2: Verify other fields

   Both have 'type' and valid 'storageClass' and 'location'. Only duplicate names cause error.

3. Final Answer:

   Duplicate resource names cause deployment failure -> Option B

4. Quick Check:

   Unique resource names required = Duplicate resource names cause deployment failure [OK]

Hint: Resource names must be unique in definitions [OK]

Common Mistakes:

• Ignoring duplicate names
• Thinking storageClass values are invalid
• Believing location is disallowed

5. You want to define a GCP resource that creates a Compute Engine VM with a specific network interface and a startup script. Which of the following resource definitions correctly includes both properties?

hard

A. resources:
- name: vm-with-script
type: compute.v1.instance
properties:
zone: us-central1-a
machineType: n1-standard-1
networkInterfaces:
- network: global/networks/default
metadata:
items:
- key: startup-script
value: |-
#!/bin/bash
echo Hello World > /var/log/startup.log

B. resources:
- name: vm-with-script
type: compute.v1.instance
properties:
zone: us-central1-a
machineType: n1-standard-1
network: default
startupScript: |
#!/bin/bash
echo Hello World > /var/log/startup.log

C. resources:
- name: vm-with-script
type: compute.v1.instance
properties:
zone: us-central1-a
machineType: n1-standard-1
networkInterfaces:
- network: default
metadata:
startup-script: |
#!/bin/bash
echo Hello World > /var/log/startup.log

D. resources:
- name: vm-with-script
type: compute.v1.instance
properties:
zone: us-central1-a
machineType: n1-standard-1
networkInterfaces:
- network: default
metadata:
items:
- key: startup
value: echo Hello World

Solution

1. Step 1: Check network interface property format

   Correct format uses 'networkInterfaces' list with 'network' as full resource path or relative path like 'global/networks/default'.

2. Step 2: Check metadata startup script format

   Metadata must have 'items' list with 'key' and 'value' pairs. The key for startup script is 'startup-script'.

3. Step 3: Validate each option

   resources: - name: vm-with-script type: compute.v1.instance properties: zone: us-central1-a machineType: n1-standard-1 networkInterfaces: - network: global/networks/default metadata: items: - key: startup-script value: |- #!/bin/bash echo Hello World > /var/log/startup.log correctly uses 'networkInterfaces' with full network path and metadata with 'items' list and proper startup script. Others have incorrect keys or missing 'items' list.

4. Final Answer:

   Option A correctly defines network interface and startup script -> Option A

5. Quick Check:

   Correct networkInterfaces and metadata items = resources: - name: vm-with-script type: compute.v1.instance properties: zone: us-central1-a machineType: n1-standard-1 networkInterfaces: - network: global/networks/default metadata: items: - key: startup-script value: |- #!/bin/bash echo Hello World > /var/log/startup.log [OK]

Hint: Use 'networkInterfaces' list and metadata 'items' with key/value [OK]

Common Mistakes:

• Using 'network' instead of 'networkInterfaces'
• Missing 'items' list in metadata
• Wrong key name for startup script
• Incorrect network path format