Task 4.1: Configure and manage virtual networks in Azure

• AEnable Allow gateway transit on both peerings to VNet-Hub

  Incorrect

  Gateway transit shares a VPN or ExpressRoute gateway; it doesn't route traffic between two spokes.

• BCreate a peering between VNet-A and VNet-B

  Correct

  Peerings aren't transitive, so VNet-A and VNet-B need a peering of their own to communicate directly.

• CAdd a route in VNet-A with next hop Virtual network

  Incorrect

  Without a peering, a route can't make VNet-B's address space reachable from VNet-A.

• DTurn on Allow forwarded traffic on the hub's peerings

  Incorrect

  Forwarded traffic needs a device in the hub that forwards it; without an NVA nothing passes between the spokes.

A peering connects exactly two virtual networks. Spokes peered to the same hub can't talk unless they're peered with each other or traffic is routed through an appliance or gateway in the hub.

• AUse remote gateways on the hub's peering to the spoke

  Incorrect

  The hub owns the gateway; Use remote gateways belongs on the side that borrows the other network's gateway.

• BAllow forwarded traffic on the spoke's peering to the hub

  Incorrect

  Forwarded traffic concerns traffic relayed by an appliance; it doesn't let the spoke use the hub's gateway.

• CAllow gateway transit on the hub's peering to the spoke

  Correct

  The network with the gateway must allow gateway transit so the peer can use it.

• DUse remote gateways on the spoke's peering to the hub

  Correct

  The spoke uses its peer's gateway through Use remote gateways, which needs the spoke to have no gateway of its own.

• EAllow gateway transit on the spoke's peering to the hub

  Incorrect

  The spoke has no gateway, so allowing transit through it offers nothing.

Gateway transit is set on both sides: the hub peering allows gateway transit, and the spoke peering uses remote gateways. A virtual network that already has a gateway can't use remote gateways.

• AA route 0.0.0.0/0 with next hop Internet, on Web's route table

  Incorrect

  Next hop Internet sends traffic straight out, which is what the system route already does.

• BA route 0.0.0.0/0 with next hop Virtual network gateway

  Incorrect

  A gateway next hop sends traffic to a VPN or ExpressRoute gateway, not to a firewall VM.

• CAllow forwarded traffic on the virtual network

  Incorrect

  Allow forwarded traffic is a peering setting; here both subnets are in the same virtual network.

• DIP forwarding enabled on the firewall VM's network interface

  Correct

  A NIC that forwards traffic not addressed to itself must have IP forwarding enabled in Azure.

• EA route 0.0.0.0/0 with next hop Virtual appliance 10.0.9.4

  Correct

  A user-defined route with next hop Virtual appliance overrides the default route and sends the traffic to the firewall.

Steering a subnet through an appliance needs a route table on the subnet with a user-defined route to the appliance's private IP, and IP forwarding on the appliance's NIC (and often in its operating system).

• A27

  Correct

  Azure reserves five addresses in every subnet: the first four and the last, which leaves 27 of 32.

• B30

  Incorrect

  Thirty would be the count if only the network and broadcast addresses were held back; Azure reserves more than that.

• C32

  Incorrect

  A /27 holds 32 addresses in total, but Azure keeps some of them for itself.

• D29

  Incorrect

  Azure reserves five addresses, not three, so 29 is too many.

Azure reserves the network address, the default gateway, two addresses that map Azure DNS, and the broadcast address in each subnet. A /27 therefore leaves 27 usable addresses.

• AA route with address prefix Storage.WestEurope and next hop Internet

  Correct

  A service tag can be the address prefix of a user-defined route, and Microsoft keeps its ranges current.

• BA private DNS zone for blob.core.windows.net

  Incorrect

  DNS changes which address a name resolves to; it doesn't route traffic around the firewall.

• CA route for the Storage.WestEurope range copied from the service tag file

  Incorrect

  Copied ranges go stale; you'd have to keep updating them.

• DA route with address prefix 0.0.0.0/0 and next hop Internet

  Incorrect

  That replaces the firewall route and sends all internet-bound traffic around the firewall, not only the Storage traffic.

Service tags can be used as the address prefix of user-defined routes. When a tag route and an explicit prefix match exactly, the explicit prefix wins.

• AResize the virtual network instead

  Incorrect

  The subnet's own range still has to change.

• BStop the VMs, then change the range

  Incorrect

  Stopped VMs still have NICs in the subnet.

• CDissociate the subnet's network security group first

  Incorrect

  An NSG association doesn't block a range change; the resources deployed in the subnet do.

• DMove or delete the resources in the subnet first

  Correct

  The address range can be changed only when no resources are deployed in the subnet.

If no resources are deployed in a subnet, you can change its address range. Otherwise move or delete them first, or create a new, larger subnet and move workloads into it.

• ATier Regional

  Incorrect

  Regional is the default tier and doesn't change routing or egress cost.

• BRouting preference Microsoft network

  Incorrect

  Microsoft network keeps traffic on Microsoft's backbone as long as possible, which costs more.

• CTier Global

  Incorrect

  The global tier is for cross-region load balancers, not cost savings.

• DRouting preference Internet

  Correct

  The Internet option minimizes time on the Microsoft network, lowering the egress data transfer cost.

Public IPs can route traffic over the Microsoft network or over the internet (ISP networks). The Internet preference reduces the egress cost in exchange for traffic spending more time on the public internet.

• AChange existing subnets to smaller prefixes

  Incorrect

  That touches the existing subnets, which the requirement rules out, and subnets with resources in them can't change their range.

• BAdd a second range to the address space

  Correct

  A virtual network can have several address ranges; new subnets can use the added one.

• CCreate a peering to the same network

  Incorrect

  A network can't be peered with itself.

• DEnable IP forwarding on the NICs

  Incorrect

  IP forwarding has nothing to do with address space.

A virtual network's address space can include several nonoverlapping ranges. Add a range and create new subnets in it; peerings can be synced afterwards.