From the question the key point is "upload ANY NEW medical images to Cloud Storage". So we are not interested in old images. That's why we need some trigger that will upload images. I think option "A" with PubSub is the best

C. Create a script that uses the gsutil command line interface to synchronize the on-premises storage with Cloud Storage. Schedule the script as a cron job.

A. Pub/Sub Topic with Cloud Storage Trigger: While Cloud Pub/Sub is great for event-driven architectures, it's not directly applicable for file synchronization scenarios. It would also require substantial modification to the existing infrastructure to send images to Pub/Sub. B. Dataflow Job: Dataflow is a powerful service for stream and batch data processing, but using it solely for file synchronization is overkill. It also requires more setup and maintenance compared to a simple gsutil script. D. Manual Upload in Cloud Console: This is not feasible for an automated process, as it requires manual intervention and isn’t practical for a large number of files.

I am also for A. Any new data should be send to Cloud Storage. Yes you need to create an application. To send data to pubsub. But for possible migration to cloud you can use the existing setup

C is the right answer as they want the automated process to upload any new medical image

C is correct. A will not work because pub/sub is meant for service to service communication only: https://cloud.google.com/pubsub/docs/overview#compare_service-to-service_and_service-to-client_communication Yes C option will sync any new images from onprem to cloud.

New images can use Pub/Sub

C is the correct answer. Keyword, they require cloud storage for archival and the want to automate the process to upload new medical image to cloud storage, hence we go for gsutil to copy on-prem images to cloud storage and automate the process via cron job. whereas Pub/Sub listens to the changes in the Cloud Storage bucket and triggers the pub/sub topic, which is not required.

The Hospital wants Cloud storage for archival of old images and also sync the new images, for this logic the answer is C

C is correct

C is correct.

Discarding (A) because "Cloud Storage trigger". So for option A the triggering event should be making a change in Cloud Storage, while in the real use case, the triggering should be adding a new medical image to the "on-premises data room"

I would go with C Not A, don’t think you can send image files to Pub/Sub. Technically you can do so by converting image to some binary text, but then we don’t know the size of the image and there is a limitation on message size. Not recommended. Not B – there is only this template “Datastore to Cloud Storage Text”, as the name implies it is for text, https://cloud.google.com/dataflow/docs/guides/templates/provided-batch#datastore-to-cloud-storage-text, and it reads from datastore which is definitely not where the medical images are stored, from the question “… stores its medical images in an on-premises data room”. Not D – it’s not automated

Pub/Sub could make sense if you ignore the size limit. But the way it is described with the storage trigger would just not be working.

A is correct. The key is automation whenever there is a new image, it needs to upload to cloud storage. Only pub/sub can make the automation work.

I think A(once the hospital receive the new images Cloud pub/sub will act on it) and C(creating a script with rsync command https://stackoverflow.com/questions/37662416/how-to-sync-a-local-folder-with-a-folder-in-a-google-cloud-platform-bucket) must be the Correct options

" any new medical images" so "A" using Pub\Sub