New Year Sale 2026! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions
Mail Us support@pass4success.com
Location US
Mob_nav_barsMENU

Google Professional Cloud Architect Exam - Topic 6 Question 92 Discussion

Actual exam question for Google's Professional Cloud Architect exam
Question #: 92
Topic #: 6
[All Professional Cloud Architect Questions]

You company has a Kubernetes application that pulls messages from Pub/Sub and stores them in Firestore. Because the application is simple, it was deployed as a single pod. The infrastructure team has analyzed Pub/Sub metrics and discovered that the application cannot process the messages in real time. Most of them wait for minutes before being processed. You need to scale the elaboration process that is I/O-intensive. What should you do?

Show Suggested Answer Hide Answer
Suggested Answer: A

https://cloud.google.com/kubernetes-engine/docs/concepts/custom-and-external-metrics#external_metrics


by Omer at Sep 16, 2024, 02:22 PM

Limited Time Offer

25%

Off

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

Contribute your Thoughts:

0/2000 characters
Submit Cancel
Julene
3 months ago
Surprised that they didn't mention horizontal pod autoscaling earlier!
upvoted 0 times
...
Rebbecca
3 months ago
I’m not sure about D, it seems too specific for this scenario.
upvoted 0 times
...
Fatima
3 months ago
Wait, isn't option A also a good option?
upvoted 0 times
...
Ines
4 months ago
Totally agree, C makes the most sense here!
upvoted 0 times
...
Javier
4 months ago
I think option C is the best choice for scaling based on undelivered messages.
upvoted 0 times
...
Zoila
4 months ago
I believe option D sounds familiar, but I’m not entirely confident if setting CPU percentage is the right approach for an I/O-bound application.
upvoted 0 times
...
Filiberto
4 months ago
I vaguely recall that using the --enable-autoscaling flag is more about enabling the feature rather than configuring it based on specific metrics.
upvoted 0 times
...
Emelda
4 months ago
I think we practiced a similar question where we had to choose between different metrics for scaling. I feel like subscription/num_undelivered messages might be relevant here.
upvoted 0 times
...
Valentine
5 months ago
I remember we discussed using metrics for autoscaling, but I'm not sure which one is best for I/O-intensive tasks.
upvoted 0 times
...
Latrice
5 months ago
Wait, what's the difference between the subscription/push_request and subscription/num_undelivered message metrics? I'm not sure which one would be more appropriate for this scenario. Maybe I should just go with the kubectl autoscale command in option D to keep it simple.
upvoted 0 times
...
Vanesa
5 months ago
Okay, I've got this. The key is to use the Pub/Sub subscription/push_request metric to trigger the autoscaling. That way, the Kubernetes cluster will automatically scale up and down based on the incoming message load. Option A is the way to go.
upvoted 0 times
...
Kris
5 months ago
This seems like a straightforward Kubernetes autoscaling question. I think I'll go with option C and configure the autoscaling based on the Pub/Sub num_undelivered message metric.
upvoted 0 times
...
Wynell
5 months ago
Hmm, I'm a bit confused here. Do I need to enable autoscaling at the cluster level or can I just configure it for the specific deployment? I'll have to review the Kubernetes autoscaling documentation again.
upvoted 0 times
...
Norah
5 months ago
Hmm, I'm a bit unsure about some of the options here. I'll need to review my notes on SOAP web services to make sure I'm selecting the right standards.
upvoted 0 times
...
Anabel
1 year ago
I'm picturing the poor Kubernetes cluster trying to process all those messages like a hamster on a wheel. Option C for the win!
upvoted 0 times
...
Louvenia
1 year ago
Wait, there's a --enable-autoscaling flag? That sounds too good to be true. I'm sticking with C, it's the most straightforward way to scale based on the actual problem.
upvoted 0 times
Lashanda
1 year ago
I see your point, but I still think C is the most straightforward option to address the issue.
upvoted 0 times
...
Orville
1 year ago
I disagree, I believe D is the way to go. It allows you to configure the autoscaling parameters easily.
upvoted 0 times
...
Stephen
1 year ago
I think A is the best option, it scales based on the actual message processing metric.
upvoted 0 times
...
...
Tatum
1 year ago
Option A is tempting, but I think C is the better choice. I don't want to end up with a bunch of pods that can't keep up with the message load.
upvoted 0 times
Erinn
1 year ago
A) Configure a Kubernetes autoscaling based on the subscription/num_undelivered message metric.
upvoted 0 times
...
Tyra
1 year ago
C) Configure a Kubernetes autoscaling based on the subscription/num_undelivered message metric.
upvoted 0 times
...
Noah
1 year ago
A) Configure a Kubernetes autoscaling based on the subscription/num_undelivered message metric.
upvoted 0 times
...
...
Lizette
1 year ago
That's a good point, but I still think configuring based on the num_undelivered message metric would be more effective.
upvoted 0 times
...
Wilford
1 year ago
I disagree, I believe we should use kubectl autoscale deployment APP_NAME --max 6 --min 2 --cpu-percent 50 to configure autoscaling.
upvoted 0 times
...
Latosha
1 year ago
Haha, I bet the infrastructure team is pulling their hair out trying to keep up with all those messages! Option D looks good, but I'd probably go with C to be safe.
upvoted 0 times
Ilona
1 year ago
Yeah, it's a tough call between Option C and Option D. Both could potentially solve the issue.
upvoted 0 times
...
Tiffiny
1 year ago
I think Option D could also work well, but I see your point about going with Option C for safety.
upvoted 0 times
...
Lacey
1 year ago
I agree, the infrastructure team must be stressed out. Option C does seem like a safer choice.
upvoted 0 times
...
...
Naomi
1 year ago
Option C seems like the way to go. Scaling based on the num_undelivered message metric makes sense for an I/O-intensive application.
upvoted 0 times
Pansy
1 year ago
I agree, scaling based on the num_undelivered message metric makes perfect sense.
upvoted 0 times
...
Shaniqua
1 year ago
Option C is definitely the best choice for an I/O-intensive application.
upvoted 0 times
...
Melvin
1 year ago
C) Configure a Kubernetes autoscaling based on the subscription/num_undelivered message metric.
upvoted 0 times
...
Mica
1 year ago
A) Configure a Kubernetes autoscaling based on the subscription/num_undelivered message metric.
upvoted 0 times
...
...
Lizette
1 year ago
I think we should configure Kubernetes autoscaling based on the subscription/num_undelivered message metric.
upvoted 0 times
...

Save Cancel