Ensuring Successful Operation of a Cloud Solution practice questions

Answer: A) Pick one project as the scoping project and add the three projects as monitored projects in its metrics scope

To monitor several projects from one place, add them as monitored projects to the metrics scope of a single scoping project. That project then charts their metrics together and holds shared dashboards and alerting policies. Log sinks, per-project dashboards, and IAM grants don't combine the metrics into one view.

• ACorrect. A metrics scope sets which projects' time-series data a scoping project can chart and monitor. The scoping project holds the dashboards and alerting policies, so engineers can view metrics from all three projects in one place.
• BIncorrect. A log sink centralizes log entries, not Cloud Monitoring metrics. It doesn't let you chart the projects' metrics together or create cross-project alerting policies on them.
• CIncorrect. Identical dashboards still show each project's metrics separately, so engineers would still switch between projects and compare views by hand.
• DIncorrect. Granting IAM access lets the team open each project's metrics, but it doesn't combine those metrics into one view. A combined view requires adding the projects to a metrics scope.

Answer: A) Add an exclusion filter for those entries to the _Default sink

An exclusion filter on the sink that feeds the log bucket stops matching entries from being stored, which reduces chargeable Cloud Logging volume. Log-based metrics, extra sinks and shorter retention don't stop the unwanted entries from being ingested.

• ACorrect. Entries that match an exclusion filter on a sink aren't routed into the log bucket, so they aren't stored and don't count as chargeable log volume. All other logs keep flowing to the bucket as before.
• BIncorrect. A log-based metric turns matching entries into a monitoring time series. It doesn't stop those entries from being sent to and stored in the log bucket, so costs don't go down.
• CIncorrect. Adding a sink sends copies of matching entries to another destination. Unless they are also excluded from the _Default sink, they are still stored in the _Default bucket, and costs go up rather than down.
• DIncorrect. The retention period only controls how long stored logs are kept. The unwanted entries would still be ingested and stored, so the cost driven by their volume remains.

Answer: A) Set maintenance timing to Week 1 on the dev/test instances and Week 5 on the production instance

Cloud SQL's maintenance timing setting (gcloud --maintenance-release-channel: preview, production, week5) controls which week of the rollout each instance is updated in. Setting Week 1 for dev/test and Week 5 for production gives time to check updates before production gets them.

• AMaintenance timing (previously called order of update) sets which week of the rollout an instance is updated in. With Week 1, maintenance happens 7 to 14 days after the notification. With Week 5, it happens 35 to 42 days after, which leaves time to test on dev/test first.
• BThe maintenance window only sets the preferred day and hour for maintenance. It doesn't change which week of the rollout an instance gets the update, so production could still be updated in the same week as dev/test.
• CA deny maintenance period stops maintenance from happening during a set date range. Putting it on dev/test would delay their updates, which is the opposite of updating them first.
• DSelf-service maintenance lets you apply an available update right away, before the scheduled time. Doing this on production would update it first instead of last.

Answer: A) Connectivity Tests in Network Intelligence Center, with the alias IP address set as the destination

Connectivity Tests checks reachability to a specific endpoint, such as a new alias IP, by analyzing routes and firewall configuration and, when eligible, sending live probes. That makes it the right tool for this check.

• ACorrect. Connectivity Tests checks reachability between endpoints you specify, such as IP addresses. It traces the path against the configured routes and firewall rules. When the test is eligible, it also sends probe packets as a live data-plane check. This configuration analysis can reveal problems such as a firewall rule that does not yet allow the new address.
• BIncorrect. Performance Dashboard shows aggregate packet loss and latency between zones and regions. It does not test reachability to one specific IP address.
• CIncorrect. Network Topology shows a graph of resources and traffic between them. It does not trace a specific source-to-destination path through routes and firewall rules.
• DIncorrect. Firewall Insights finds shadowed, unused, or overly permissive firewall rules. It does not test whether a given destination IP address is reachable.

Answer: A) Create a lowest-priority deny-all ingress rule with Firewall Rules Logging enabled, then review its log entries for denied connections

The implied deny ingress rule can't be logged, so to see traffic that a deleted allow rule used to permit, add a logged, low-priority deny-all ingress rule and review its denied entries.

• ACorrect. Firewall Rules Logging does not cover the implied deny ingress rule, so blocked traffic would otherwise leave no log entry. A low-priority deny-all ingress rule (for example, priority 65534) with logging enabled records denied connection attempts. That shows whether anything legitimate still depended on the removed rule.
• BIncorrect. Firewall Rules Logging is not supported for the implied deny ingress and implied allow egress rules, so this can't be configured. The team needs an explicit deny rule with logging enabled.
• CIncorrect. A deleted rule naturally drops out of Firewall Insights. Its absence says nothing about whether legitimate traffic is now being blocked.
• DIncorrect. Admin Activity audit logs record who deleted the rule and when. They don't record data-plane connections, so they can't show whether traffic is being denied.

Answer: A) A Cloud Monitoring alerting policy with a metric-threshold condition

To get automatic notifications when a metric stays above a threshold for a set time, create a Cloud Monitoring alerting policy with a metric-threshold condition and notification channels. Uptime checks, dashboards and budget alerts do not cover this case.

• AA metric-threshold condition is met when a metric stays above or below a threshold for a set duration, called the retest window. When the condition is met, the alerting policy sends notifications to its notification channels, such as email and Slack.
• BUptime checks send periodic HTTP, HTTPS or TCP requests to test whether a URL or resource is available. They do not evaluate CPU utilization against a threshold.
• CA dashboard can show CPU utilization against a threshold, but it does not send notifications. Someone would have to keep watching the chart to notice the problem.
• DBudget threshold rules send email when actual or forecasted spend passes a percentage of the budget. They track cost, not resource metrics like CPU utilization.

Answer: A) Set the job's time zone to UTC and change the cron hour so the run happens at the matching UTC time

Cloud Scheduler runs on wall-clock time, so DST in the configured time zone can disrupt a job's cadence. For strict 24-hour spacing, Google recommends setting the job to UTC.

• ACorrect. Cloud Scheduler evaluates schedules on wall-clock time in the configured time zone, so DST transitions can cause unexpected runs. Google recommends a time zone without DST, specifically UTC, when a job needs a very specific cadence.
• BIncorrect. Retry settings only control what happens after a failed attempt. They don't change when the schedule fires, so the DST-related cadence problem remains.
• CIncorrect. The job's location doesn't decide how the schedule is evaluated. The configured time zone does, and America/Chicago would still observe DST.
• DIncorrect. The attempt deadline limits how long a single attempt may run. It has no effect on when runs are scheduled across a DST transition.

Answer: A) Run a PITR to a specific recent timestamp, which creates a new instance, and validate that its data matches the expected state at that time

The only way to show that Cloud SQL PITR works is to perform one. A periodic PITR to a new instance at a chosen timestamp, followed by checking the data, validates recovery. Configuration checks and storage metrics don't.

• ACorrect. In Cloud SQL, PITR restores a backup and replays binary logs into a new instance at the chosen timestamp. Running this regularly and checking the recovered data confirms the whole recovery path works without touching production.
• BIncorrect. This confirms the prerequisites are still in place, but it doesn't show that a restore succeeds or that the recovered data is correct.
• CIncorrect. Restoring over production overwrites live data, which is risky. A backup restore also returns the instance only to the backup time and doesn't test binary log replay to an arbitrary point in time.
• DIncorrect. Growing storage suggests logs are being written, but it doesn't show that the logs and backups can actually be used to recover a correct database state.

Answer: A) Error Reporting, which sorts error events into error groups

Error Reporting automatically groups similar error events, using exception type, stack frames and message, and shows their counts in one place. Log-based metrics need filters you define, and Trace and Profiler measure performance, not errors.

• ACorrect. Error Reporting collects application error events and puts them into error groups. It groups them by exception type, the topmost stack frames, and the message, then shows each group's occurrence counts and timeline in one view.
• BIncorrect. A counter metric counts the log entries that match a filter you write yourself. It doesn't automatically sort different exceptions into groups by similarity.
• CIncorrect. Cloud Trace records latency data for requests as they pass through services. It's built for finding performance bottlenecks, not for grouping exceptions by their stack traces.
• DIncorrect. Cloud Profiler shows which functions use the most CPU or memory. It doesn't collect or group the exceptions an application throws.

Answer: A) Update that node pool with --workload-metadata=GKE_METADATA so its Pods use the GKE metadata server

After you enable Workload Identity Federation for GKE on a cluster, each node pool must run with --workload-metadata=GKE_METADATA. Otherwise its Pods keep getting the node service account's credentials from the Compute Engine metadata server.

• ACorrect. Enabling Workload Identity Federation at the cluster level doesn't move existing node pools to the GKE metadata server. Until a node pool runs with GKE_METADATA, its Pods can reach the Compute Engine metadata server and get the node service account's credentials. With GKE_METADATA, the GKE metadata server intercepts these requests and returns credentials for the Pod's Kubernetes ServiceAccount.
• BIncorrect. This gets the relationship backwards and gives the node identity more power. It doesn't stop Pods from reaching the Compute Engine metadata server, so they would keep using the node's credentials.
• CIncorrect. The workload pool is already set on the cluster. Running the cluster-level command again doesn't change the metadata mode of an existing node pool. You have to update the node pool itself.
• DIncorrect. Access scopes only limit what the node's Compute Engine service account can do. Setting them to cloud-platform makes the node identity broader and has no effect on how Pod credential requests are handled.