AZ-700 er en sertifisering som ofte blir oppfattet som en test i Azure-tjenester og eksamensfakta. I praksis tester den om nettverksingeniører kan forstå og bruke Azure-nettverk på en praktisk og løsningsorientert måte.
Den antakelsen gjør forberedelsen svakere enn den trenger å være, fordi eksamenen i praksis belønner evnen til å ta nettverksvalg ut fra krav, begrensninger, ruting, sikkerhet og drift.
Hva AZ-700 måler
AZ-700, Designing and Implementing Microsoft Azure Networking Solutions, er rettet mot nettverksingeniører, cloud-ingeniører og arkitekter som designer og implementerer Azure-nettverksløsninger. Microsofts sertifiseringsside beskriver eksamenen som en vurdering av ferdigheter innen hybridnettverk, kjerneinfrastruktur, ruting, nettverkssikkerhet, overvåking og privat tilgang til Azure-tjenester; kandidatene bør alltid sjekke den oppdaterte oversikten på Microsofts offisielle AZ-700-side før de melder seg opp.
For en norsk kandidat betyr dette at forberedelsen bør ligne praktisk nettverksarbeid mer enn ren lesing. Kandidaten må kunne forklare hvorfor en organisasjon bør bruke VPN Gateway, ExpressRoute, Private Link, Azure Firewall, Azure Bastion, Network Watcher eller Azure Monitor i et bestemt scenario, og hva valget betyr for ruting, DNS, sikkerhet, feilsøking og kost.
Eksamenen passer særlig godt for fagfolk som allerede har nettverksforståelse og nå arbeider med Azure som plattform. Azure-administratorer som fortsatt bygger grunnlaget for identitet, compute, storage og generell drift kan ha mer nytte av å starte med Azure Administrator-stoffet før de går dypt inn i nettverksdesign.
Fra Norge: oppmelding, språk og praktiske rammer
Kandidater i Norge melder seg vanligvis opp via Microsofts sertifiseringsside, der tilgjengelige leveringsformer, språkvalg og pris vises for aktuell region og tidspunkt. Pris og tilgjengelighet kan endre seg, så faste beløp bør ikke brukes som planleggingsgrunnlag uten å kontrollere Microsofts side samme dag som oppmeldingen gjøres.
Det er også verdt å avklare språk før lesingen starter. Mange norske fagmiljøer bruker engelske tjenestenavn i daglig drift, selv når dokumentasjon og interne rutiner er på norsk. Det gjør det praktisk å øve med engelske begreper som user-defined routes, effective routes, private DNS zone, BGP, forced tunnelling og service endpoints, fordi de samme uttrykkene ofte dukker opp i dokumentasjon, portal og feilsøking.
Designvalgene som skiller gode svar fra svake svar
AZ-700 handler ofte om å velge riktig tilkoblingsmønster. VPN Gateway gir kryptert tilkobling over Internett og passer i mange hybride scenarioer der kravene til kapasitet og forutsigbarhet er moderate. ExpressRoute gir privat tilkobling via leverandør og brukes når organisasjonen trenger mer forutsigbar ytelse, lavere varians i latenstid eller strengere krav til trafikkvei. Private Link og Private Endpoint løser et annet problem: de gir privat tilgang til PaaS-tjenester fra virtuelle nettverk uten å eksponere tjenesten via offentlig nettverkstilgang.
Et nyttig beslutningsrammeverk er å vurdere valget langs de samme aksene som eksamenen måler: hybrid tilkobling, kjerneinfrastruktur, ruting, sikkerhet og privat tilgang. Hvis hovedproblemet er å koble datasenteret til Azure, står valget ofte mellom VPN Gateway og ExpressRoute. Hvis hovedproblemet er å hindre at applikasjoner når en lagringskonto eller database over offentlig endepunkt, peker løsningen oftere mot Private Endpoint, riktig DNS-design og tydelig segmentering.
Virtual WAN gir mening når mange lokasjoner, regioner eller forbindelser skal administreres med mer standardisert hub-arkitektur. En klassisk hub-spoke-modell med Azure Firewall, Azure Route Server og eventuelle NVA-er gir derimot mer kontroll i miljøer der rutingpolicy, inspeksjon og integrasjon med eksisterende nettverksverktøy må skreddersys. Begge mønstre kan være riktige; eksamensspørsmålene tester ofte om kandidaten leser kravene presist nok til å se hvilket kompromiss som er relevant.
Hub-spoke i praksis
En typisk AZ-700-lab bør starte med en trygg testressursgruppe, separate virtuelle nettverk og en enkel hub-spoke-modell. Poenget er ikke å bygge en produksjonsklar plattform, men å se hvordan peering, rutetabeller, DNS og sikkerhetskontroller påvirker trafikkflyten.
En vanlig designfelle er å anta at VNet-peering er transitiv. Hvis spoke A er peered med hub, og hub er peered med spoke B, betyr ikke det automatisk at spoke A kan nå spoke B gjennom hub. Transitivitetskravet må løses med riktig arkitektur, ruting og eventuelt en sentral nettverksfunksjon som Azure Firewall eller NVA.
Denne korte Azure CLI-labben viser en trygg start på hub-spoke-design i en testressursgruppe. Den oppretter ikke virtuelle maskiner, åpner ingen offentlige porter og bør bare brukes i et isolert labmiljø.
Example — opprett hub og spoke med peering
az group create --name rg-az700-lab-norway --location norwayeast
az network vnet create \
--resource-group rg-az700-lab-norway \
--name vnet-hub-az700 \
--address-prefix 10.10.0.0/16 \
--subnet-name AzureFirewallSubnet \
--subnet-prefix 10.10.0.0/26
az network vnet create \
--resource-group rg-az700-lab-norway \
--name vnet-spoke-app \
--address-prefix 10.20.0.0/16 \
--subnet-name snet-app \
--subnet-prefix 10.20.1.0/24
az network vnet peering create \
--resource-group rg-az700-lab-norway \
--name peer-hub-to-spoke-app \
--vnet-name vnet-hub-az700 \
--remote-vnet vnet-spoke-app \
--allow-vnet-access
az network vnet peering create \
--resource-group rg-az700-lab-norway \
--name peer-spoke-app-to-hub \
--vnet-name vnet-spoke-app \
--remote-vnet vnet-hub-az700 \
--allow-vnet-access
Etter en slik lab bør kandidaten undersøke peering-innstillingene i portalen og lese Microsoft Learn-dokumentasjonen for Azure Virtual Network, VPN Gateway, ExpressRoute og Azure Firewall. Læringsverdien ligger i å knytte kommandoene til designspørsmål: hvilke nett trenger felles tjenester, hvilke subnett skal inspiseres, og hvor skal standardruter plasseres?
Ruting, BGP og de små detaljene som ofte avgjør
Ruting er et av områdene der eksamenen raskt avslører overflatisk forståelse. Kandidater bør vite hvordan systemruter, user-defined routes og BGP-lærte ruter samspiller, og hvordan Azure velger rute når flere alternativer finnes. I praksis er det sjelden nok å vite at UDR finnes; man må forstå når en rute overstyrer ønsket vei, når BGP annonserer mer spesifikke prefikser, og hvordan forced tunnelling påvirker inspeksjon og utgående trafikk.
En annen praktisk felle er SNAT-portutnyttelse. Mange arbeidslaster som går ut mot samme eksterne mål kan bruke opp tilgjengelige SNAT-porter hvis designet baserer seg på feil egress-mønster. NAT Gateway kan være et bedre valg for skalerbar utgående tilkobling fra subnett, mens Load Balancer-baserte mønstre krever mer bevisst planlegging av kapasitet og trafikkprofil.
IPv6 og dual-stack bør heller ikke behandles som et tillegg man kan ignorere. Flere organisasjoner har applikasjoner, klientnett eller partnerkrav der IPv6 blir relevant, og da må DNS, ruting, sikkerhetsregler og overvåking vurderes samlet. I hybridmiljøer kan en svak DNS-plan skape mer nedetid enn selve tilkoblingstjenesten.
Privat tilgang til PaaS krever DNS-disiplin
Private Endpoint er et sentralt tema fordi det endrer hvordan klienter når Azure PaaS-tjenester. Når en tjeneste bindes til et privat endepunkt, blir DNS-oppsettet avgjørende: klientene må løse tjenestenavnet til privat IP der det er ønsket, samtidig som andre miljøer ikke brytes av feil sonedelegering eller manglende videresending.
En vanlig feil er å aktivere Private Endpoint uten å avklare om offentlig nettverkstilgang skal deaktiveres, og hvilke klienter som fortsatt trenger tilgang. Det kan gi et sikrere design, men det kan også stenge legitime administrasjons- eller integrasjonsbaner hvis DNS, brannmurregler og tilgangspolicyer ikke er planlagt.
Denne PowerShell-labben viser strukturen i en privat DNS-sone for blob-lagring i et lab-VNet. Den forutsetter at ressursgruppen og VNet finnes fra tidligere lab, og den oppretter ikke selve lagringskontoen eller endepunktet.
Example — knytt privat DNS-sone til et VNet
$resourceGroup = "rg-az700-lab-norway"
$vnetName = "vnet-spoke-app"
$zoneName = "privatelink.blob.core.windows.net"
New-AzPrivateDnsZone `
-ResourceGroupName $resourceGroup `
-Name $zoneName
$vnet = Get-AzVirtualNetwork `
-ResourceGroupName $resourceGroup `
-Name $vnetName
New-AzPrivateDnsVirtualNetworkLink `
-ResourceGroupName $resourceGroup `
-ZoneName $zoneName `
-Name "link-spoke-app-blob" `
-VirtualNetworkId $vnet.Id `
-EnableRegistration:$false
Labben illustrerer hvorfor Private Endpoint-spørsmål ofte er DNS-spørsmål forkledd som sikkerhetsspørsmål. Kandidaten bør kontrollere hvordan navneoppløsning fungerer fra riktig subnett, og sammenholde dette med Microsoft Learn-dokumentasjon for Private Link, private DNS-soner og relevant PaaS-tjeneste.
Sikkerhet og overvåking: NSG er ikke en brannmur
NSG-er filtrerer trafikk på subnett- eller nettverkskortnivå, men de gir ikke samme rolle som Azure Firewall. Azure Firewall kan brukes til sentral inspeksjon, applikasjonsregler, nettverksregler, DNAT og logging i en hub-arkitektur. Azure Bastion reduserer samtidig behovet for offentlige IP-adresser på virtuelle maskiner ved å gi administrativ tilgang via en kontrollert tjeneste.
Motstandsdyktighet og kost bør være en del av designet fra starten. Zonal distribusjon av Azure Firewall kan gi bedre tilgjengelighet i regioner som støtter soner, men påvirker også arkitektur, logging og driftskostnader. ExpressRoute FastPath kan være relevant når dataplanet bør gå mer direkte til virtuelle maskiner, men det må vurderes mot krav til inspeksjon, sikkerhetskontroller og observability.
Overvåking er ikke bare etterarbeid. Azure Monitor, Network Watcher, NSG Flow Logs, Traffic Analytics og Log Analytics bør inngå i labbene, fordi feilsøking er en praktisk ferdighet i både eksamen og drift. Microsoft Learn-dokumentasjonen for Azure Monitor og Network Watcher er særlig nyttig når kandidaten skal forstå hvilke verktøy som svarer på hvilke typer nettverksspørsmål.
En fast feilsøkingssekvens for Azure-nettverk
Effektiv feilsøking i Azure starter med å avgrense hvor trafikken stopper. Mange hopper rett til brannmur eller applikasjon, men de mest nyttige første kontrollene er ofte Effective Routes, Effective Security Rules, IP Flow Verify og Connection Troubleshoot i Network Watcher.
- Bekreft kilde, mål, protokoll og port før konfigurasjon endres.
- Sjekk Effective Routes på nettverkskortet for å se valgt trafikkvei.
- Sjekk Effective Security Rules for NSG-regler som blokkerer trafikken.
- Bruk IP Flow Verify for en rask tillat-eller-nekt-vurdering.
- Bruk Connection Troubleshoot når ruten eller neste hopp må valideres.
- Analyser NSG Flow Logs i Traffic Analytics eller Log Analytics ved gjentatte feil.
Dette mønsteret hindrer unødvendige endringer i produksjon. Det trener også eksamensrelevant tenkning: først observere faktisk ruting og filtrering, deretter endre den minste konfigurasjonen som forklarer problemet.
Hvordan bygge en realistisk studieplan
En god AZ-700-plan bør blande Microsoft Learn, offisiell dokumentasjon, praksisvurderinger og egne labber. Lesing alene gir ofte falsk trygghet, særlig i temaer som BGP, Private Endpoint og hub-spoke-ruting. Hver hovedtjeneste bør kobles til et lite scenario: hvorfor brukes den, hva bryter hvis den konfigureres feil, og hvordan bekreftes at den virker?
Strukturert undervisning kan være nyttig når kandidaten ønsker laboratorier, gjennomgang av designvalg og en rytme som holder progresjonen oppe. I den sammenhengen kan AZ-700-kurset hos Readynez være et relevant alternativ, særlig for nettverks- og cloud-fagfolk som vil arbeide systematisk med eksamensmålene.
Noen kandidater trenger først et bredere Azure-grunnlag før AZ-700 gir full uttelling. Da kan generell Azure-administrasjon, identitet, compute, storage og overvåking være et bedre startpunkt enn å gå rett på avansert nettverksdesign; organisasjoner som vurderer bredere opplæring kan også bruke Readynez som ett av flere steder å sammenligne læringsformer.
Vanlige feil i forberedelsen
Den vanligste feilen er å pugge tjenestebeskrivelser uten å øve på beslutninger. Kandidaten bør kunne forklare hvorfor ExpressRoute ikke er det samme som VPN, hvorfor Private Endpoint ikke erstatter all nettverkssikkerhet, og hvorfor en NSG-regel ikke gir samme kontrollnivå som en sentral brannmur.
En annen feil er å overse drift. AZ-700-spørsmål kan beskrive et miljø som ser riktig ut på papiret, men der DNS, rutepreferanse, logging eller overvåking mangler. I virkelige Azure-miljøer er disse detaljene ofte forskjellen mellom et design som kan driftes og et design som bare kan tegnes.
Det er også lett å undervurdere kostkonsekvensene av logging, datatrafikk, sonedistribusjon og tilkoblingstjenester. Eksamenen krever ikke at kandidaten husker lokale priser, men den belønner forståelsen av at arkitekturvalg påvirker både robusthet og kost over tid.
Veien videre for nettverksingeniører
AZ-700 er mest verdifull når forberedelsen bygger praktisk dømmekraft. Kandidaten bør kunne tegne et hybridmønster, forklare rutingvalgene, sikre administrativ tilgang uten unødvendige offentlige IP-adresser, etablere privat PaaS-tilgang og feilsøke trafikk med Azure Monitor og Network Watcher.
Den mest effektive neste handlingen er å bygge et lite labmiljø, dokumentere hvert designvalg og sammenligne løsningen med Microsofts oppdaterte eksamensmål. Når lesingen, labbene og feilsøkingen henger sammen, blir AZ-700 mindre en teoretisk test og mer en strukturert måte å utvikle Azure-nettverkskompetanse på.
