Welp, yesterday went fairly well. Ended up going for brunch and leaving the house for the first time in like 2 or 3 months to actually do something. Anyway, I think this is going to be a short post unless I go through some more questions.
Wow, a slightly tricky question where they actually expound upon the answer so I don’t have to look around confused like. Having never used Azure for storage or really at all, root is not c but /. Good note. I don’t think this would work the same way on a local install but I could be wrong. Well, per this (which does state that add can be used to copy files into a build) it has to be where docker is installed and you don’t annotate the drive. Interesting note if I’m reading it correctly.
The docker documentation doesn’t use a drive any where either. I’m not sure why I didn’t notice that haha
My first instinct in this was to select the two correct answers but then considered the A answer and went with that and C. Why I thought forwarded traffic was more important than remote gateways was that it seemed redundant for some reason. It seems like if you use gateway transit it has to go through a gateway and into other one right? I don’t know about this one, I need to read the article. Probably a good place to start Virtual network peering
Virtual network peering enables you to seamlessly connect networks in Azure Virtual Network. The virtual networks appear as one for connectivity purposes. The traffic between virtual machines uses the Microsoft backbone infrastructure. Like traffic between virtual machines in the same network, traffic is routed through Microsoft’s private network only.
Azure supports the following types of peering:
- Virtual network peering: Connect virtual networks within the same Azure region.
- Global virtual network peering: Connecting virtual networks across Azure regions.
The benefits of using virtual network peering, whether local or global, include:
- A low-latency, high-bandwidth connection between resources in different virtual networks.
- The ability for resources in one virtual network to communicate with resources in a different virtual network.
- The ability to transfer data between virtual networks across Azure subscriptions, Azure Active Directory tenants, deployment models, and Azure regions.
- The ability to peer virtual networks created through the Azure Resource Manager.
- The ability to peer a virtual network created through Resource Manager to one created through the classic deployment model. To learn more about Azure deployment models, see Understand Azure deployment models.
- No downtime to resources in either virtual network when creating the peering, or after the peering is created.
Network traffic between peered virtual networks is private. Traffic between the virtual networks is kept on the Microsoft backbone network. No public Internet, gateways, or encryption is required in the communication between the virtual networks.
So that’s helpful but its not the specifics we are looking for but this one has more info Create, change, or delete a virtual network peering
So it turns out this is a fairly specific scenario as it doesn’t indicate that your using a VPN, it says hub and spoke. Which apparently works the same way as using a VPN. Forwarded traffic is also covered in that article and explains why you would want to do that and gives scenario examples. I’ll let you click through to the article if your interested but I’m sure your excited about my high lighted notes in this bad boy. Anyway, that’s all for this one.