Google Cloud ACE: Deploying and implementing a cloud solution Practice Questions

terraform plan generates an execution plan showing what changes Terraform will make without actually applying them. terraform apply then executes those changes. This is the standard Terraform workflow. terraform deploy and terraform push are not valid Terraform CLI commands. terraform diff is not a Terraform command (it is used in other tools like Pulumi). terraform refresh updates the local state file to match real-world infrastructure but does not preview or apply configuration changes, and terraform run is not a valid command.

Cloud Run is purpose-built for containerized, stateless HTTP workloads. It scales automatically from zero to many instances with zero infrastructure management, making it the best fit. GKE Autopilot reduces node management overhead but still requires cluster configuration and does not scale pods to zero natively without additional tooling (like KEDA). Compute Engine MIGs can scale to a minimum of 0 instances but require infrastructure setup, OS patching, and container orchestration that adds management overhead. Cloud Functions (2nd gen) is backed by Cloud Run and could technically run containers, but Cloud Run is the more direct and idiomatic choice for a containerized microservice.

Option 2 is correct. A StatefulSet with a PersistentVolumeClaim backed by a single-zone Persistent Disk ensures data persists across pod restarts and is appropriate when replication is not required. GKE will ensure the PVC remains bound to the same disk. Option 1 is incorrect—Regional Persistent Disks provide replication, which is unnecessary for this requirement and adds complexity and cost. Option 3 is wrong—directly attaching disks to nodes through instance templates bypasses Kubernetes' storage abstraction and prevents proper pod-disk binding. Option 4 is overkill—while Cloud Filestore works, it's NFS-based shared storage and more expensive; a single-zone PD is simpler for this use case.

An instance template defines the VM configuration (machine type, disk, image, etc.), and a Managed Instance Group (MIG) uses that template to create and manage identical VMs. MIGs support autoscaling policies (including CPU-based), minimum/maximum instance counts, and automatic healing — exactly what is required here. A standalone instance cannot auto-scale by itself; it is a single VM. An unmanaged instance group does not support autoscaling or automatic healing; Cloud Monitoring alerts alone cannot provision new VMs. Sole-tenant nodes are for dedicated physical hardware and do not provide autoscaling capabilities.

Option 1 is correct. You should create a firewall rule that: (1) allows ingress on port 22 (SSH), (2) restricts source traffic to the subnet CIDR ranges (not the entire internet), and (3) applies to VMs via target tags or service accounts. This allows inter-subnet SSH while blocking other traffic. Option 2 is insecure—allowing SSH from '0.0.0.0/0' exposes SSH to the entire internet. Option 3 is unnecessarily complex—VPC Flow Logs are for monitoring, not traffic control. Option 4 is wrong—while deny rules work, the approach is backwards; you should allow SSH and implicitly deny by default (default-deny firewall exists).