- Börja med att kartlägga Microsofts aktuella AZ-700-mål innan någon studieplan låses.
- Bygg labbar som tränar design, implementation och felsökning i samma scenario.
- Använd övningsprov för att hitta svaga domäner, inte för att memorera svar.
AZ-700 definierar kompetensen bakom microsoft-az-700" data-autoinject="link_injection">Microsoft Certified: Azure Network Engineer Associate: att designa, implementera, säkra och felsöka nätverkslösningar i Azure. För nätverksingenjörer, cloud-administratörer och DevOps- eller SRE-profiler blir provet mest värdefullt när förberedelsen speglar verkligt arbete med routingbeslut, hybridanslutning, privat åtkomst, lastbalansering, övervakning och incidentfelsökning.
Den officiella utgångspunkten bör alltid vara Microsofts aktuella sida för Exam AZ-700 och listan över “skills measured”. Microsoft uppdaterar certifieringsmål när Azure-tjänster förändras, och detaljer kring exempelvis Private Link, DNS, Virtual WAN, ExpressRoute och övervakningsfunktioner kan flyttas eller omformuleras över tid. Därför bör en studieplan behandlas som en levande plan: först kontroll av målen, sedan labbmiljö, därefter återkommande mätning mot varje domän.
Vad AZ-700 egentligen testar
AZ-700 handlar inte om att kunna namnet på varje Azure-nätverkstjänst. Provet prövar om kandidaten kan välja, kombinera och felsöka nätverkskomponenter i scenarier där kraven ofta konkurrerar med varandra. En lösning kan behöva låg latens, privat åtkomst, central säkerhetskontroll, segmentering, hybrid namnlösning och driftbar övervakning samtidigt.
Det gör att förberedelsen bör börja med arkitekturförståelse. En kandidat behöver kunna förklara varför en hub-spoke-modell passar ett visst fall, när Virtual WAN förenklar global anslutning, varför ExpressRoute kan vara lämpligt för stabil privat kapacitet och när site-to-site VPN räcker. Kostnad är en faktor, men på provet och i arbetslivet väger även latens, kapacitet, ägande av förbindelsen, compliancekrav, förändringshantering och operativ felsökbarhet tungt.
En enkel beslutsram för hybridanslutning är därför att först bedöma krav på förutsägbar prestanda och SLA-liknande driftmönster, därefter krav på central styrning och routingkontroll, och sist hur lösningen ska övervakas och förvaltas. VPN passar ofta som startpunkt, reservväg eller mindre belastade anslutningar. ExpressRoute passar när privat, mer förutsägbar anslutning är en del av kravet. Virtual WAN passar när många platser, grenar eller regioner behöver standardiserad anslutning och centraliserad styrning. Denna typ av resonemang ligger nära AZ-700-domänerna för hybridnätverk, routing, privat åtkomst och säker övervakning.
En praktisk studieplan över sex till åtta veckor
En tidsbunden plan fungerar bäst när varje vecka kombinerar teori, implementation och felsökning. Första fasen bör fokusera på virtuella nätverk, subnät, peering, NSG, effektiva rutter och grundläggande namnlösning. Det är frestande att gå direkt till mer avancerade tjänster, men många fel i Azure-nätverk beror på enkla beslut i adressplan, subnetdesign, peeringinställningar eller routetabeller.
Under den andra fasen bör kandidaten bygga en hub-spoke-miljö med minst två spoke-nät, central brandvägg eller NVA-liknande kontrollpunkt, UDR och separata säkerhetsregler. Målet är inte att klicka igenom en lyckad deployment, utan att kunna bevisa varför trafik tar en viss väg. Effective Routes, NSG-regler och loggar bör användas aktivt för att verifiera designen.
Tredje fasen bör ägnas åt hybridanslutning. En labb kan simulera site-to-site VPN med lokal gateway, VPN gateway och BGP-baserad route exchange där det är möjligt. För ExpressRoute räcker det ofta i en träningsmiljö att studera design, routing, peeringtyper och driftscenarier om riktig krets inte finns tillgänglig. Kandidaten bör ändå kunna beskriva hur anslutningen valideras, vilka rutter som annonseras och hur failover påverkar applikationstrafik.
Fjärde fasen bör fokusera på Private Link, Private Endpoints och DNS. Här missar många att själva nätverksvägen kan vara korrekt medan namnlösningen fortfarande pekar mot publik endpoint eller fel privat zon. Private DNS-zoner, Azure DNS Private Resolver, conditional forwarding och split-horizon DNS bör därför tränas som ett sammanhängande område, inte som en separat fotnot.
Femte fasen bör gå igenom lastbalansering och edge-val: Azure Load Balancer, Application Gateway, Traffic Manager, Front Door och relaterade säkerhetsval. Kandidaten behöver kunna skilja på lager, protokoll, global kontra regional trafikstyrning, TLS-terminering och hälsoprober. Ett vanligt examensscenario beskriver symptom snarare än produktnamn, exempelvis att användare i en region får fel backend eller att en probe misslyckas trots att servern verkar fungera.
Den sista fasen bör vara repetition med diagnostik. Övningsprov används här för att identifiera svaga domäner. Om resultatet visar brister i routing bör nästa aktivitet vara en mini-labb med UDR, peering, BGP och next-hop-verifiering, inte fler frågor inom samma ämne. Readynez metodik bygger på just denna koppling mellan mål, scenario, labb och återkoppling, vilket passar AZ-700 bättre än ren memorering.
Labbscenarier som ger verklig provnytta
En bra AZ-700-labb bör börja med ett krav, inte med en tjänst. Ett exempel är en organisation som vill ha centralt inspekterad trafik mellan två spoke-nät, privat åtkomst till en PaaS-tjänst och hybrid namnlösning från ett lokalt nät. Det scenariot tvingar fram designval kring peering, gateway transit, UDR, DNS-zoner och loggning.
För hub-spoke bör kandidaten bygga en miljö där all spoke-to-spoke-trafik går via hubben. Sedan bör en felaktig route introduceras medvetet, exempelvis en UDR som skickar trafik till en felaktig next hop. Det tränar det som ofta avgör både prov och drift: att kunna skilja mellan routingfel, NSG-blockering, brandväggspolicy och DNS-problem.
För Private Link bör labben innehålla både lyckad och misslyckad namnlösning. Kandidaten bör testa att en tjänst resolve:ar till privat IP från rätt nät, att privat DNS-zon är länkad till rätt virtuellt nät och att hybridklienter når samma namn via rätt resolverkedja. När en privat endpoint finns men klienten fortfarande använder publik adress är DNS nästan alltid första misstanken.
För lastbalansering bör labben kontrollera både dataplan och kontrollplan. Hälsoprober, backend pool-medlemskap, NSG-regler och routning mot backend-subnät måste stämma. Om en applikation är onåbar kan felet ligga i probe-porten, i en subnetregel, i fel frontend-konfiguration eller i att returtrafiken tar en annan väg än inkommande trafik.
Diagram är värdefulla i denna förberedelse, även om de skapas enkelt i ett ritverktyg. Ett användbart diagram för hub-spoke bör visa hubbens brandvägg, spoke-nät, UDR, peeringriktningar och var DNS-resolvern finns. Alt-texten bör beskriva beslutet, till exempel: “Hub-spoke-arkitektur där spoke-trafik styrs via central Azure Firewall och Private DNS-zon är länkad till hubb och spoke.” Det tvingar kandidaten att motivera designen i ord, vilket ofta är mer anställningsrelevant än att bara kunna portalsteg.
Felsökning: ordningen som sparar tid
AZ-700-scenarier innehåller ofta flera möjliga felkällor. Den effektivaste metoden är att felsöka i en stabil ordning. Börja med effektiva rutter och NSG-regler, eftersom de snabbt visar om Azure ens försöker skicka trafiken rätt. Gå sedan vidare till namnlösning, särskilt vid Private Link och hybridscenarier. Först därefter bör transport, brandväggsloggar, Connection Monitor och flödesloggar analyseras djupare.
Routingfallgropar är särskilt viktiga. En default route, 0.0.0.0/0, i en UDR kan skicka trafik till en brandvägg eller NVA, men peeringinställningar, gateway transit och returväg måste fortfarande vara symmetriska. BGP-preferenser kan göra att en väg väljs framför en annan trots att designen på papperet ser rimlig ut. Azure Route Server kan förändra hur dynamiska rutter lärs in och distribueras, vilket gör next-hop-verifiering viktigare än antaganden.
NSG Flow Logs och liknande flödesdata hjälper när kandidaten behöver se om trafik tillåts eller nekas på nätverksnivå. Effective Security Rules visar vilka regler som faktiskt träffar ett nätverkskort. Connection Monitor kan bekräfta anslutning mellan källor och mål över tid, medan brandväggsloggar visar policyträffar och nekad trafik vid central inspektion. I en examensfråga kan samma symptom beskrivas som “tjänsten svarar inte”, men orsaken kan vara route, NSG, DNS, probe eller policy.
Kommandon kan användas för att bekräfta hypoteser, särskilt när portalvyn inte räcker. I en labbmiljö med Azure CLI är målet att hämta observerbara fakta: vilka rutter finns, vilken next hop används och vilka regler gäller. Kommandon bör inte memoriseras isolerat, men de hjälper kandidaten att förstå vad Azure faktiskt har beräknat.
Exempel — kontrollera effektiva rutter på ett nätverkskort
az network nic show-effective-route-table \
--resource-group rg-az700-lab \
--name nic-spoke1-web01 \
--output table
Resultatet bör visa systemrutter, eventuella UDR:er och nästa hopp för relevanta prefix. Om trafik från spoke-nätet förväntas gå via en brandvägg men next hop visar virtuell nätverkspeering eller internet, är routetabellen eller subnetassociationen troligen fel. Nästa kontroll blir då UDR, peeringinställningar och returväg.
Exempel — verifiera privat namnlösning för en PaaS-tjänst
nslookup storageprivatelab.blob.core.windows.net
Server: 10.10.0.4
Address: 10.10.0.4#53
Name: storageprivatelab.privatelink.blob.core.windows.net
Address: 10.20.1.5
Det viktiga är inte exakt verktyg, utan att namnet resolve:ar mot privat adress och rätt privatelink-zon. Om svaret pekar mot publik adress bör kandidaten kontrollera Private DNS-zon, VNet-länk, resolverregler och eventuell hybrid forwarding. Denna typ av kontroll är ofta snabbare än att börja ändra brandväggsregler på måfå.
Så används övningsprov utan att skapa falsk trygghet
Övningsprov bör behandlas som diagnostik. Ett bra resultat på en uppsättning frågor betyder inte automatiskt att kandidaten kan designa eller felsöka lösningen i en ny variant. Ett svagt resultat är däremot användbart om det kopplas till rätt åtgärd: bygg om scenariot, ändra en parameter, bryt miljön medvetet och dokumentera varför felet uppstod.
Efter varje övningsprov bör kandidaten sortera fel efter domän: hybridanslutning, routing, privat åtkomst, lastbalansering, säkerhet eller övervakning. Därefter bör varje domän få en mini-labb. Om flera fel gäller Private Link ska labben fokusera på DNS-zoner, endpoint-status, nätverksåtkomst och hybrid resolverkedja. Om felen gäller routing ska labben fokusera på UDR, BGP, peering, Route Server och effektiv next hop.
Det är också klokt att öva på att läsa scenarier långsamt. Frågor kan innehålla begränsningar som “minimera administrativ overhead”, “behåll privat anslutning”, “inspektera all utgående trafik” eller “undvik ändringar i lokal infrastruktur”. Sådana krav styr ofta svaret mer än produktnamnen i frågan. Markera begränsningarna mentalt först, välj sedan lösningen.
Provdag: strategi för scenarier och tid
På provdagen bör kandidaten börja med att läsa instruktionerna noggrant, eftersom format och ordning kan variera. Case-liknande frågor kräver ofta att man håller flera krav i huvudet samtidigt. Det är bättre att först identifiera mål, begränsningar och befintlig topologi än att snabbt söka efter en bekant Azure-tjänst i svarsalternativen.
Flaggning bör användas disciplinerat. Om två alternativ verkar rimliga men ett krav saknas, flagga frågan och gå vidare i stället för att fastna. Vid återbesök bör kandidaten jämföra alternativen mot kraven ett i taget: privat eller publik åtkomst, regional eller global trafikstyrning, central eller distribuerad kontroll, statisk eller dynamisk routing och vilken komponent som faktiskt löser problemet.
En risk med AZ-700-förberedelse är att blanda ihop implementation och design. I praktiken kan två lösningar fungera tekniskt, men bara en matchar kraven på drift, säkerhet eller förändringsbarhet. Kandidaten bör därför öva på att skriva korta HLD- och LLD-liknande förklaringar: vilken topologi valdes, vilka rutter annonseras, var inspekteras trafik, hur sker namnlösning och hur rullas förändringen tillbaka vid fel.
Vanliga frågor om AZ-700
Vem passar AZ-700 för?
AZ-700 passar främst nätverksingenjörer, Azure-administratörer, cloud engineers och DevOps- eller SRE-profiler som arbetar med Azure-nätverk. Kandidaten bör vara bekväm med IP-adressering, routing, DNS, säkerhetsregler och grundläggande hybridanslutning innan provförberedelsen börjar på allvar.
Räcker Microsoft Learn för att klara provet?
Microsoft Learn är en viktig officiell källa, men de flesta kandidater behöver även praktiska labbar. AZ-700 testar tillämpning i scenarier, och därför bör dokumentation kombineras med hub-spoke-design, Private Link, DNS, routing, lastbalansering och felsökning i en egen miljö.
Vilket område brukar vara svårast?
Det varierar, men många underskattar kombinationen av Private Link, DNS och hybrid namnlösning. Routing är ett annat vanligt problemområde, särskilt när UDR, BGP, peering, brandväggar och asymmetrisk returtrafik möts i samma scenario.
Hur nära provet bör övningsprov användas?
Övningsprov är mest användbara efter att grunderna och de viktigaste labbarna är genomförda. De bör användas för att hitta domänsvagheter och prioritera repetition, inte som ersättning för att förstå arkitektur och felsökning.
Att bygga kompetens som håller efter provet
AZ-700 belönar kandidater som kan resonera som nätverksingenjörer i Azure, inte bara känna igen portalvyer. Den starkaste förberedelsen kombinerar officiella mål, praktiska labbar, strukturerad felsökning och återkommande reflektion över designval. DNS, routing och hybridanslutning förtjänar särskild uppmärksamhet eftersom de ofta är roten till problem som först ser ut som applikationsfel.
En praktisk väg framåt är att låta varje svag domän bli ett nytt scenario: bygg, bryt, felsök och dokumentera. Den som vill ha en mer styrd förberedelse kan använda Readynez som stöd för AZ-700-träning, men grunden är densamma oavsett upplägg: förstå kraven, verifiera designen och kunna förklara varför lösningen fungerar.
