Configuration properties in GCP - Step-by-Step Execution

Process Flow - Configuration properties

Start: Define Config Properties

↓

Set Key-Value Pairs

↓

Apply Config to Service

↓

Service Reads Config

↓

Service Behaves According to Config

↓

End

This flow shows how configuration properties are defined, applied to a service, and then used by the service to control its behavior.

Execution Sample

GCP

config = {
  "max_instances": 3,
  "enable_logging": true
}
apply_config(service, config)

Defines configuration properties as key-value pairs and applies them to a cloud service.

Process Table

Step	Action	Config State	Service State	Result
1	Define config with max_instances=3, enable_logging=true	{"max_instances":3, "enable_logging":true}	Not configured	Config ready
2	Apply config to service	{"max_instances":3, "enable_logging":true}	Applying config	Service receives config
3	Service reads max_instances	{"max_instances":3, "enable_logging":true}	max_instances=3	Limits instances to 3
4	Service reads enable_logging	{"max_instances":3, "enable_logging":true}	enable_logging=true	Logging enabled
5	Service runs with config	{"max_instances":3, "enable_logging":true}	Running with limits and logging	Service behaves accordingly
6	End of config application	{"max_instances":3, "enable_logging":true}	Configured and running	Execution complete

💡 All configuration properties applied and service behavior updated accordingly.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
config	{}	{"max_instances":3, "enable_logging":true}	{"max_instances":3, "enable_logging":true}	{"max_instances":3, "enable_logging":true}	{"max_instances":3, "enable_logging":true}	{"max_instances":3, "enable_logging":true}
service_state	Not configured	Not configured	Applying config	max_instances=3	enable_logging=true	Configured and running

Key Moments - 2 Insights

Why does the service need to read each config property separately?

Because each property controls a different part of the service behavior, as shown in steps 3 and 4 where max_instances and enable_logging are read and applied individually.

What happens if a config property is missing?

The service may use a default value or fail to apply that setting. This is implied because the service reads each property explicitly (steps 3 and 4), so missing keys would affect behavior.

Visual Quiz - 3 Questions

Look at the execution table, what is the service state after step 2?

A Applying config

B Configured and running

C Not configured

D Running with limits and logging

💡 Hint

Check the 'Service State' column at step 2 in the execution table.

At which step does the service enable logging?

A Step 3

B Step 4

C Step 5

D Step 6

💡 Hint

Look for when 'enable_logging=true' appears in the service state in the execution table.

If max_instances was changed to 5, how would the service state change at step 3?

A max_instances not set

B max_instances=3

C max_instances=5

D Service fails to start

💡 Hint

Refer to the variable_tracker for 'config' values and how they affect service_state at step 3.

Concept Snapshot

Configuration properties are key-value pairs that control cloud service behavior.
Define them clearly, then apply to the service.
The service reads each property to adjust its actions.
Missing or wrong values can change or break behavior.
Always verify config is applied before service runs.

Full Transcript

Configuration properties in cloud services are simple key-value pairs that tell the service how to behave. First, you define these properties, like maximum instances allowed or whether logging is enabled. Then, you apply this configuration to the service. The service reads each property one by one and adjusts its behavior accordingly. For example, it limits the number of instances to the max_instances value and turns logging on or off based on enable_logging. If a property is missing, the service might use a default or fail to apply that setting. This step-by-step process ensures the service runs exactly as intended by the configuration.

Practice

1. What is the purpose of configuration properties in Google Cloud Platform (GCP)?

easy

A. To define settings that control how cloud resources behave

B. To write application code for cloud functions

C. To store user data in databases

D. To monitor network traffic in real-time

Solution

1. Step 1: Understand configuration properties

   Configuration properties are settings that control the behavior of cloud resources like virtual machines, storage, or services.

2. Step 2: Differentiate from other cloud tasks

   Writing code, storing data, or monitoring traffic are different tasks not directly related to configuration properties.

3. Final Answer:

   To define settings that control how cloud resources behave -> Option A

4. Quick Check:

   Configuration properties = settings control behavior [OK]

Hint: Think of configuration as setting rules for cloud resources [OK]

Common Mistakes:

• Confusing configuration with coding
• Mixing configuration with data storage
• Assuming configuration monitors traffic

2. Which of the following is the correct way to specify a configuration property in a GCP YAML deployment file?

easy

A. config:
instanceType = n1-standard-1

B. properties:
instanceType: n1-standard-1

C. settings:
instanceType: 'n1-standard-1'

D. parameters:
instanceType -> n1-standard-1

Solution

1. Step 1: Identify correct YAML syntax for properties

   In GCP deployment manager, configuration properties are under 'properties:' with key-value pairs using colon and indentation.

2. Step 2: Check each option's syntax

   properties: instanceType: n1-standard-1 uses 'properties:' and colon syntax correctly. Options B, C, and D use incorrect keys or invalid syntax like '=' or '->'.

3. Final Answer:

   properties: instanceType: n1-standard-1 -> Option B

4. Quick Check:

   YAML properties use colon and indentation [OK]

Hint: YAML uses colon and indentation for key-value pairs [OK]

Common Mistakes:

• Using '=' instead of ':' in YAML
• Wrong top-level key like 'config' or 'settings'
• Using symbols like '->' which are invalid in YAML

3. Given this snippet of a GCP deployment YAML:

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

What is the machine type configured for the VM?

medium

A. n1-standard-1

B. us-central1-a

C. debian-10

D. PERSISTENT

Solution

1. Step 1: Locate machineType property

   The machineType is set under properties as 'zones/us-central1-a/machineTypes/n1-standard-1'. The last part after the last slash is the machine type.

2. Step 2: Extract machine type value

   The machine type is 'n1-standard-1', which defines the VM size and resources.

3. Final Answer:

   n1-standard-1 -> Option A

4. Quick Check:

   Machine type is the last part of the path [OK]

Hint: Machine type is the last segment in the machineTypes path [OK]

Common Mistakes:

• Confusing zone with machine type
• Picking image name as machine type
• Selecting disk type as machine type

4. You have this GCP deployment YAML snippet:

resources:
- name: my-storage
  type: storage.v1.bucket
  properties:
    location: us-east1
    storageClass: STANDARD
    versioning:
      enabled: true
    accessControl:
      - entity: allUsers
        role: READER

What is the error in this configuration?

medium

A. location must be a zone, not a region

B. versioning.enabled must be false for public buckets

C. accessControl should be acl

D. storageClass must be lowercase

Solution

1. Step 1: Check property names for storage bucket

   The correct property for access control in GCP storage buckets is 'acl', not 'accessControl'.

2. Step 2: Validate other properties

   Versioning can be true or false regardless of public access. StorageClass is case-insensitive but usually uppercase is accepted. Location is a region, which is correct.

3. Final Answer:

   accessControl should be acl -> Option C

4. Quick Check:

   Property names must match GCP specs exactly [OK]

Hint: Check exact property names in GCP docs [OK]

Common Mistakes:

• Using incorrect property name 'accessControl' instead of 'acl'
• Assuming versioning must be false for public buckets
• Confusing region and zone names

5. You want to configure a GCP Compute Engine instance with a startup script and custom metadata. Which configuration properties should you use in your deployment YAML to achieve this?

hard

A. startupScript: |
#!/bin/bash
echo Hello World

B. scripts:
startup: '#!/bin/bash\necho Hello World'

C. customMetadata:
startup-script: '#!/bin/bash\necho Hello World'

D. metadata:
items:
- key: startup-script
value: |-
#!/bin/bash
echo Hello World

Solution

1. Step 1: Identify correct metadata property for startup scripts

   GCP Compute Engine uses 'metadata' with 'items' list containing key-value pairs for custom metadata like 'startup-script'.

2. Step 2: Verify syntax for multiline script

   Using '|-' in YAML allows multiline script values correctly under 'value'. Other options use incorrect property names or formats.

3. Final Answer:

   metadata: items: - key: startup-script value: |- #!/bin/bash echo Hello World -> Option D

4. Quick Check:

   Use metadata.items with key startup-script [OK]

Hint: Startup scripts go under metadata.items with key 'startup-script' [OK]

Common Mistakes:

• Using wrong property names like startupScript or scripts
• Not formatting multiline scripts properly in YAML
• Placing script outside metadata block