Google Cloud Professional Cloud Architect: Manage and provision a solution infrastructure Practice Questions

Option C is correct. The roles/artifactregistry.reader role grants permissions to read (pull/download) artifacts from Artifact Registry repositories without the ability to push, tag, or delete—exactly matching the requirement. Option B is wrong because roles/artifactregistry.writer also grants write (push) permissions, which the team explicitly should not have. Option D is wrong because roles/artifactregistry.repoAdmin grants full administrative control over the repository, including deletion and permission management, which far exceeds the read-only requirement. Option A is wrong because roles/storage.objectViewer is a Cloud Storage IAM role; Artifact Registry stores metadata and blobs in its own managed storage that is not directly accessible via Cloud Storage IAM, so this role does not grant Artifact Registry pull/download permissions.

Option C is correct because surge upgrades (configuring maxSurge in the node pool upgrade settings) cause GKE to add new nodes at the target version before draining old ones, ensuring capacity is maintained and workloads are rescheduled with zero downtime. This is GKE's built-in, recommended mechanism for zero-downtime node pool upgrades. Option D (blue/green with a new node pool) is a valid alternative but is more operationally complex and is not the standard GKE upgrade mechanism — it also requires workload selectors or taints to manage scheduling. Option A is wrong because GKE does not support in-place kubelet upgrades without node replacement; the --no-drain flag is not a supported upgrade option and upgrading nodes without draining could cause pod disruption. Option B is wrong because manually upgrading kubelet on nodes is unsupported in GKE — nodes are managed by the control plane and manual changes are overwritten or cause nodes to become NotReady.

Options A and C are correct. Autohealing (A) monitors instance health using a configured health check and automatically recreates any instance that fails, addressing the crash-replacement requirement. A rolling update policy with max surge and max unavailable settings (C) controls how the update is applied—limiting disruption while progressively replacing instances, meeting the rolling-update completion requirement. Option B (canary deployment to a separate group) is a traffic-splitting strategy for testing a new version, not a mechanism for autohealing or structured rolling updates within a single MIG. Option D (preemptible VMs) reduces cost but actually increases the likelihood of instance loss and is inappropriate for a stable rolling update. Option E (instance scheduling/maintenance windows) controls when instances start and stop on a schedule, not rolling updates. Option F (regional MIG) improves availability across zones but does not by itself enable autohealing or manage rolling update behavior.

Option B is correct because Cloud Build executes build steps as the Cloud Build service account, and roles/artifactregistry.writer grants the minimum permissions required to push images to Artifact Registry. Option D is overly permissive — roles/artifactregistry.admin includes delete and administrative permissions not needed for a push operation. Option C is wrong because Cloud Build runs as its own service account, not the submitting user's account; granting the user account permissions does not help. Option A is wrong because Artifact Registry does not use a GCS bucket as a backend for container images — it is a separate service — and roles/storage.objectAdmin on GCS does not grant Artifact Registry push access.

Option A is correct. The initialDelaySec parameter in a MIG's autohealing policy specifies how long to wait after an instance is created before the health check is evaluated for autohealing purposes. Setting a value long enough for the application to fully start (e.g., 120–300 seconds) prevents the MIG from incorrectly replacing healthy instances that are still in their startup phase. Option D is wrong because switching to a TCP health check only verifies that a port is open, not that the application is actually ready to serve traffic; it would mask real application failures and defeats the purpose of autohealing. Option C is wrong because reducing check interval and timeout makes the health checker more aggressive, not less—this would cause instances to be marked unhealthy even faster during startup, worsening the problem. Option B is wrong because manually disabling and re-enabling autohealing introduces operational risk, is not scalable, and is precisely the problem that initialDelaySec is designed to solve without manual intervention.