What is the primary purpose of a template in Google Cloud Deployment Manager?
Think about what you reuse when creating multiple similar resources.
Templates in Deployment Manager define reusable resource configurations, allowing you to deploy consistent infrastructure repeatedly.
Given the following Deployment Manager YAML snippet, how many VM instances will be created?
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
networkInterfaces:
- network: global/networks/default
accessConfigs:
- name: External NAT
type: ONE_TO_ONE_NATCount the resource entries defined in the YAML.
There is one resource named 'my-vm' of type compute.v1.instance, so one VM instance will be created.
In Deployment Manager, if you want to ensure a Cloud Storage bucket is created before a Compute Engine instance that uses it, which approach correctly enforces this order?
Think about how to tell Deployment Manager about resource creation order.
The 'dependsOn' field explicitly tells Deployment Manager to create the bucket before the instance, ensuring correct order.
Which is the best practice to handle sensitive data like API keys in Deployment Manager templates?
Consider secure storage options provided by Google Cloud.
Using Google Secret Manager to store and reference secrets keeps sensitive data secure and separate from code.
When you update a Deployment Manager configuration that changes the machine type of a Compute Engine instance, what is the expected behavior during deployment update?
Think about how immutable some resource properties are in GCP.
Changing machine type requires recreating the instance, so Deployment Manager deletes the old instance and creates a new one.