the config sync is like config repository which means f5 devices in the Device Group will store shared data replica (e.g. floating ip, virtual server config but not self (static) ip)
so for example if a device is corrupt and you deply new device, then the new device can simply get the shared config by joining the device group.

vip can be shared (in active-standby mode) only if the devices can have Self IP and Floating IP in Traffic Group (basically same IP subnet; in addition to joining same Device Group).

there is workaround to allow separate traffic group to use same VIP using OSPF/BGP and LTM VS RHI method but i think it's not necessary in your case because the upfront GCP LB will load balance both F5 LBs.
https://techdocs.f5.com/en-us/bigip-14-1-0/big-ip-tmos-routing-administration-14-1-0/dynamic-routing.html#GUID-7CDA4A41-3148-4D5F-B031-45E14190398E

It appears that the only documentation we have is for a configsync in an active/active dual zone environment:

http://clouddocs.f5.com/cloud/public/v1/google/Google_configsync.html

https://clouddocs.f5.com/cloud/public/v1/google_index.html

for 

Active/Active ScaleN Clustering Exercise

refer below link:

https://clouddocs.f5.com/training/community/adc/html/class2/module1/lab1.html

https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-device-service-clustering-admin-11-6-0/10.html

HTH

🙏

thanks for the reply - the github configuration -  and deployment of F5s is extremely complex to figure out . if the only advantage of have a config sync between the 2 F5s is to have "Some components" in sync then it would be easier to do it with CICD - 

woudd both F5s have the same IP for a VP?