Exam Professional Cloud Developer All QuestionsBrowse all questions from this exam
Go to Exam
Question 94

You need to redesign the ingestion of audit events from your authentication service to allow it to handle a large increase in traffic. Currently, the audit service and the authentication system run in the same Compute Engine virtual machine. You plan to use the following Google Cloud tools in the new architecture:

✑ Multiple Compute Engine machines, each running an instance of the authentication service

✑ Multiple Compute Engine machines, each running an instance of the audit service

✑ Pub/Sub to send the events from the authentication services.

How should you set up the topics and subscriptions to ensure that the system can handle a large volume of messages and can scale efficiently?

    Correct Answer: A

    Create one Pub/Sub topic. Create one pull subscription to allow the audit services to share the messages. This setup ensures that messages are distributed among multiple audit service instances efficiently and allows the system to scale horizontally. Each audit service can pull messages from the same subscription, which helps to handle a large volume of messages without creating a bottleneck. This approach simplifies the management of topics and subscriptions while providing the required scalability.

Discussion
gfr892Option: A

https://cloud.google.com/pubsub/docs/subscriber "Multiple subscribers can make pull calls to the same "shared" subscription. Each subscriber will receive a subset of the messages." Response is A. With C and D you can't scale efficiently, because you have to create a topic for each new instance of the authentication service.

akshaychavan7

This seems to be a smart answer and follows the logic with which I was thinking.

telpOption: A

A is correct. This is the most flexible way to scale, allowing the authentication and audit services to be sized independently according to load. B is incorrect. This will cause messages to be duplicated, one copy per subscription. C is incorrect. This will allow the system to scale, but push subscriptions are less suited to handle large volumes of messages. D is incorrect. This will allow the system to scale, however each audit service will listen to all subscriptions. E. is incorrect. This will allow the system to scale, however it will require each audit service to listen to all subscriptions. Also push subscriptions are less suited to handle large volumes of messages.

tomato123Option: A

A is correct I think

scaenruyOption: C

I vote C

ParagSanyashivOption: D

Agree with D

thewalkerOption: C

The best approach here is C. Create one Pub/Sub topic. Create one push subscription with the endpoint pointing to a load balancer in front of the audit services. Here's why: Scalability: A single Pub/Sub topic allows you to centralize all audit events. This makes it easy to scale the authentication services by adding more instances without needing to change the Pub/Sub configuration. Load Balancing: Using a push subscription with a load balancer in front of the audit services ensures that the incoming messages are distributed evenly across the available audit service instances. This prevents any single instance from becoming overloaded. Efficiency: Push subscriptions are more efficient than pull subscriptions for high-volume scenarios. This is because the Pub/Sub service actively pushes messages to the subscribers, reducing the need for the audit services to constantly poll for new messages.

thewalker

Why other options are less ideal: A. Create one Pub/Sub topic. Create one pull subscription to allow the audit services to share the messages. This would create a bottleneck at the single pull subscription, as all audit services would need to compete for messages. B. Create one Pub/Sub topic. Create one pull subscription per audit service instance to allow the services to share the messages. This would be less efficient than push subscriptions and could lead to uneven message distribution. D. Create one Pub/Sub topic per authentication service. Create one pull subscription per topic to be used by one audit service. This would require a lot of topics and subscriptions, making the system more complex to manage. E. Create one Pub/Sub topic per authentication service. Create one push subscription per topic, with the endpoint pointing to one audit service. This would create a one-to-one relationship between authentication services and audit services, which is not scalable.

AeglasOption: A

Most simple and efficient one is A

braskaOption: E

Option E is a more scalable and efficient solution for handling a large volume of messages and scaling efficiently.

RajanOption: A

I would go with A.

YochenOption: C

In my opinion, Option C would be the most efficient way to handle the scenario. Here's why: Single Topic: Having one Pub/Sub topic keeps things simpler and allows all authentication service instances to publish to the same topic. Push Subscription with Load Balancer: This allows incoming messages to be distributed among all available audit service instances. The load balancer would handle distributing the load, making it easier for the audit service to scale out as needed. Option C ensures both scalability and efficient handling of a large volume of messages.

closer89Option: A

i go for A + custom pubsub metric on autoscale

omermahgoubOption: E

Answer is E, in which there is one topic per authentication service and one push subscription per topic, with the endpoint pointing to one audit service, is a better option because it allows the audit services to scale horizontally to handle a large volume of messages, and it allows the messages to be processed in parallel. Each authentication service will send messages directly to its own topic, which will be handled by a specific audit service. This will ensure that the system can scale horizontally to handle a large volume of messages, and it will also allow the audit services to process the messages in parallel.

omermahgoub

A, in which there is only one topic and one pull subscription, would not allow the audit services to scale horizontally to handle a large volume of messages, as they would all be pulling messages from the same subscription. If the volume of messages increased, the audit services would not be able to process them all in a timely manner, as they would be competing for messages from the same subscription. B, in which there is only one topic and one pull subscription per audit service, would also not allow the audit services to scale horizontally, as they would all be pulling messages from the same topic

omermahgoub

D, in which there is one topic per authentication service and one pull subscription per topic, you may encounter issues with scaling efficiently as the number of authentication service instances increases. This is because you would have to create a new topic for each new instance of the authentication service, and each audit service would have to pull messages from a different topic. This would not allow the audit services to process the messages in parallel, as each audit service would be pulling messages from a different topic and processing them sequentially. This could lead to bottlenecks if the volume of messages increased.

omermahgoub

C, in which there is only one topic and one push subscription with a load balancer endpoint, would not allow the audit services to scale horizontally to handle a large volume of messages. The messages would all be sent to the same endpoint, which would be handled by the load balancer. If the volume of messages increased, the load balancer would not be able to distribute the messages to the audit services in a timely manner, as it would have to process all of the messages itself before forwarding them to the audit services. This could lead to bottlenecks if the volume of messages increased.

zellckOption: A

A is the answer.

BlueoceanOption: D

While this can be between C and D , I would go with Option D considering the large volume mentioned in question