Google Cloud Professional Cloud Architect: Ensure solution and operations reliability Practice Questions

Option C is correct: Compute Engine Snapshot Schedules are a native, fully managed feature that automates both creation and deletion of disk snapshots on a configurable schedule with a built-in retention policy — exactly what is needed with zero custom code. Option D (Cloud Scheduler + Cloud Run + Cloud Functions) achieves the same result but requires building and maintaining custom application code, IAM bindings, and multiple resources — far more operational overhead than a snapshot schedule. Option B is wrong: Cloud SQL automated backups apply only to Cloud SQL instances and their managed storage, not to arbitrary Persistent Disks. Option A (startup script on a management VM) is fragile, requires managing the VM lifecycle, and introduces unnecessary complexity compared to the native snapshot schedule feature.

Option A is correct: Cloud Monitoring alerting policies have a documentation field (sometimes called 'Documentation' or 'Alert policy documentation') where you can embed Markdown-formatted text, including URLs to runbooks, dashboards, and the alerting policy itself. This documentation is included in alert notifications sent to on-call engineers. Option C (notification channel labels) are metadata tags on the notification channel configuration (e.g., a PagerDuty channel) and are not the right place for per-policy contextual documentation. Option D (uptime check annotations) does not exist as a feature — uptime checks have names and resource labels but not free-text annotation fields for runbook links. Option B (log-based metric labels) are used to extract dimension values from log entries for metric segmentation, not for embedding operational documentation.

Option C is correct: promoting a read replica severs the replication relationship permanently. The original primary and the promoted instance become two independent databases. Any data written to both after promotion creates a split-brain scenario requiring manual reconciliation. Option A is correct: asynchronous replication means the replica may be seconds to minutes behind the primary at the time of the outage. Transactions in that gap are lost on the promoted replica, resulting in RPO > 0. Option D is wrong: promoting a replica does not trigger PITR on the original primary — these are independent operations. Option E is wrong: promotion does involve a brief period where the instance reconfigures itself, and client applications must be updated to use the new instance connection string — connections are NOT automatically rerouted. Option B is wrong: GCP does NOT automatically re-establish replication after a recovery — the team must manually recreate a new replica from the promoted instance if desired.

Options A and E are correct systemic findings. Option E identifies a process/tooling gap: the lack of a mandatory approval gate for destructive infrastructure changes is a systemic failure — a policy requiring human review of plans with deletions would have caught this regardless of which engineer ran it. Option A identifies a recovery capability gap: a 1-day backup retention limited the blast radius recovery options; extending retention is a systemic improvement. Option B is wrong in the context of blameless postmortems: pointing to an individual engineer's lack of attention is blame-based and does not lead to systemic improvement. Option C is explicitly blame-based and focuses on individual skill rather than systemic factors. Option D is not a realistic or actionable systemic finding — it is not grounded in the actual contributing factors.

Option A is correct because DNS TTL (Time To Live) controls how long resolvers and clients cache a record before re-querying. Pre-setting a low TTL (30–60 seconds) ensures that after a failover DNS update, clients will pick up the new record quickly. This is a best practice: lower TTL before anticipated maintenance, though it applies continuously here for disaster scenarios. Option C is correct because Cloud DNS routing policies with health checks allow Cloud DNS to automatically detect that a regional endpoint is unhealthy and serve an alternate record—this eliminates the need for manual record updates entirely and provides near-instant failover at the DNS level. Option B is wrong because the record type (A vs. CNAME) has no bearing on propagation speed; propagation is governed by TTL and resolver cache behavior. Option D is wrong because increasing TTL to 3600 seconds would make the propagation problem far worse—clients would continue using the stale (failed) IP address for up to an hour. Option E is wrong because DNSSEC provides cryptographic authentication of DNS responses for security purposes and has no mechanism to reduce propagation latency; it does not affect TTL or caching behavior.