Resource definitions for GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Identify the correct resource type for a GCP Compute Engine VM instance

Which of the following resource types correctly defines a Compute Engine virtual machine instance in a GCP deployment configuration?

A compute.instance.v1

B compute.v1.instance

C gcp.compute.instance

D computeEngine.instance

💡 Hint

GCP resource types follow the pattern: service.apiVersion.resource

The correct resource type for a Compute Engine VM instance is 'compute.v1.instance'. This follows the GCP naming convention where 'compute' is the service, 'v1' is the API version, and 'instance' is the resource.

❓ Configuration

intermediate

Determine the correct YAML snippet for defining a GCP Cloud Storage bucket

Given the following YAML snippet, which option correctly defines a Cloud Storage bucket resource in a GCP deployment?

GCP

resources:
- name: my-storage-bucket
  type: ???
  properties:
    location: US
    storageClass: STANDARD

A storage.v1.buckets

B gcp.storage.bucket

C storage.v1.bucket

D storage.bucket.v1

💡 Hint

Check the official GCP resource type naming for Cloud Storage buckets.

The correct resource type for a Cloud Storage bucket is 'storage.v1.bucket'. This matches the service 'storage', API version 'v1', and resource 'bucket'.

❓ security

advanced

Identify the resource type to define a GCP IAM policy binding

Which resource type is used to define an IAM policy binding for a GCP project in a deployment configuration?

A cloudresourcemanager.v1.projectIamMember

B cloudresourcemanager.v1.projectIamBinding

C cloudresourcemanager.v1.projectIamPolicy

D cloudresourcemanager.v1.projectIamRole

💡 Hint

IAM bindings assign a role to a member, so look for 'IamMember'.

The resource type 'cloudresourcemanager.v1.projectIamMember' is used to assign a specific IAM role to a member on a project. Other types manage policies or bindings but this one is for individual member bindings.

❓ service_behavior

advanced

Predict the behavior when deploying a GCP Pub/Sub topic with an incorrect resource type

If you deploy a configuration with the resource type 'pubsub.topic.v1' instead of the correct 'pubsub.v1.topic', what will happen?

A Deployment succeeds and creates a default topic

B Deployment succeeds but the topic is not created

C Deployment partially succeeds with warnings

D Deployment fails with a resource type not found error

💡 Hint

GCP resource types must match exactly to be recognized.

Using an incorrect resource type like 'pubsub.topic.v1' causes the deployment to fail because GCP does not recognize this resource type. The error will indicate the resource type is invalid or not found.

✅ Best Practice

expert

Choose the best practice for defining multiple GCP resources with dependencies

When defining multiple GCP resources in a deployment configuration where one resource depends on another (e.g., a VM depends on a network), what is the best practice to ensure correct deployment order?

A Use the 'dependencies' property to explicitly declare dependencies between resources

B List resources in the order they should be created; GCP will deploy sequentially

C Deploy resources separately in different deployment files to control order

D Rely on GCP to automatically detect dependencies based on resource names

💡 Hint

Explicit dependency declarations help deployment tools understand order.

Using the 'dependencies' property explicitly tells the deployment manager which resources must be created first. This ensures correct order and avoids deployment errors due to missing dependencies.

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