Microsoft Certified: Network Engineer Associate – Exam Passed!

2022 Dec 16 By Deathmage85 0 comment

Created: 12/16/22

Updated: 12/16/22

I did it, I got it. I passed the Microsoft Certified: Network Engineer Associate.

Boy was this exam FUN! – networking has always been a passion of mine. I started out in IT doing Cisco and the CompTIA Network+; so being able to do networking and networking study for this pursuit was like a kid in a candy shop.

We all learn new stuff in Azure all the time, but at its core the cloud that we know today is still driven by networking. Azure is nothing more they a highly refined Hyper-V platform that lives on bare metal machines in an Azure data center that is connected to a software-defined network just like a VMware VXLAN solution that then provides networking for all our Azure tenants on a global scale. Azure is really just someone else data center (with networking), and it’s owned by Microsoft.

It’s funny how this all comes full circle. 😉

Some things I’ve learned along the way:

  1. Express Routes with a standard SKU can support up to 10 vNET in 10 different subscriptions as long as they all exist in the same geographical region.
  2. Express Route Global, allows two geographically isolated regions say a Madrid on-premise datacenter that connects to a Madrid-based Azure tenant via Express Route and a Chicago on-premise datacenter that connects to a Chicago-based Azure tenant via Express Route to link its Express Route with the Madrid Express route to create a private peering “bridge” between each other while using the Azure Global Network to allow both networks to communicate with each as if it was Local LAN access.
  3. When managing a vNET that has a private DNS zone attached with a series of virtual machines (contoso.com) and you’re using an Azure firewall in the same vNET and you’d like to resolve the Azure-based private DNS zone’s virtual machines with an on-premise network connected via an Express Route (or any tunnel); ensure you enable a DNS Proxy on the Azure firewall (with the private IP address of the Azure firewall defined in the Azure private DNS as a DNS NS record) that then points to the on-premise DNS Servers and then set up a conditional forwarder from the on-premise DNS Servers that points to the Azure firewall’s frontend IP address for azure-based DNS name resolution to be resolvable with on-premises DNS Server name resolution, i.e contoso.com. – long-winded topic; read about it: here
  4. Similar to the one above, but for storage accounts, in this example a normal file share, that you need access to from an on-premises network and you need to resolve the IP address of this storage resource, you must do the following:
    1. Creates the storage account
    2. Create a File Share in the storage account
    3. Create a private endpoint and link it to the storage account (you do this from the networking section of the storage account and click on Private Endpoint – also under networking under network connectivity select “Disable public access and use private access”) and call it: privatelink.file.core.windows.net; however, a list of others is: here – also establish a virtual network link with your vNET (if you don’t do it in Step 4 below); this is mentioned: here
      1. Note: during the creation of the private endpoint, it will ask for the target sub-resource on the 2nd resources tab, this is key, you’d select “file” to denote a File Explorer-like file share
      2. Note: on the end of the private endpoint creation it will ask you to integrate with Private DNS, do this, it’s critical. You can do it manually but it’s more work.
    4. (optional) Ideally, the most secure way of sharing a storage account on-premise is by selecting a “specific network” you want and not the default of “All networks”, this prevents public access to the storage account, but this is to your design
    5. In your Azure vNET, if you don’t already have one, spin up a Windows Server VM and then deploy the DNS role after joining it to the domain (Note its critical the VM lives in the vNET that the storage account also lives or that the vNET with the Azure-based DC and the storage accounts live in can “peer” with each other)
    6. Once DNS is set up on the Azure-based VM perform this on the same newly spun-up DNS server in Azure, create a conditional forwarder for file.core.windows.net and point it towards 168.63.129.16 (this is a Microsoft-managed Azure public DNS address for resolving these addresses but it can only be done from within a tenant vNET setup like this, as this is an internal Microsoft DNS resolution mechanism that is not resolvable outside of the Azure global network)
    7. Once the DNS is setup in Azure on the Azure-based DNS server as aforementioned, you then on your on-premise DNS Server create a conditional forwarder for file.core.windows.net and point it at the IP address of this Azure-based DNS Server.
    8. Once this is done you can then resolve the private endpoint address of the storage account from on-premise resources.
  5. Policy-based VPN and Route-based VPN cant mix when using VPN tunnels. Both types need to match on both ends.
  6. Knowing the use case for bi-directional vNET peering (allowing for VLAN to VLAN communication only without a default route) and bi-directional vNET peering with gateway transmit (allows for the default gateway of a connecting vNET to be used with a peered vNET if one of the vNET does have virtual gateway defined – an example would be a virtual gateway with a Site-to-Site connection with an on-premises Datacenter)
  7. If you’re the owner of an Azure tenant and you have resources in your subscriptions that live in US East and also US West, you don’t need a VPN tunnel between them, you simply use vNET peering and let the Azure Global Network worry about backend routing.
  8. When using a NAT gateway for outbound traffic be mindful that a single public IP can only support up to 64,000 connections per IP with a max of 16 public IPs per NAT Gateway, reference: here
  9. Be sure you know the use case for the Azure vNET networking for the “firewall and virtual networks” sections as it pertains to “all networks” or “selected networks and IP addresses”.
  10. Know the difference between a Service Endpoint and a Private Endpoint; a Service Endpoint is used to connect to App from an on-premise resource but also allows public access. As it says in the name a Private Endpoint is only accessible within the constructs of an Azure vNET, its peered vNET connections, and also remote on-premise networks that are allowed to transit the “hub” vNET in your Azure tenant that has your edge gateway connection in Azure to your on-premise edge security like a firewall-based VPN tunnel that has a routing table to link on-premise to azure networking of your tenant. Long but this is the only way a Private Endpoint will work, it’s not public access; it’s private to your network. Here is a very good explanation
  11. Ensure you know your DNS Records and their use cases
    1. Example: Domain FQDN = mydomain.local
      1. A = is the name of the IP tagging; for example DNSServer1’s IP is 192.168.10.1 | it would be a DNSServer1 with a value of 192.168.10.1
    2. Alias = is a nickname for the primary record; example DNS1 is an alias of DNSServer1
    3. MX = this is a record that denotes the IP address or FQDN of the Exchange Server (typically there is two of these records with a weighed priority to denote primary and secondary for Exchange – but with EXO, this is becoming less and less of a need-to-know)
    4. PTR = this is used for the reverse lookup of a FQDN of an IP address; typically you do “nslookup <ip address>”, but a reverse lookup is “nslookup DNSServer1”
    5. TXT = these are records use to confirm ownership of a domain
    6. NS = Name Server; these are your DNS servers that store the records of the domain
    7. SOA = Start of Authority; this is the DNS servers that are authoritative for the domain
  12. Make sure you understand the use cases for Network Security Groups (NSG’s) along with inbound and outbound rules. Know what are default rules, and also how to configure these rules for ports like RDP (3389 default) or HTTPS (443)
  13. Make sure you have a grasp on service tags that can be linked to Azure networking
  14. Know what an LNG and VNG are and how to configure them
  15. Know what a RADIUS server is and what its use is with a VPN for AD authentication
  16. A critical skill is to know to subnetting, IPv4 /16 is the smallest, but also know the uses of a /22, /23, and the sizing that a /28 has over a /27; take note of the broadcast and network IDs and also of the addresses the Microsoft uses for its own gray area backend linkage with your vNET (hint: they reserve the 1st 4 IP’s and the last IP in a block) – also know IPv6 though not as critical unless your working with BGP all the time
  17. This reminds me, know Express Route Local and Global Reach and how BGP is used. I don’t see OSPF used with Express Routing, but that makes sense as BGP is more of a WAN routing mechanism and OSPF is more of a local LAN routing mechanism
  18. Understand Azure WAN and all its SKUs and their use cases
  19. Dabble a little into the dark arts of DevOps so you know how Azure App works with vNET’s, Private/Service Endpoints, and how Azure Apps need their own vNET as an example
  20. Know how to configure an Azure load balancer, the pools, and the rules associated with the balancers
  21. Know you to set up Web Application Firewalls and what they are used for. I was lucky enough to use them all in a past life all the time, so I understand the purpose of an Azure WAF.
  22. Make sure you understand PKI and certificates and the use cases of certs when it comes to HTTPS and encryption requirements
  23. And lastly touching on certificates, know how this can tie into Azure networking as it intermingles with Azure Key Vaults

Ok, on that note I think this article is done. Just wanted to share what I’ve learned and maybe this will guide others on stuff they should focus on too if they decide to do the AZ-700 for the Microsoft Certified: Azure Network Engineer Associate.

Have a good one! ^_^ Cheers! 😀