Google Professional Cloud Security Engineer Question 244
Single answerGoogle Cloud PlatformYour company has two projects in Google Cloud: 'project-a' and 'project-b'. They are both part of the same organization and require private workloads to communicate over internal IPs. To minimize management overhead, you decide to configure a Shared VPC where 'project-a' will serve as the host project and 'project-b' as a service project. After setting up the Shared VPC, you notice that instances in 'project-b' cannot communicate with instances in 'project-a'. What is the most likely reason for this issue?
- A
Firewall rules have not been configured to allow communication between the subnets.
- B
VPC Peering between 'project-a' and 'project-b' has not been established.
- C
The service account for 'project-b' does not have the Shared VPC Admin role.
- D
The necessary subnet in 'project-a' has not been shared with 'project-b'.
Show answer and explanation
Correct answer: A
Explanation
In a Shared VPC setup, service projects and host projects share the same VPC network. However, even though they share a network, communication between instances in different subnets is governed by firewall rules. If no rules are explicitly configured to allow traffic between subnets, the traffic will be blocked by default. Therefore, the issue in this scenario can be resolved by configuring the appropriate firewall rules to allow communication.
- A. Correct.
Correct: Firewall rules are required to allow traffic between instances in a Shared VPC. Without appropriate ingress and egress rules, communication between subnets in the host and service projects will be blocked.
- B. Incorrect.
Incorrect: VPC Peering is not needed in a Shared VPC setup because the service and host projects use the same VPC network for communication.
- C. Incorrect.
Incorrect: The Shared VPC Admin role is only required for managing Shared VPC configurations, not for instance-to-instance communication.
- D. Incorrect.
Incorrect: Subnets in a Shared VPC are automatically accessible to the service project if they are already shared. The issue lies in the firewall rules, not subnet sharing.