In order to provide subnet level isolation, you want to force instance-A in one subnet to route through a security appliance, called instance-B, in another subnet. What should you do?
A.
Create a more specific route than the system-generated subnet route, pointing the next hop to instance-B with no tag.
B.
Create a more specific route than the system-generated subnet route, pointing the next hop to instance-B with a tag applied to instance-A.
C.
Delete the system-generated subnet route and create a specific route to instance-B with a tag applied to instance-A.
D.
Move instance-B to another VPC and, using multi-NIC, connect instance-B's interface to instance-A's network. Configure the appropriate routes to force traffic through to instance-A.
It is B for me:
https://cloud.google.com/vpc/docs/routes#subnet-routes
Custom static routes can apply to all instances or specific instances. Static routes with a tag attribute apply to instances that have that same network tag. If the route doesn't have a network tag, the route applies to all instances in the network.
The answer is B. Lots of discussion about whether you can create a more specific route and whether the tag is necessary. The answer is somewhat in the question: Yes, use a tag applied to instance-A because it allows you to apply the more specific route to just the instance(s) with that tag. The question doesn't say ALL instances in the subnet, just instance-A. As for creating a more specific route: Yes, you can do this and while the documentation is somewhat confusing on this topic, you only need to focus on the static route documentation to be sure: https://cloud.google.com/vpc/docs/static-routes
To force instance-A in one subnet to route through a security appliance, called instance-B, in another subnet, you need to create a more specific route than the system-generated subnet route. The next hop of the more specific route should point to instance-B with no tag.
Here is an example of how to create a more specific route than the system-generated subnet route:
gcloud compute routes create my-route \
--destination-range=10.0.0.0/24 \
--next-hop-instance=instance-b \
--next-hop-instance-zone=us-central1-a \
--priority=100
This command will create a route with a destination range of 10.0.0.0/24 and a next hop of instance-B. The priority of the route is set to 100, which is higher than the priority of the system-generated subnet route. This means that the more specific route will be used to route traffic from instance-A to instance-B.
The other options are incorrect because:
B. Create a more specific route than the system-generated subnet route, pointing the next hop to instance-B with a tag applied to instance-A. This is not necessary. You do not need to apply a tag to instance-A in order to force traffic to route through instance-B.
C. Delete the system-generated subnet route and create a specific route to instance-B with a tag applied to instance-A. This is not necessary. You can simply create a more specific route than the system-generated subnet route.
D. Move instance-B to another VPC and, using multi-NIC, connect instance-B's interface to instance-A's network. Configure the appropriate routes to force traffic through to instance-A. This is a more complex solution than simply creating a more specific route.
Therefore, the best option is to create a more specific route than the system-generated subnet route, pointing the next hop to instance-B with no tag.
It is B for me: https://cloud.google.com/vpc/docs/routes#subnet-routes Custom static routes can apply to all instances or specific instances. Static routes with a tag attribute apply to instances that have that same network tag. If the route doesn't have a network tag, the route applies to all instances in the network.
Right answer MUST be C! You can not create a more specific VPC route, it's stated right here:
https://cloud.google.com/load-balancing/docs/internal/troubleshooting-ilb#invalid-dest-range
Mods please delete my comment. I have tested the steps in answer B and this will work but only if both VMs had IpForward enabled at the time of creation.
Right now this is the warning I'm getting at the route, after testing scenario from answer B:
"Your source and destination VM instances must have canIpForward enabled."
The route is created successfully, this warning is just attached to it with a small warning symbol.
The ANSWER should be D, You can not put a third part appliance(firewall) within a VPC, it has to be 2 seperate VPC and with a multi nic VM this scenario is achievable.
Answer is D.
This is a typical Arch. Design for shared VPC host project where you add your Security Appliance to control traffic between service projects [ E-W traffic]
Sorry, Answer D is incorrect... That answer says: ...Configure the appropriate routes to force traffic through to instance-A. Instance A is NOT the Security appliance.. unless its a typo, and it meant to say Instance B.
But Answer D shows the Instance A as the Security appliance, not Instance B...
The questions ask for traffic to go from Instance-A to Instance-B... Answer D has it the other way around...
The answer is 200 % D by elimination method.
1)It cannot be A or B because you are not allowed to create a more specific route than subnet route
2)You are not allowed to remove a subnet route. The only way to do so is by deleting the subnet itself.
Thus, by elimination the answer is D.
Agree. Its D for the reasons you give. Its a process of elimination question and in reality east west routing via firewall appliance would be across VPC's not subnet. Subnets are segreated by firewall rules not routes
Not sure, this is circular logic, after moving B to a different VPC, which route will you create to force routing of instance-A through instance-B without running into the same limitation of inability to define a more specific route then the system generated subnet route ?
Having security appliance that use multi-nic for east-west subnet isolation is a good pattern. But to achieve this you will need to move more then just instance-b to the other VPC.
B should be the answer. It's question about defining static route.
The scenario is to require traffic from instance-A to be routed VIA instance-B in a different subnet, thus, instance-B's subnet is not the destination. "No other route can have a destination that matches or is more specific (has a longer subnet mask) than the destination of a subnet route." --> only applies when you try to set a destination CIDR within the subnet range. For example,if the 10.10.10.0/24 is the subnet, you can not define a static route which has destination ip range as 10.10.10.0/25.
When creating the static route for this question, you can select an instance (B) as next-hop, and use tag applied to instance-A to limit this static route to be only applicable for Instance-A.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
gless
Highly Voted 3 years, 11 months agoAzureDP900
1 year, 12 months ago3fd692e
Most Recent 1 month, 2 weeks agothewalker
7 months agothewalker
7 months agocrg63
1 year, 1 month agodesertlotus1211
9 months, 1 week agodidek1986
1 year, 3 months agotnar140
1 year, 7 months agodesertlotus1211
1 year, 6 months agodesertlotus1211
9 months, 1 week agopk349
1 year, 10 months agopfilourenco
1 year, 11 months ago[Removed]
2 years, 1 month agoMr_MIXER007
2 years, 1 month agogcpengineer
1 year, 3 months agosmall1_small2
2 years, 3 months agoRaz0r
2 years, 4 months agoRaz0r
2 years, 4 months agopapaliu
2 years, 5 months agoLEGCPLele
2 years, 8 months agodesertlotus1211
2 years, 11 months agodesertlotus1211
2 years, 11 months agomatmuh
2 years, 11 months agodesertlotus1211
2 years, 11 months agoseddy
3 years, 6 months agoJoeShmoe
3 years, 6 months agoEranSolstice
3 years, 1 month agodensnoigaskogen
3 years, 6 months ago