Professional Cloud Architect

Answer: D. Use separate backend pools for each API path behind the load balancer
This is the correct option because:
learns-google.blogspot.com
It maintains a single entry point with existing SSL/DNS
Allows path-based routing to direct traffic appropriately
Requires no client reconfiguration
Provides clean separation between versions
Follows common API versioning patterns

D is the answer because HTTP(S) load balancer can direct traffic reaching a single IP to different backends based on the incoming URL. A is not correct because configuring a new load balancer would require a new or different SSL and DNS records which conflicts with the requirements to keep the same SSL and DNS records. B is not correct because it goes against the requirements. The company wants to keep the old API available while new customers and testers try the new API. C is not correct because it is not a requirement to decommission the implementation behind the old API. Moreover, it introduces unnecessary risk in case bugs or incompatibilities are discovered in the new API.

Selected Answer: D
I need to perform the Google Architect Renew. There's a Google release of one Architect certification called "Professional Cloud Architect Renewal." I would like to know if the Google Architect certification available on this site covers these renewal questions. Thanks in advance.

https://docs.google.com/document/d/1VV6vkkjShXDgPLSG6V_7-0dweLmZTUnYiTSxo6C5ERY/edit?tab=t.0

Selected Answer: D
I need to perform the Google Architect Renew. There's a Google release of one Architect certification called "Professional Cloud Architect Renewal." I would like to know if the Google Architect certification available on this site covers these renewal questions. Thanks in advance.

https://services.google.com/fh/files/misc/pca_renewal_exam_overview_and_faqs.pdf

CQ

Selected Answer: D
Answer is D.
Using a HTTPS load balancer for different backend makes sense as we dont want to disturb the old API setup and also want to test new API

Selected Answer: D
Can anybody tell if these here question are still in the current exam?

Selected Answer: D
D is good for keep the same records.

Selected Answer: D
Using separate backend pools for each API version behind a single load balancer fulfills all requirements:

Single SSL and DNS Endpoint:

Both API versions share the same SSL certificate and DNS records, so users and developers don’t need to reconfigure their endpoints.
The load balancer handles routing transparently.
Separation of APIs:

Different backend pools allow for clear segregation between the old and new API versions.
Each API can be deployed, updated, and scaled independently.
Traffic Management:

The load balancer can route traffic based on request paths (e.g., /v1 for the old API and /v2 for the new API).
This allows smooth coexistence of the APIs while developers gradually adopt the new version.

Selected Answer: D
You have to split the traffic

Answer: D. Use separate backend pools for each API path behind the load balancer
This is the correct option because:

It maintains a single entry point with existing SSL/DNS
Allows path-based routing to direct traffic appropriately
Requires no client reconfiguration
Provides clean separation between versions
Follows common API versioning patterns

The best answer here is D. Use separate backend pools for each API path behind the load balancer.

Here's why:

* Maintaining the same DNS and SSL records: This requirement implies that both API versions need to be accessible through the same domain and endpoint.
* Separate backend pools: By using separate backend pools for each API version, the load balancer can direct traffic to the appropriate servers based on the request path. This allows for seamless co-existence of both versions without any conflict.
* Flexibility and Control: This approach provides flexibility in managing traffic, allowing you to gradually shift users to the new API or run A/B testing.

You have a Compute Engine managed instance group that adds and removes Compute Engine instances from the group in response to the load on your application.The instances have a shutdown script that removes REDIS database entries associated with the instance.You see that many database entries have not been removed, and you suspect that the shutdown script is the problem.You need to ensure that the commands in the shutdown script are run reliably every time an instance is shut down. You create a Cloud Function to remove the database entries.What should you do next?
A.
Modify the shutdown script to wait for 30 seconds and then publish a message to a Pub/Sub queue.
B.
Modify the shutdown script to wait for 30 seconds before triggering the Cloud Function.
C.
Set up a Cloud Monitoring sink that triggers the Cloud Function after an instance removal log message arrives in Cloud logging
D.
Do not use the Cloud Function. Modify the shutdown script to restart if it has not completed in 30 seconds. 

what is your answer?

C.
Use the Cloud Storage Signed URL feature to generate a POST URL

A, The Cross Origin Resource Sharing (CORS) spec was developed by the World Wide Web Consortium (W3C) to remove the limit of Same Origin Policy. Cloud Storage supports this specification by allowing you to configure your buckets to support CORS. 
 https://cloud.google.com/storage/docs/cross-origin

Then for authentication I'll go with signed URL feature, it gives more security

Option D seems to be the right one..
cloud.google.com/network-connectivity/docs/vpn/concepts/topologies#to_peer_vpn_gateways

I think it should be A. refer to the documentation, to have HA 99.99%, it needs at least 2 tunnels. And one HA VPN with one peer VPN could have 2 tunnels. In Google Cloud, the REDUNDANCY_TYPE for this configuration takes the value SINGLE_IP_INTERNALLY_REDUNDANT.
D. not cost optimized
B. didn't mention 2 tunnels
C. not simple

Selected Answer: D
D because This approach allows you to keep the same SSL and DNS records while directing traffic based on the API path. The load balancer can be configured to route requests to different backend pools depending on whether the request is for the old or new API version. This ensures that both versions are accessible under the same domain, providing a seamless transition for both old and new users.

Selected Answer: D
D is the right answer.

Selected Answer: D
Obvious.... split the feed

The correct answer is D as visually explained in the HTTPS Load Balancer architecture infographic (figure 5.5) at page 225 in the "GCP Professional Cloud Network Engineer Certification Companion" book.

Selected Answer: D
The correct answer is D:

Selected Answer: D
The correct answer is D: 

Explanation: 
Option D, using separate backend pools for each API path behind the load balancer, allows traffic to be routed to the appropriate backend based on the API path. This ensures that the old and new APIs can coexist and be independently deployable while sharing the same SSL and DNS records. It provides isolation and simplifies the management of the two versions.
Therefore, option D is the recommended approach to achieve the desired outcome of keeping the old API available and deployable while allowing new customers and testers to try out the new API.

Selected Answer: D
The question states that the company needs to keep the old version of the API available and deployable, while allowing new customers and testers to try out the new API. They want to keep the same SSL and DNS records in place to serve both APIs.
Using a separate backend pool for each API path behind the load balancer will allow the company to keep the old version of the API available and deployable, while allowing new customers and testers to try out the new API. This is because the load balancer will be able to route traffic to the appropriate backend pool based on the path.

D. Use separate backend pools for each API path behind the load balancer

To keep the old version of the API available and deployable while allowing new customers and testers to try out the new API, while also keeping the same SSL and DNS records in place, your company can use separate backend pools for each API path behind the load balancer. This will allow them to route traffic to the appropriate backend pool based on the path, allowing them to serve both the old and new versions of the API using the same load balancer and DNS records.

Other options, such as configuring a new load balancer for the new version of the API or reconfiguring old clients to use a new endpoint for the new API, may not allow them to keep the same SSL and DNS records in place. Forwarding traffic to the new API based on the path may not provide a reliable way to separate the two APIs.

Selected Answer: D
D. Use separate backend pools for each API path behind the load balancer

D... while allowing new customers and testers to try out the new API. They want to keep the same SSL and DNS records in place to serve both APIs.

D. Use separate backend pools for each API path behind the load balancer.

vote D
key point is :
They want to keep the same SSL and DNS records in place to serve both APIs.

Selected Answer: D
D is the correct answer.

Selected Answer: D
D is the answer because HTTP(S) load balancer can direct traffic reaching a single IP to different backends based on the incoming URL.

Selected Answer: D
Because they want to have the same SSL and DNS

D is correct which can be combined with cloud native load balancer like traefik for Cananry, A/B testing to redirect % traffic to old & new API for testing

D. Use separate backend pools for each API path behind the load balancer

D is the answer because HTTP(S) load balancer can direct traffic reaching a single IP to different backends based on the incoming URL.

For all other options there will not be same SSL and DNS configration for both working APIs.

I will go with D.
A does not seem right because the requirement is to use the same SSL and DNS entries for both APIs.
B does not seem right because it would mean changing old client code.
C does not seem right because it would mean modifying the old API.
D makes the most sense because a path-based decision would require SSL and DNS changes and wouldn't require changes to old clients and the old API code.

DNS has nothing to do with path-based forwarding. With path-based forwarding, the hostname (which DNS resolution is based on) does not change.

D is ok
C is incorrect. LB can't forward any traffic based on path as DNS is not changing.

Options "A", "B", and "C" would change the availability of the old API. Preventing traffic from flowing through it, option "D" mentions load balancer which in Google's marketing context implies traffic to both APIs.

Your company has decided to make a major revision of their API in order to create better experiences for their developers. They need to keep the old version of the API available and deployable, while allowing new customers and testers to try out the new API. They want to keep the same SSL and DNS records in place to serve both APIs.
What should they do?

Access scopes are the legacy method of specifying permissions for your instance. read from > https://cloud.google.com/compute/docs/access/service-accounts . So , I would go with C

agreed to comment here . C seems like a good option

agree
access scope is enabled by default
https://cloud.google.com/bigquery/docs/authorization#authenticate_with_oauth_20

 If you use the BigQuery client libraries, you do not need this information, as this is done for you automatically.

A - If client library was not installed, the python scripts won't run - since the question states the script reports "cannot connect" - the client library must have been installed. so it's B or C.

B - https://cloud.google.com/bigquery/docs/authorization an access scope is how your client application retrieve access_token with access permission in OAuth when you want to access services via API call - in this case, it is possible that the python script use an API call instead of library, if this is true, then access scope is required. client library requires no access scope (as it does not go through OAuth)

C - service account is Google Cloud's best practice
So prefer C.

Configure the Python API to use a service account with relevant BigQuery access enabled. is the right answer.

It is likely that this service account this script is running under does not have the permissions to connect to BigQuery and that could be causing issues. You can prevent these by using a service account that has the necessary roles to access BigQuery.

Ref: https://cloud.google.com/bigquery/docs/reference/libraries#cloud-console

A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person.

Ref: https://cloud.google.com/iam/docs/service-accounts

Sorry, B is ok. You can create service account, add user to service account, and grant the user role as Service Account User. You still need to enable BigQuery scope to make the Python script running the instance to access BigQuery.

Create a new service account with BigQuery access and execute your script with that user: If you want to run the script on an existing virtual machine, you can create a new service account with the necessary permissions to access BigQuery and then execute the script using that service account. This will allow the script to connect to BigQuery and access the data it needs.

I stand corrected, B you need to have scope. It is union of Scope + Service Account. If scope is not there, you are screwed anyways.

C, no brainer. You need SA for using API period. Thats where your start your troubleshooting.

Selected Answer: B
Google Compute Engine instances have access scopes that control which Google Cloud services they can interact with.

Selected Answer: C
A & D does not deal about connection
C : is mandatory for security reason
B : could be true but here is always a "default" scope. And the error message is about connection not access. And it is for OAuth2 which we do not know if the python script uses it.

Selected Answer: B
This is obviously a really old question. The best answer is B. Here's why:

- There was a time when you couldn't update access scopes on a VM and had to create a new one if the scopes needed to change (which was painful).
- Without access scopes enabled, Google will block access to those APIs, so a new service account isn't enough, even if IAM was a problem.
- The question just says that the script 'cannot connect' to BQ - it doesn't mention permissions.

Selected Answer: B
Actually the correct answer is B, reason is , you need to define the scope first, service accounts comes later.

Selected Answer: C
A and C are correct, but we eliminated A because they mentioned "cannot connect" which means the script can run which means the client library was already installed, so final answer is only "C"

"C" was chosen because in order to access BigQuery, the script needs to authenticate and be authorized. The recommended way to do this for applications running on Compute Engine is to use a service account. Create a service account with the appropriate permissions (e.g., "BigQuery Data Editor") to access your BigQuery data. When running the script, make sure it uses the service account credentials to authenticate. This can be done by setting the GOOGLE_APPLICATION_CREDENTIALS environment variable to the path of the service account key file.

run script on a new vm, not create a new vm..

I suppose all of them are correct, but we should choose the least effort, B is correct..

Selected Answer: C
Tricky question.
However, as you can read in gcloud compute instances create documentation:
--scopes=[SCOPE,…]
If not provided, the instance will be assigned the default scopes, described below. However, if neither --scopes nor --no-scopes are specified and the project has no default service account, then the instance will be created with no scopes. Note that the level of access that a service account has is determined by a combination of access scopes and IAM roles so you must configure both access scopes and IAM roles for the service account to work properly.

So, probably, B is the right one, as for the "new vm", I guess that this is because you don't want to stop the current one before having the working one ready...

Selected Answer: C
C - service account is Google Cloud's best practice

Selected Answer: C
You don't need to create a new VM to have different access scopes:
https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
This weakens answer B.
When a user-managed service account is attached to the instance, the access scope defaults to cloud-platform:
https://cloud.google.com/compute/docs/access/service-accounts#scopes_best_practice
See Step 6 in: https://cloud.google.com/compute/docs/instances/change-service-account#changeserviceaccountandscopes
These facts leave C as the valid answer.

better than creating and downloading a service account key would be to impersonate the service account

Selected Answer: C
C. Create a new service account with BigQuery access and execute your script with that user.
Service accounts are used for server-to-server interactions, such as those between a virtual machine and BigQuery. You would need to create a service account that has the necessary permissions to access BigQuery, then download the service account key in JSON format. Once you have the key, you can set an environment variable (GOOGLE_APPLICATION_CREDENTIALS) to the path of the JSON key file before running your script, which will authenticate your requests to BigQuery.

The answer is C

https://cloud.google.com/bigquery/docs/authentication
For most services, you must attach the service account when you create the resource that will run your code; you cannot add or replace the service account later. Compute Engine is an exception—it lets you attach a service account to a VM instance at any time.

Selected Answer: C
Connecting to BigQuery from a script requires proper authorization. Service accounts provide a secure way to grant access without sharing user credentials.

It should be B,
Script cannot be run by user and user cannot be assigned with Service account, SA can be assigned to a VM

C
Best practice is that SA with least privilege from a CE should access BQ.

You write a Python script to connect to Google BigQuery from a Google Compute Engine virtual machine. The script is printing errors that it cannot connect to
BigQuery.
What should you do to fix the script?

https://cloud.google.com/solutions/reliable-task-scheduling-compute-engine#schedule-compute-engine

B is correct. More appropriately: https://cloud.google.com/solutions/reliable-task-scheduling-compute-engine

Selected Answer: B
You can create Cron job using HTTP endpoint, Pub/Sub and App engine.

Thanks... I was a little confused by this options

Selected Answer: B
Answer is B, but this question is outdated, Today the best practices for cron is Cloud Scheduler: fully managed enterprise-grade cron job scheduler
https://cloud.google.com/scheduler/?gad_source=1&gclsrc=ds&gclsrc=ds

This seems to be an old question, despite B could be the more correct answer, it is not exactly a good one. 'Using the Cron service provided by App Engine', the cron service is provided by Cloud Scheduler, not App Engine. App Engine HTTP endpoint can be a target for the cron task.

Selected Answer: B
https://cloud.google.com/blog/products/gcp/reliable-task-scheduling-on-google-compute-engine

This is because cloud scheduler is a newly released service which is a replacement to cloud app engine cron service.

Something feels missing/broken about this question

Even before comments in discussion that correctly mentioned Cloud Scheduler, which is not mentioned in the question

"By using Cloud Scheduler for scheduling and Pub/Sub for distributed messaging, you can build an application to reliably schedule tasks across a fleet of Compute Engine instances." https://cloud.google.com/architecture/reliable-task-scheduling-compute-engine

Answer is B. (Note: It was down to B or D but containerization was not mentioned)

Answer is B.
Cloud Scheduler provides a fully managed, enterprise-grade service that lets you schedule events. After you have scheduled a job, Cloud Scheduler will call the configured event handlers, which can be App Engine services, HTTP endpoints, or Pub/Sub subscriptions.

To run tasks on your Compute Engine instance in response to Cloud Scheduler events, you need to relay the events to those instances. One way to do this is by calling an HTTP endpoint that runs on your Compute Engine instances. Another option is to pass messages from Cloud Scheduler to your Compute Engine instances using Pub/Sub.

Selected Answer: B
A and C are out… messages are to be sent to pub sub and processed using a client. D is overkill for this purpose

Selected Answer: B
Ans is B https://cloud.google.com/architecture/reliable-task-scheduling-compute-engine

the link points to use Cloud Scheduler, and not Cron service provided by App Engine.

Ans is B https://cloud.google.com/architecture/reliable-task-scheduling-compute-engine

refer the examples with diagram

GKE is too expensive if all you are after is cron scheduling.

You right, but D is overkill. 
So B if the best practices for this task.

Sorry, can be implemented using both B and D

A is a bad solution as "send message directly to the utility" is not really reliable, you'd want pub/sub in between.

Selected Answer: D
This solution can be implemented using both A and D
1) With App Engine - https://cloud.google.com/appengine/docs/flexible/nodejs/scheduling-jobs-with-cron-yaml
2) With GKE - https://cloud.google.com/kubernetes-engine/docs/how-to/cronjobs

They ask for best practices and it's well known that GKE (aka containers) is the best practice for building modern infra solution. 

Yet another confusing PCA question on the card. Honestly, think the quality of the questions can be mightily improved.

B says Appengine.
But Cloud Scheduler is itself a managed service.
To schedule jobs via AppEngine, the cron.yaml has to be used.
It can be done similarly via GKE as well.
This question is confusing

So, did u passed? If yes then congratulations and please let us know the answer of this question

Selected Answer: B
https://cloud.google.com/solutions/reliable-task-scheduling-compute-engine

B is correct , there is no need of GKE for this scenario.

That said, App Engine has a cron job capabilities, so out of the options, indeed B makes sense, although App Engine is still an overkill comparing to Cloud Scheduler...

To use Cloud Scheduler App Engine must be enable at project level, else you can't use Cloud Scheduler

none seem correct.
You do not need App Engine - Cloud Scheduler can call Pub/Sub directly...
GKE seems like a massive overkill for job scheduling. Nonetheless, B seems the only choice that makes sense.

B is the correct answer
https://cloud.google.com/architecture/reliable-task-scheduling-compute-engine

B

Cloud Scheduler provides a fully managed, enterprise-grade service that lets you schedule events. After you have scheduled a job, Cloud Scheduler will call the configured event handlers, which can be App Engine services, HTTP endpoints, or Pub/Sub subscriptions.

GKE also provide cronjob
https://cloud.google.com/kubernetes-engine/docs/how-to/cronjobs

B. Using the Cron service provided by App Engine, publish messages to a Cloud Pub/Sub topic. Subscribe to that topic using a message-processing utility service running on Compute Engine instances.

B is correct
https://cloud.google.com/solutions/reliable-task-scheduling-compute-engine

It should be B as per below link
https://cloud.google.com/solutions/reliable-task-scheduling-compute-engine

A is probably correct because the sender has to ensure that the receiver has got the message and it's not hanging in the Pub/Sub. If the subscriber is not up and attached to the topic then it's possible that the subscriber may miss it. So, it's not a reliable conversation in that terms.

Both B & D work. Let's assume the Cron Service in D means CronJob.
But D requires more infra cost while B is simpler and easier.
- B.

I am debating between A and B. The only concern I have in choosing B that Cloud Pub/Sub can send duplicate messages since it will send the message "at least once". However, the direct messaging option in A can also fail.

B, but of course now you should use Cloud Scheduler.

B is the correct answer , App engine with pubsub is worked best for scheduling the tasks

B - https://cloud.google.com/solutions/reliable-task-scheduling-compute-engine

I don't think it's any of these. It should be Cloud Scheduler: https://cloud.google.com/solutions/reliable-task-scheduling-compute-engine

Answer B:
https://cloud.google.com/scheduler/docs/quickstart

Answer is B.
https://cloud.google.com/solutions/reliable-task-scheduling-compute-engine

Final Decision to go with Option B 
https://cloud.google.com/solutions/reliable-task-scheduling-compute-engine

B is the answer

Exact explanation is here https://cloud.google.com/solutions/reliable-task-scheduling-compute-engine

ignore and compute engine reference when GKE is involved.

B is correct, as we'll need to use pub-sub

CronJob is an object type creatable in Kubernetes, but that would require a cluster, too much overhead for a simple thing. B is best.

Perhaps cronjob is cron of kubernetes version.
this question don't mention cronjob, only cron.

It is A or B, https://cloud.google.com/appengine/docs/flexible/nodejs/scheduling-jobs-with-cron-yaml 

There is no mention of Cron Service for Kubernetes in the Google Documentation

Think D is better because:
- Perhaps you can't have all your apps in APP Engine 
- If you send directly messages to GCE and there is any availabity problem, message is lost. Otherwise message is in Pub/Sub, that has better availabity and performance than GCE VMs running messaging software

You need to ensure reliability for your application and operations by supporting reliable task scheduling for compute on GCP. Leveraging Google best practices, what should you do?

Also with option A you need months to download archive files(900TB)

ok but dedicated connection is available from 10 GBPS right where as in question it says internet connection is 100 MB, to me D is correct.

True. B is the most apt answer with just this extra bit "direct peering" raising some confusion.

Direct peering is meant only to connect to G Suite Services. Its reference may invalidate the whole answer.

The 100MB is the internet connection Dedicated Interconnect means physically connecting the on-prem server and google with a new network cable, I do hope the internal company network is not limited to only 100MB

Dedication interconnect doesn't connect with your internet. It is separate connection That is physical connection.

With option A, daily data would take 27 hours.
My answer is B.
How do you think?

even with 100MB internet it's slow. It's 800 Mbps and transfer for 10 TB will take 2 days

There is no such thing as a "100MB" internet connection :) . That must be a speed (per second), and I would guess that the "B" is just a typo (it is highly atypical to measure bandwidth in Bps).

Agree B. 100Mbps connections for 10TB data transfer is takes too long

https://cloud.google.com/solutions/transferring-big-data-sets-to-gcp#close

Selected Answer: B
Option B is the correct answer, but the term "or Direct Peering connection" is probably a typo. Direct peering is GCP to GCP service NOT an on-prem to GCP service.

Selected Answer: B
Lease a Transfer Appliance, upload archived files to it, and send it to Google to transfer archived data to Cloud Storage. (In this case is the more appropriated solution)
Establish a connection with Google using a Dedicated Interconnect or Direct Peering connection and use it to upload files daily. (Because of the size Dedicated interconnect or peering performs better and offer a better latency)

Selected Answer: B
There is no option than B.

Selected Answer: B
B would be correct as pubsub b service might redeliver messages. When you receive messages in order and the Pub/Sub service redelivers a message with an ordering key, Pub/Sub maintains order by also redelivering the subsequent messages with the same ordering key. The Pub/Sub service redelivers these messages in the order that it originally received them.

Selected Answer: D
B has an option of direct peering too which is not a recommended practise

Selected Answer: B
B. https://cloud.google.com/architecture/migration-to-google-cloud-transferring-your-large-datasets#time

It's B, transferring over 100mbps 10TB daily is not possible, because could take up to 12 days.. You need a better connection.

Selected Answer: C
I don't think the company needs "dedicated intereconnect" - because it is clearly said that the company wants to do "data-centric" business. Dedicated interconnect is more for having private-access to google cloud. 

C seems like a correct option to me

Selected Answer: B
Answer B => Dedicated interconnect will provide a private network with 10gbs. The internet limited to 100 mb is not possible to use cloud VPN ( it will use public internet so be limited for the daily)

Selected Answer: B
B. Since it is a new network just sign up for a dedicated line…

you can not use gsutil to load 10TB daily >>>and then continue loading 10 TB of data daily<<< it will take longer than 24hrs to upload using gsutil

B is the best, VPN doesn't scale very well for huge data

Selected Answer: B
B is the answer.

To support daily 10TB upload, you need Dedicated Interconnect who has at least 10Gbps.

Selected Answer: B
Key is "Daily transfer of 10 TB"- Any data transfer that requires more than 3 Gigs in bandwidth, VPN is out of equation.

Answer is B. The question asks what action would the company need to take to support the requirement...

I would go with B , VPN is not viable option to transfer that much date with 100mbps.

Dedicated Interconnect will be a new connection and will not run over the existing internet connection. With dedicated interconnect the existing ISP becomes irrelevant. If you were trying to use VPN the existing internet connection would be relevant. Answer is B.

I agree that in real life compressing a csv would probably reduce it's size by 100-1000x, making transfer over VPN connection actually feasible.

But test makers probably want B. Just as we don't know if direct interconnect is possible, we also don't know how effective compression is.

Hmm. Not easy. Everybody tends to B. But I think that can't be correct for the simple reason...

A is obviously not an option because of the initial amount of data. It could be that through compression the amount can be extremely reduced (I saw examples down to 5% of the original size). But the assumption at that point is, that the entropy is high => that means the compression is not necessarily the most important factor.

B: The answer doesn't say anything about the reach-ability of the interconnect / peering (meaning IXP's). So one has to assume that they CAN'T be reached. That means that only C/D can be correct.

I would tend to C because Google obviously would always recommend their own tools (gsutil). Then the hope would be that the compression and the bandwidth of the VPN is enough to get accomplish the job successfully.

go for B cause "900 TB of data and then continue loading 10 TB of data daily. You currently have an existing 100-MB internet connection."

Selected Answer: B
It's B. Look at https://cloud.google.com/architecture/migration-to-google-cloud-transferring-your-large-datasets#transfer-options

gsutil is not a choice for large migration. Leasing Transfer Appliance for one off migation is an option. Use GCS for archieving. Now coming to connectivity: Cloud VPN is only good for low bandwidth work. Google recommends to use Interconnect over Peering. However, here both are under option B. So answer is B

Consider: 
The gsutil tool is the standard tool for small- to medium-sized transfers (less than 1 TB)

Go for B.
"100-MB internet connection" is for download. In this case, we are going to send data to the Cloud.

Selected Answer: B
B is the correct answer

B
https://cloud.google.com/architecture/migration-to-google-cloud-transferring-your-large-datasets#close
10 TB / 100 Mbps = 12 days

B. Lease a Transfer Appliance, upload archived files to it, and send it, and send it to Google to transfer archived data to Cloud Storage. Establish a connection with Google using a Dedicated Interconnect or Direct Peering connection and use it to upload files daily.

Answer is B.

Breakdown plus solution:
1- Process and load 7 years of archived files totalling 900TB (Cloud Storage/Archive storage class + Transfer Appliance to ship data)

2- Continue loading 10TB data daily (Dedicated Interconnect - 10-200GBps line, typically you will compress files before uploading).

B probably is correct. MB is notation for Mega Bytes. The internet connections are available up to 2000Mbps and more widely maximum rate available is 1000Mbps. Here 100 MB which means 800Mbps (considering 8 bits per byte) which is a realistic internet speed the company has currently. So 10TB=10000000MB/100MBsec=100000 sec/60sec=1666.66667min/60min=27.77777778hr. Which is more than 24 hours. Unrealistic on the internet with no connection drops!!!

10GB is not the required bandwith but the technology that has to be supported by the physical network of the company. 
As Dedicated Interconnect implies to create a new physical link between the company and Google, the bandwith for this connection will be faster than the current internet connection

It cannot be B, as Dedicated interconnect/Direct Peering needs 10Gbps-80Gbps bandwidth. question clearly mentions available bandwidth is 100Mbps. Its between C and D.

Its B to answer 1st part of requirement and Dedicated interconnect supports from 50 MBPS to 50 GBPS . Refer below snippet from documentation 
 Dedicated Interconnect 
Features 
A direct connection to Google.
Traffic flows directly between networks, not through the public internet.
10-Gbps or 100-Gbps circuits with flexible VLAN attachment capacities from 50 Mbps to 50 Gbps.
Reference: https://cloud.google.com/network-connectivity/docs/how-to/choose-product#:~:text=If%20you%20have%20high%20bandwidth,options%20starting%20at%2050%20Mbps

daily 10T csv, can be easily compressed to 1T daily. with 100MB speed, 10K sec is enough to send the file. 1 day = 86400sec. Even with overhead, 100MB is enough for 1T file transfer.

The company has only 100 MBps internet connection. so, interconnect will not help them. Cloud VPN is upda to 375MBps. It works well.
C vs D: C has a typo says "compares" instead of "compress". "gsutil cp -m" can compress and upload the files. But that compare wording failed this option. So, only answer is :
D

B is the correct answer, self explanatory.

I will go with answer B, It will take 3 years to transfer 900 TB of data over 100 MBps line. https://cloud.google.com/solutions/migration-to-google-cloud-transferring-your-large-datasets

The catch here is that when you notice on-premises to GCP requirements means most definitely B is right. Transfer Applaince for transferring old 900TB and dedicated interconnect for daily transfer.

B is right. Transfer Applaince for transferring old 900TB and dedicated interconnect for daily transfer.

Answer is B; although the per tunnel capacity of Clould VPN is 3Gbps, but Internet bandwidth is only 100Mbps, which can only upload around 800GB data

10 TB over 100 MBps will take more than a day so B is best answer .

Best answer is C as Google Transfer Appliance is a physical appliance which is shipped to on Prem network , data copied and shipped back to Google for huge volume of data and used only for one Time Load . For daily load of data gsutil is preferred
.

B is correct, as you need to transfer 10TB daily too.

The sheer amount of volume of data involved would mean that you have to transfer at very high speeds. So the answer is B for sure.

B is my own correct answer
https://cloud.google.com/interconnect/docs/how-to/direct-peering

VPN have limited bandwidth: 3Gbps, it is the worst choice

10TB transfer can take more than 10 days over VPN connection 100 MB. My answer is B

Answer C. 900 TB data - Transfer Appliance use for data over 100TB, public internet is available, so it should be VPN

.csv files can be compressed well. but even though, it wont be drastic reduction to 900TB data. So ideal hear is answer B. It also considers 10TB of daily data to be transferred.

It's depends on the compression. You are compressing before, you don't know how much it will occupy. But I'would choose B answer too. But I'm not sure

Your company is building a new architecture to support its data-centric business focus. You are responsible for setting up the network. Your company's mobile and web-facing applications will be deployed on-premises, and all data analysis will be conducted in GCP. The plan is to process and load 7 years of archived .csv files totaling 900 TB of data and then continue loading 10 TB of data daily. You currently have an existing 100-MB internet connection.
What actions will meet your company's needs?

"globally scaled frontend" means Dataflow is required. If the clients were in 1 region only pushing messages, then Pub/Sub alone would be the solution. Since there are global clients, this requires Dataflow.

Answer is B. The question is talking about guaranteed-once FIFO delivery of data. Although Pub/sub provides data in order (FIFO) but it does 'at-least' once delivery of data. So, we need Dataflow for deduplication of data.

https://cloud.google.com/pubsub/docs/exactly-once-delivery
reference

Pub/Sub supports exactly-once delivery, within a cloud region.
The question states ¨global¨, so needs Dataflow

Now Pub/Sub guarantees message order. Until the exam does not change I would pick B.

the correct is B https://cloud.google.com/pubsub/docs/stream-messages-dataflow

I believe the answer is B. "Pub/Sub doesn't provide guarantees about the order of message delivery. Strict message ordering can be achieved with buffering, often using Dataflow." https://cloud.google.com/solutions/data-lifecycle-cloud-platform

B is the answer. CloudSQL is only for storage, to get the messages in order you need timestamp processed in dataflow to arrange them before putting it in any storage volume. The system described is not querying a db it is expecting a stream of messages only dataflow can correct the order. ACID has no value here because the db is not being queried. You'll not find any documentation on pub/sub order being corrected with a db. See notes below on pub/sub and dataflow using timestamps and windows to ensure order

https://cloud.google.com/pubsub/docs/pubsub-dataflow

Selected Answer: B
Answer is still B (Pub/Sub + Dataflow), because https://cloud.google.com/pubsub/docs/exactly-once-delivery#regional_considerations 
mentions "The exactly-once delivery guarantee only applies when subscribers connect to the service in the same region. If your subscriber application is spread across multiple regions, it can lead to duplicate message delivery, even when exactly-once delivery is enabled."
(so the exactly-once delivery only works regionally, but the question says architect for global)
The question's constraint of a globally scaled frontend, means you'll have clients in multiple regions.

Selected Answer: B
Cloud Pub/Sub to Dataflow because the data is streaming.

Selected Answer: B
https://cloud.google.com/pubsub/docs/exactly-once-delivery#regional_considerations

Selected Answer: A
Google Cloud Pub/Sub now supports message ordering, which ensures that messages with the same ordering key are delivered in the exact order they were published. This feature addresses the requirement for strict chronological order without the need for additional services.

Key Features of Cloud Pub/Sub with Message Ordering:
Message Ordering: By using ordering keys, Pub/Sub can guarantee that messages are delivered in the order they are published.
Exactly-once Delivery: Pub/Sub supports at-least-once delivery and can be configured to handle duplicate messages.
Scalability and Reliability: Pub/Sub is a fully managed service that scales automatically and ensures high availability.

Selected Answer: A
A. Cloud Pub/Sub alone

Cloud Pub/Sub Ordered Delivery: Cloud Pub/Sub natively supports ordered delivery when using the same ordering key. This guarantees that messages with the same key are delivered to subscribers in the order they were published, preventing out-of-order events.
Exactly-once Delivery: Cloud Pub/Sub also offers exactly-once delivery within a region, ensuring that each message is delivered to a subscriber only once.

Selected Answer: B
Pub/Sub provide ordered delivery but doesn't ensure deduplication. Cloud SQL is regional resource and it cant perform custom logic. I go with B

Selected Answer: A
A is correct. While Cloud Dataflow can be used for data processing, it doesn't guarantee FIFO order on its own. Additionally, introducing another processing layer adds complexity and might not be necessary for this specific requirement.

Selected Answer: B
Dont see a need for SQL here as the answer suggests. Option B is more appropriate

Selected Answer: B
b, even if pubsub now have exactly-once-delivery this is within a region. question is for a global app.
https://cloud.google.com/pubsub/docs/exactly-once-delivery#exactly-once_delivery_2

Answer is B.
Key words: globally scaled and ensure delivery only once: Pubsub + Dataflow.

If it were only one region, it would be fine to say just pubsub, but it is globally scaled.

Selected Answer: B
B, you need dataflow to deduplicate. Pub/Sub does "at-least" once delivery.

Selected Answer: A
https://cloud.google.com/pubsub/docs/exactly-once-delivery

Selected Answer: B
Pub/Sub is an at-least-once service. So you need to deduplicate messages with DataFlow as a data pipeline.

Selected Answer: B
B
Cloud Pub/Sub to Cloud Dataflow: Cloud Dataflow is a managed data processing service that can be used to process and transform streaming data. By using Cloud Dataflow with Cloud Pub/Sub, you can implement custom processing logic to ensure data is delivered in strict chronological order with no repeats. This combination allows you to achieve guaranteed-once FIFO delivery.

The Answer should be B simply because the question specifically stated that the solution will be globally scaled. 

this same link states:
"If messages have the same ordering key and are in the same REGION, you can enable message ordering and receive the messages in the order that the Pub/Sub service receives them."

https://cloud.google.com/pubsub/docs/ordering#receiving_messages_in_order

Selected Answer: A
https://cloud.google.com/pubsub/docs/ordering

Selected Answer: B
cloud sql does not gurantee FIFO, but cloud data flow does on real time streams and historical batch data

You are developing a globally scaled frontend for a legacy streaming backend data API. This API expects events in strict chronological order with no repeat data for proper processing.
Which products should you deploy to ensure guaranteed-once FIFO (first-in, first-out) delivery of data?

.css-1hohgv6{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;-webkit-flex-direction:row;-ms-flex-direction:row;flex-direction:row;gap:0px;}Exam.css-1cp477w{color:#4285F4;}Prepper

Exam
Prepper