You use a multiple step Cloud Build pipeline to build and deploy your application to Google Kubernetes Engine (GKE). You want to integrate with a third-party monitoring platform by performing a HTTP POST of the build information to a webhook. You want to minimize the development effort. What should you do?
The most efficient way to integrate a third-party monitoring platform by performing an HTTP POST of the build information to a webhook is to add a new step at the end of the pipeline in Cloud Build. This approach keeps the implementation straightforward and centralized, minimizing development efforts by ensuring that the HTTP POST action occurs after the completion of the build process in a single place, rather than setting up separate services or more complex subscription models.
Ans: D Pub/Sub A: No becauseThere is not Structure attribute to create a http request in the steps and remember you want minimize the development effort. B: The same A C: minimize the development effort D: Its OK To receive messages from push subscriptions, use a webhook and process the POST requests that Pub/Sub sends to the push endpoint. For more information about processing these POST requests in App Engine, see Writing and responding to Pub/Sub messages. https://cloud.google.com/pubsub/docs/push https://cloud.google.com/build/docs/subscribe-build-notifications
I have submitted D answer
D is the answer. https://cloud.google.com/build/docs/subscribe-build-notifications Cloud Build publishes messages on a Google Pub/Sub topic when your build's state changes, such as when your build is created, when your build transitions to a working state, and when your build completes. The Pub/Sub topic to which Cloud Build publishes these build update messages is called cloud-builds. Each message contains a base64 JSON string representation of your Build resource in the message.data attribute. The build's unique ID and the build's status can be found in the message.attributes field. You can use a push or pull model for your Pub/Sub subscriptions. https://cloud.google.com/build/docs/subscribe-build-notifications#push Push subscriptions deliver messages to an HTTP endpoint that you define. Messages are delivered as soon as they are published to the topic.
Yes, D is right based on given scenario
Not sure on D. Pub/Sub posts into specific format and the actual payload in is message.data. Third party system API (where you post status) will have its own POST format. I feel B is better - you add a step in CLoud Build to do the POST.
D is correct answer https://cloud.google.com/build/docs/subscribe-build-notifications
Agree D looks correct to me.
Cloud Build -> Pubsub -> HTTP Builder.........SO ans is D
Ans: D
no idea on this
Its D. Cloud Build -> Pubsub -> HTTP Builder
Ans : D
Submitted D in exam.
Ans: D
Answer D
A is correct because Easy to implement and not correct because Scalable but complex
A is correct because Easy to implement and D is not correct because Scalable but complex