Fördelar med en praktisk AZ-700-studieplan: labbar, scenarier och bättre beslut

En praktisk AZ-700-studieplan är ett sätt att träna Azure-nätverk som sammanhängande designbeslut snarare än som isolerade tjänster. Nätverksämnena kan annars verka separata tills provfrågorna binder ihop routing, DNS, säkerhet och applikationsleverans i samma scenario. Den som bara läser tjänst för tjänst riskerar därför att känna igen begreppen men ändå missa varför en viss design passar bättre än en annan.

AZ-700 är provet för certifieringen Microsoft Certified: Azure Network Engineer Associate och fokuserar på att designa, implementera och hantera nätverkslösningar i Microsoft Azure. En bra studieplan behöver därför kombinera officiella provmål, praktiska labbar och beslutsträning kring verkliga arkitekturval, inte enbart repetition av produktnamn.

Senast uppdaterad: 2026. Artikeln utgår från Microsofts aktuella AZ-700-inriktning vid publicering, men kandidater bör alltid kontrollera Microsofts officiella Exam Guide före bokning eftersom provmål, tjänstebeteenden och frågetyper kan ändras. Microsoft Learn är också den säkraste platsen för aktuell information om provformat, retake-policy och pris, eftersom sådana detaljer kan ändras utan att äldre studieguider uppdateras.

Vad AZ-700 faktiskt testar

AZ-700 mäter inte om kandidaten kan definiera varje nätverkstjänst isolerat. Provet testar om kandidaten kan välja, kombinera och felsöka Azure-nätverkstjänster när krav på säkerhet, tillgänglighet, namnupplösning, routing och prestanda drar åt olika håll.

Microsofts egen inlärningsväg för Designing and Implementing Microsoft Azure Networking Solutions är därför en naturlig bas. Den bör läsas tillsammans med tjänstedokumentationen, särskilt för VPN Gateway, ExpressRoute, Private Link, Azure Firewall, Application Gateway, Azure Front Door, Load Balancer, Network Watcher och Azure DNS.

Den som redan arbetar som nätverksingenjör, systemadministratör eller cloud engineer har ofta en fördel i grundläggande IP, routing och felsökning. Samtidigt har traditionell nätverkserfarenhet en fallgrop: Azure-design styrs av tjänsternas gränser, regioner, PaaS-integrationer och policyobjekt. En lösning som är rimlig i ett datacenter kan bli dyr, svår att felsöka eller otillräckligt säker i molnet om den kopieras utan anpassning.

En 4-veckors studieplan som bygger färdighet, inte bara minne

En effektiv AZ-700-plan bör börja med kärnnätverket och därefter lägga på hybridanslutning, applikationsleverans, privat åtkomst och säkerhet. Ordningen spelar roll eftersom senare ämnen ofta förutsätter att VNet-design, subnät, routning och DNS redan sitter.

1. Vecka 1: Bygg två VNets med subnät, peering, UDR och grundläggande Azure DNS, och verifiera flöden med Network Watcher.
2. Vecka 2: Lägg till S2S VPN, P2S VPN och ett hybrid-DNS-scenario där Azure och on-premises behöver lösa privata namn korrekt.
3. Vecka 3: Jämför Load Balancer, Application Gateway och Front Door genom att publicera samma testapplikation med olika krav på räckvidd, TLS och WAF.
4. Vecka 4: Repetera säkerhetskontroller, ExpressRoute-koncept, övervakning och fallstudier under tidspress med fokus på varför fel alternativ är fel.

Varje vecka bör avslutas med en kort designanteckning: krav, vald tjänst, antaganden, risker och hur lösningen verifierades. Det gör provförberedelsen mer lik verkligt arbete och tränar samma resonemang som scenariobaserade frågor kräver.

Labbarna bör vara återskapbara. Bicep eller Terraform gör det lättare att riva och bygga upp miljöer igen, vilket minskar risken att lärandet fastnar i portalens klickflöden. Tidsboxade labbar är också värdefulla: en kandidat som kan felsöka ett DNS- eller routningsproblem på begränsad tid är bättre förberedd för både provet och produktion.

Följande Bicep-exempel visar en enkel grund för vecka 1: ett VNet med separata subnät för applikation och privat åtkomst. Syftet är inte att täcka all nätverksdesign, utan att skapa en repeterbar miljö där subnät, DNS och säkerhetskontroller kan läggas till stegvis.

Example — grundläggande VNet för AZ-700-labb

param location string = resourceGroup().location

resource labVnet 'Microsoft.Network/virtualNetworks@2023-11-01' = {
  name: 'vnet-az700-lab-se'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.40.0.0/16'
      ]
    }
    subnets: [
      {
        name: 'snet-app'
        properties: {
          addressPrefix: '10.40.10.0/24'
        }
      }
      {
        name: 'snet-private-endpoints'
        properties: {
          addressPrefix: '10.40.20.0/24'
          privateEndpointNetworkPolicies: 'Disabled'
        }
      }
    ]
  }
}

Efter distributionen bör kandidaten kontrollera adressrymder, subnätsegenskaper och eventuell peering innan fler tjänster läggs till. Den viktiga lärdomen är att provet ofta testar konsekvenser av en design, exempelvis om en route table påverkar trafikflödet eller om ett subnät är lämpligt för Private Endpoints.

Beslutsramverk för applikationsleverans

En vanlig AZ-700-svårighet är att Azure Load Balancer, Azure Application Gateway och Azure Front Door alla kan uppfattas som belastningsutjämning. Skillnaden ligger i lager, räckvidd, TLS-hantering, WAF-stöd och var trafiken ska styras.

Den praktiska frågan är var beslutet ska tas. Om kravet gäller privat regional trafik på transportnivå pekar det ofta mot Load Balancer. Om kravet gäller HTTP-baserad routing inom en region är Application Gateway ofta mer relevant. Om kravet gäller global användartrafik, edge-nära TLS och failover mellan regioner är Front Door normalt den tjänst som bör utvärderas först.

Det är också viktigt att inte blanda ihop Azure Front Door med Traffic Manager. Front Door hanterar HTTP/S-trafik vid Microsofts globala edge och kan terminera TLS samt använda WAF. Traffic Manager är DNS-baserad styrning och fungerar på ett annat sätt, vilket påverkar både failover-beteende och klientupplevelse.

Microsoft beskriver hur det globala nätverket utvecklas för reliabilitet och intelligent trafikstyrning i sin artikel om global network reliability. För AZ-700 är poängen inte att memorera nätverkets storlek, utan att förstå varför global och regional applikationsleverans leder till olika tjänsteval.

Hybridanslutning: där routing och DNS ofta avgör svaret

Hybridfrågorna i AZ-700 handlar ofta om mer än att välja mellan VPN och ExpressRoute. Kandidaten behöver förstå hur S2S VPN, P2S VPN, ExpressRoute och Azure Virtual WAN påverkar drift, routning, skalning och felsökning.

S2S VPN passar ofta som en snabbare väg till krypterad anslutning mellan ett lokalt nät och Azure, medan P2S VPN löser åtkomst för enskilda klienter. ExpressRoute används när privat anslutning, förutsägbar routing och integration med operatör eller connectivity provider är centrala krav. Azure Virtual WAN blir relevant när många platser, hubbar och anslutningstyper ska hanteras mer samlat.

ExpressRoute kräver särskild uppmärksamhet på BGP. AS-nummer, route filters, annonserade prefix och path selection påverkar hur trafik faktiskt går. Om UDR, NVA:er och on-premises routing inte planeras tillsammans kan asymmetrisk routing uppstå, där trafik går ut en väg och kommer tillbaka en annan. Det är en typ av problem som ofta syns som intermittent fel, brutna sessioner eller säkerhetskontroller som verkar bete sig inkonsekvent.

Prestanda bör inte bedömas genom antaganden. Microsofts dokumentation om Azure network latency ger en bättre utgångspunkt för att resonera om avstånd, regionval och mätning. I labb bör Connection Monitor, IP flow verify och effektiva routningstabeller användas för att bevisa var trafiken går och var den stoppas.

Private Endpoints, Service Endpoints och DNS-fällan

Private Endpoints och Service Endpoints blandas ofta ihop, men de löser olika problem. En Private Endpoint ger en privat IP-adress i ett VNet för åtkomst till en PaaS-resurs via Private Link. En Service Endpoint behåller åtkomstvägen mot tjänstens publika endpoint men låter tjänsten begränsa åtkomst baserat på VNet eller subnät.

Den stora praktiska fallgropen med Private Endpoints är namnupplösning. Om Private DNS Zones, länkning till rätt VNets och DNS-forwarding från on-premises inte är på plats kan klienter fortsätta lösa tjänstens publika namn till fel adress. Resultatet blir ofta att anslutningen ser korrekt ut i nätverksdesignen men misslyckas i applikationen.

I hybridmiljöer behöver detta testas från båda håll. En virtuell maskin i Azure, en klient via P2S och en server på plats kan få olika DNS-svar beroende på resolverkedjan. Därför bör labben innehålla namnuppslagning, anslutningstest och kontroll av vilken IP-adress klienten faktiskt använder, inte bara en kontroll av att Private Endpoint-objektet finns.

Säkerhetsgränser: NSG, ASG, Azure Firewall och WAF

AZ-700 kräver tydlig förståelse för var olika säkerhetskontroller hör hemma. NSG:er filtrerar trafik på subnät eller nätverkskort och arbetar med regler för källor, destinationer, portar och protokoll. ASG:er förenklar regelhantering genom att gruppera virtuella maskiners nätverkskort logiskt, men de ersätter inte en brandvägg.

Azure Firewall är en centraliserad nätverkssäkerhetstjänst som ofta placeras i en hubb för att styra utgående, inkommande och öst-väst-trafik beroende på design. WAF skyddar däremot webbapplikationer på HTTP/S-nivå och används med tjänster som Application Gateway eller Front Door. Om WAF placeras där problemet egentligen är generell nätverkssegmentering, eller om NSG:er används där centraliserad egresskontroll krävs, blir designen svag och provsvaret ofta fel.

Ett bra sätt att studera säkerhetsdelen är att ställa två frågor för varje kontroll: vilket lager skyddar den, och vilken trafik ser den faktiskt? Den metoden avslöjar snabbt om en föreslagen lösning skyddar användartrafik, workload-trafik, internetutgång, PaaS-åtkomst eller HTTP-applikationen.

Så bör provfrågor läsas

Scenariobaserade frågor i AZ-700 innehåller ofta fler detaljer än vad som behövs. Kandidaten bör först identifiera hårda krav: global eller regional räckvidd, privat eller publik åtkomst, HTTP eller TCP/UDP, behov av WAF, hybridberoenden, failoverkrav och begränsningar i befintlig topologi.

Därefter bör uppenbart fel tjänstekategori tas bort innan alternativen jämförs. Om frågan kräver L7-regler är en ren L4-lösning svag. Om kravet gäller privat PaaS-åtkomst räcker inte ett generellt påstående om nätverkssäkerhet. Om DNS-svar måste vara privata från on-premises behöver lösningen inkludera namnupplösning, inte bara nätverksväg.

Tidshantering handlar framför allt om att inte fastna i okända tjänstedetaljer. Om två alternativ verkar möjliga bör kandidaten leta efter formuleringar som ändrar skalan, exempelvis global kontra regional, eller trafiksättet, exempelvis HTTP/S kontra TCP. Vid osäkerhet är det bättre att markera frågan, gå vidare och återvända med mer tid kvar än att låta en enda tjänstefiness styra hela provpasset.

Studiematerial och strukturerad träning

Microsoft Learn och den officiella Exam Guide bör vara huvudkällor eftersom de speglar Microsofts aktuella provmål. Dokumentation för varje tjänst behövs därefter för detaljer som inte alltid ryms i inlärningsvägen, exempelvis begränsningar, DNS-beteenden, routingkonsekvenser och felsökningsverktyg.

Böcker och videomaterial kan vara användbara när de används selektivt, men de bör inte ersätta labbar. AZ-700 belönar förståelse av designval, och den förståelsen uppstår snabbare när kandidaten själv bryter en route, felkonfigurerar DNS, testar WAF-beteende eller jämför applikationsleveransalternativ i en kontrollerad miljö.

Den som vill kombinera egen labbträning med lärarledd struktur kan använda Readynezs utbildning för Microsoft Certified Azure Network Engineer som ett sätt att arbeta igenom AZ-700-ämnena mer sammanhållet. Det viktigaste är att varje utbildningspass kopplas till praktiska tester och egna anteckningar om varför en viss design valdes.

Vanliga frågor om AZ-700

Behöver kandidaten kunna Azure-administration innan AZ-700?

Grundläggande Azure-erfarenhet hjälper, särskilt kring resurser, regioner, prenumerationer, övervakning och identitetsberoenden. AZ-700 är dock främst ett nätverksprov, så tyngdpunkten bör ligga på VNet-design, routing, hybridanslutning, säker nätverksåtkomst, DNS och applikationsleverans.

Är labbar viktigare än övningsfrågor?

Båda behövs, men de fyller olika funktioner. Labbar bygger förståelse för hur Azure beter sig, medan övningsfrågor tränar läsning av scenarier och elimineringsstrategi. Kandidater som enbart gör frågor kan missa de praktiska detaljer som avslöjar rätt design i ett nytt scenario.

Vilket ämne underskattas oftast?

DNS i kombination med Private Endpoints och hybridmiljöer underskattas ofta. Många anslutningsproblem beror inte på att nätverksvägen saknas, utan på att klienten löser fel namn till fel IP-adress eller använder en resolver som inte känner till den privata zonen.

Hur bör provdatum väljas?

Provdatum bör sättas när kandidaten kan förklara tjänstevalen utan att läsa innantill och kan felsöka enkla labbproblem med Network Watcher eller Connection Monitor. Före bokning bör Microsofts officiella sidor kontrolleras för aktuella regler, pris, tillgänglighet och eventuella ändringar i provguiden.

Att göra AZ-700-förberedelsen användbar i produktion

Den bästa AZ-700-förberedelsen är den som lämnar efter sig fungerande labbar, tydligare designresonemang och bättre felsökningsvanor. Kandidaten bör kunna motivera varför en lösning använder Front Door i stället för Application Gateway, varför Private DNS behövs för en Private Endpoint, och hur BGP, UDR och säkerhetskontroller påverkar verkliga trafikflöden.

När studieplanen kombinerar Microsofts officiella material, återuppbyggbara labbar och scenarier under tidspress blir certifieringsarbetet mer än provträning. Readynez kan vara ett stöd för den som vill ha en strukturerad väg genom ämnena, men den avgörande färdigheten är att kunna översätta krav till en nätverksdesign som går att driftsätta, verifiera och felsöka.