Google Professional Cloud Architect Exam - Topic 4 Question 87 Discussion

Actual exam question for Google's Professional Cloud Architect exam

Question #: 87
Topic #: 4

[All Professional Cloud Architect Questions]

You have an application that runs in Google Kubernetes Engine (GKE). Over the last 2 weeks, customers have reported that a specific part of the application returns errors very frequently. You currently have no logging or monitoring solution enabled on your GKE cluster. You want to diagnose the problem, but you have not been able to replicate the issue. You want to cause minimal disruption to the application. What should you do?

A1. Update your GKE cluster to use Cloud Operations for GKE.
2. Use the GKE Monitoring dashboard to investigate logs from affected Pods.

B1. Create a new GKE cluster with Cloud Operations for GKE enabled.
2. Migrate the affected Pods to the new cluster, and redirect traffic for those Pods to the new cluster.
3. Use the GKE Monitoring dashboard to investigate logs from affected Pods.

C1. Update your GKE cluster to use Cloud Operations for GKE, and deploy Prometheus.
2. Set an alert to trigger whenever the application returns an error.

D1. Create a new GKE cluster with Cloud Operations for GKE enabled, and deploy Prometheus.
2. Migrate the affected Pods to the new cluster, and redirect traffic for those Pods to the new cluster.
3. Set an alert to trigger whenever the application returns an error.

Show Suggested Answer

Suggested Answer: B

The practice for managing logs generated on Compute Engine on Google Cloud is to install the Cloud Logging agent and send them to Cloud Logging.

The sent logs will be aggregated into a Cloud Logging sink and exported to Cloud Storage.

The reason for using Cloud Storage as the destination for the logs is that the requirement in question requires setting up a lifecycle based on the storage period.

In this case, the log will be used for active queries for 30 days after it is saved, but after that, it needs to be stored for a longer period of time for auditing purposes.

If the data is to be used for active queries, we can use BigQuery's Cloud Storage data query feature and move the data past 30 days to Coldline to build a cost-optimal solution.

Therefore, the correct answer is as follows

1. Install the Cloud Logging agent on all instances.

Create a sync that exports the logs to the region's Cloud Storage bucket.

3. Create an Object Lifecycle rule to move the files to the Coldline Cloud Storage bucket after one month. 4.

4. set up a bucket-level retention policy using bucket locking.'

by Cherrie at Jul 05, 2024, 03:24 AM

Limited Time Offer

25%

Off

Get Premium Professional Cloud Architect Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

Submit Cancel

Carrol

3 months ago

I agree with C, but I'm surprised they haven't set up logging yet!

upvoted 0 times

...

Jacquline

3 months ago

Wait, can you really just migrate Pods like that?

upvoted 0 times

...

Armando

4 months ago

Why create a new cluster? Seems like overkill.

upvoted 0 times

...

Lanie

4 months ago

I think option C is the best choice here!

upvoted 0 times

...

Maira

4 months ago

Sounds like a logging issue, definitely need to enable monitoring.

upvoted 0 times

...

Cary

4 months ago

I'm leaning towards option D because it seems like a more comprehensive solution, but I'm not entirely confident about migrating Pods to a new cluster.

upvoted 0 times

...

Michel

5 months ago

I practiced a similar question where we had to set alerts for errors. I feel like option C might be the best approach for proactive monitoring.

upvoted 0 times

...

Marylyn

5 months ago

I think option A sounds familiar, but I wonder if just updating the existing cluster is enough to diagnose the issue.

upvoted 0 times

...

Catarina

5 months ago

I remember we discussed the importance of monitoring in GKE, but I'm not sure if creating a new cluster is necessary.

upvoted 0 times

...

Wendell

5 months ago

Okay, I think I've got it. The key is to minimize disruption, so option A looks like the best choice. Update the existing cluster to use Cloud Operations, then use the monitoring dashboard to dig into the logs and find the root cause. Simple and straightforward.

upvoted 0 times

...

Karrie

5 months ago

I'm a bit confused by all the options here. It's not clear to me why we'd need to create a whole new cluster in options B and D. Wouldn't that be a lot more disruptive than just updating the existing one? I'll need to think through the tradeoffs carefully.

upvoted 0 times

...

Vicente

5 months ago

This seems like a tricky issue, but I think I have a good strategy. I'll start by looking at option A - it seems like the simplest approach, just updating the existing cluster to use Cloud Operations. That should give me the logging and monitoring I need to investigate the problem.

upvoted 0 times

...

Kerry

5 months ago

I'm feeling pretty confident about this one. Option C seems like the way to go - update the cluster to use Cloud Operations, and also deploy Prometheus to get even more visibility. Setting an alert will help us stay on top of the issue going forward. Solid plan.

upvoted 0 times

...

Paz

5 months ago

Okay, let's see... I think the key is understanding what the "alias" command does in the shell.

upvoted 0 times

...

Lawrence

5 months ago

This looks like a tricky question. I'll need to carefully read through the requirements and the provided code to make sure I understand the problem before attempting a solution.

upvoted 0 times

...

Pearlene

10 months ago

Option D sounds like a job for the 'Kubernetes Extreme Makeover' team. I hope they remember to leave the application's favorite snacks in the new cluster.

upvoted 0 times

...

Hector

10 months ago

Option A? More like Option 'Ah, the simple life'! I'm all about that low-maintenance approach.

upvoted 0 times

...

Farrah

10 months ago

Option D seems like overkill. Creating a new cluster and migrating Pods just to enable Prometheus and set an alert seems like it would cause a lot of disruption to the application.

upvoted 0 times

Demetra

8 months ago

B) Create a new GKE cluster with Cloud Operations for GKE enabled. Migrate the affected Pods to the new cluster, and redirect traffic for those Pods to the new cluster. Use the GKE Monitoring dashboard to investigate logs from affected Pods.

upvoted 0 times

...

Alica

9 months ago

A) That sounds like a better approach. Option D does seem like it would cause too much disruption.

upvoted 0 times

...

Telma

9 months ago

C) Update your GKE cluster to use Cloud Operations for GKE, and deploy Prometheus. Set an alert to trigger whenever the application returns an error.

upvoted 0 times

...

Dorthy

9 months ago

A) Update your GKE cluster to use Cloud Operations for GKE. Use the GKE Monitoring dashboard to investigate logs from affected Pods.

upvoted 0 times

...

Maile

10 months ago

I'm a bit skeptical about Option C. Deploying Prometheus on the existing cluster might introduce more complexity than necessary, and setting an alert seems like a reactive approach.

upvoted 0 times

Tyra

8 months ago

A) Update your GKE cluster to use Cloud Operations for GKE. Use the GKE Monitoring dashboard to investigate logs from affected Pods.

upvoted 0 times

...

Maile

8 months ago

upvoted 0 times

...

Ceola

9 months ago

A) Update your GKE cluster to use Cloud Operations for GKE. Use the GKE Monitoring dashboard to investigate logs from affected Pods.

upvoted 0 times

...

Melina

10 months ago

Option B gives me more confidence in identifying the root cause by migrating the affected Pods to a new cluster. The additional monitoring capabilities with Prometheus could be really helpful too.

upvoted 0 times

Craig

9 months ago

It's important to diagnose the problem without disrupting the application too much. Option B seems like a good balance.

upvoted 0 times

...

Johana

9 months ago

I agree. Having the additional monitoring capabilities with Prometheus can provide more insights into what's causing the errors.

upvoted 0 times

...

Alysa

10 months ago

Option B sounds like a good plan. Migrating the affected Pods to a new cluster could help isolate the issue.

upvoted 0 times

...

Rozella

10 months ago

Option A seems like the easiest solution to diagnose the issue without disrupting the application. I like how it leverages the GKE Monitoring dashboard to investigate the logs.

upvoted 0 times

...