✓ 01 AD→ ✓ 02 AGDLP+PS→ ✓ 03 GPO→ ✓ 04 NTFS→ 05 Azure→ 06 Nettverk
Modul 05 av 6 ★ Medium prioritet ⚡ Interaktiv

Azure
styringsstruktur

Vi forlater Windows Server og går inn i skyen. Samme grunnprinsipper – hierarki, tilgangskontroll, policyer – men et helt nytt landskap. Eksamen tester Management Groups, RBAC, Azure Policy og Tags.

~40 minLesetid
9Seksjoner
13Øvelser
I denne modulen
  1. Fra on-prem til sky – hvorfor et hierarki?flervalg
  2. Azure-hierarkiet: 4 nivåerbygg
  3. RBAC – Role-Based Access Controlmatchflervalg×2
  4. Azure Policy – tving regler på ressurserklassifiserflervalg
  5. Tags – organisering og sporbarhetbyggflervalg
  6. Azure Cost Managementflervalg
  7. FINAL BOSS – mixed challenge🔥 boss
  8. Oppsummering
§ 01 — Motivasjon

Fra on-prem til sky – hvorfor et hierarki?

Bedriften Nimbostratus AS bestemte seg for å starte i Azure. De oppretter én subscription, putter alt inn der, og begynner å lage virtuelle maskiner. Etter 3 måneder:

Dette er problemet Azure-styringsstrukturen løser. Microsoft tilbyr et fire-nivå-hierarki som gir deg kontroll over hvem som kan gjøre hva, hvor, og til hvilken kostnad.

Tenk på det som et konsern. Konsernet (Management Group) eier flere selskaper (Subscriptions). Hvert selskap har avdelinger (Resource Groups). Avdelingene har ansatte og utstyr (Resources). Regler på konsernnivå gjelder alt nedover – men du kan også ha avdelingsspesifikke regler.

🧠 Sjekk forståelsen · flervalg
Hva er den primære fordelen med Azure-hierarkiet (Management Groups → Subscriptions → Resource Groups)?
B er korrekt. Hierarkiet gir governance – styring av tilgang (RBAC), regler (Policy) og kostnader (Cost Management) på et strukturert vis.
Tenk på Nimbostratus-problemene: tilgang uten kontroll, uventede kostnader, feil ressursplassering. Hierarkiet løser disse. Svar B.
§ 02 — Hierarkiet

Azure-hierarkiet: 4 nivåer

Azure-strukturen har fire nivåer du må kjenne til. Regler og tilganger arves automatisk nedover – akkurat som GPO-arv i on-prem:

🏢
Management Group
Grupperer subscriptions. Regler her gjelder alle under. Typisk: én per forretningsdomene (Prod / Dev / Test)
💳
Subscription
Faktureringsenhet + tilgangsgrense. Alle ressurser tilhører én subscription. Typisk: én per avdeling eller miljø
📦
Resource Group
Logisk beholder for relaterte ressurser med lik livssyklus. Slett én Resource Group = slett alle ressurser i den
⚙️
Resource
Selve tjenesten: VM, database, storage account, VNet osv.

Merk: RBAC-tilganger og Azure Policies arves nedover i hierarkiet. Sett en Owner-rolle på Subscription-nivå → gjelder automatisk alle Resource Groups og Resources under.

📌 Eksamensdetalj
Resource Group er en nøkkelkonsept: det er ikke bare en mappe – det er en livssyklus-enhet. Du oppretter VM, VNet, og storage account i samme Resource Group fordi de hører til én applikasjon. Sletter du Resource Group, sletter du alt. Dette brukes bevisst for opprydning.
⚡ Interaktiv øvelse · hierarki-rekkefølge sequence builder
Bygg Azure-hierarkiet fra topp til bunn
Klikk nivåene i riktig rekkefølge – fra øverste styringsnivå ned til selve ressursen.
0 / 4 plassert
Resource Group
Management Group
Resource
Subscription
Perfekt! 🎓 Management Group → Subscription → Resource Group → Resource. Husk: regler arves nedover, og du kan overstyre på hvert nivå (som LSDOU i GPO!)
§ 03 — RBAC

RBAC – Role-Based Access Control

RBAC i Azure er det direkte ekvivalentet til AGDLP fra Modul 2 – men for sky-ressurser. I stedet for NTFS-rettigheter tildeler du roller til brukere eller grupper på et bestemt scope (nivå i hierarkiet).

De tre RBAC-komponentene

KomponentHva det erEksempel
Security PrincipalHvem som får tilgang (bruker, gruppe, service principal)Kari Hansen, g_devops
Role DefinitionHva de kan gjøre (samling av tillatelser)Contributor, Reader, Owner
ScopeHvor tilgangen gjelder (MG, Sub, RG, Resource)Subscription "Prod"

De fire innebygde roller du må kjenne

Owner– Full tilgang + kan tildele RBAC til andre
Contributor– Full tilgang til ressurser, MEN kan ikke tildele RBAC
Reader– Kan se ressurser, men ikke endre noe
User Access Administrator– Kan bare administrere RBAC-tilganger, ikke ressurser

Scope-arv i RBAC

Sett en rolle på Management Group-nivå → gjelder alle subscriptions, resource groups og resources under. Sett den på Resource Group-nivå → gjelder kun ressurser i den gruppen. Nærmere ressursen = smalere scope.

⚡ Eksamenstips: Owner vs Contributor
Den viktigste forskjellen: Owner kan tildele RBAC til andre, Contributor kan det ikke. Dette er en klassisk fallgruve. Contributor kan gjøre ALT med selve ressursene, men kan ikke gi andre folk tilgang.
⚡ Interaktiv øvelse · RBAC-roller match pairs
Match scenariet til riktig rolle
Klikk scenario, deretter riktig rolle. Hvilken rolle passer best for hvert behov?
0 / 4 matchet
Scenario
Sjefen vil se en oversikt over alle Azure-ressurser men skal ikke røre noe
En utvikler skal kunne opprette og endre VMs, men ikke gi andre tilgang
IT-ansvarlig skal ha full kontroll, inkludert å onboarde nye teammedlemmer
En støtteingeniør skal bare administrere hvem som har tilgang, ikke selve ressursene
Rolle
Owner
Reader
User Access Administrator
Contributor
Glimrende! 🎯 Reader = se, Contributor = gjøre (ikke RBAC), Owner = alt, UAA = kun tilgangsstyring.
🧠 Sjekk forståelsen · flervalg
Hva er den viktigste forskjellen mellom rollen Owner og rollen Contributor i Azure RBAC?
Spot on! 🎯 Dette er den viktigste RBAC-distinksjonen: Owner kan delegere tilgang videre, Contributor kan ikke.
A er feil (begge kan opprette). C er feil (begge kan brukes på alle scopes). D er feil. Den avgjørende forskjellen er RBAC-tildeling. Svar B.
🧠 Sjekk forståelsen · scope-arv
Du tildeler en bruker rollen Reader på Subscription-nivå. Hva gjelder?
Riktig! ✨ RBAC arves nedover i hierarkiet. Reader på Subscription = Reader på alle RGs og ressurser under – nøyaktig samme prinsipp som GPO-arv.
Arv er kjerneprinsippet. Scope på høyere nivå → gjelder alt under. Svar C.
§ 04 — Azure Policy

Azure Policy – tving regler på ressurser

RBAC styrer hvem som kan gjøre noe. Azure Policy styrer hva som er lov å gjøre – uansett hvem du er. Det er forskjellen mellom «hvem har nøkkelen» og «hvilke rom finnes i det hele tatt».

«Selv om en bruker har Contributor-tilgang, kan du via Azure Policy hindre dem fra å opprette ressurser i bestemte regioner, av bestemte størrelser, eller uten påkrevde Tags.»

Hva kan Policy gjøre?

Eksempler fra pensumet ditt

🌍 Begrense lokasjoner

  • Policy: «Ressurser kan kun opprettes i Norway East og Norway West»
  • Effekt: Ingen kan opprette noe i Australia eller USA
  • Løser: Uventede kostnadsfakturaer fra feil region

🏷️ Håndheve Tags

  • Policy: «Alle ressurser MÅ ha taggen 'Miljø' og 'Kostsenter'»
  • Effekt: Kan ikke opprette ressurs uten disse taggene
  • Løser: Uidentifiserbare ressurser i kostnadsoversikten

📐 Begrense SKU

  • Policy: «Kun VM-størrelsene B2s og B4ms er tillatt»
  • Effekt: Ingen kan opprette dyre GPU-VMs ved en feil
  • Løser: Kostnadskontroll for dev-miljøer

🔐 Sikkerhetskrav

  • Policy: «Storage accounts MÅ ha HTTPS-only»
  • Effekt: Ikke mulig å lage usikrede storage-kontoer
  • Løser: Sikkerhetssvakheter fra feilkonfigurering
⚡ Interaktiv øvelse · Policy-effekter drag to bucket
Match scenariet til riktig Policy-effekt
Klikk scenariet, deretter riktig Policy-effekt-type.
Klikk scenario → klikk effekt
0 / 6 plassert
Blokkér oppretting av VM i Australia-regioner
Logg alle storage accounts uten HTTPS, men blokker ikke
Forhindre oppretting av ressurser uten påkrevd Tag
Varsle sikkerhetsadmin hvis en NSG-regel åpner port 22
Tillat kun VM-størrelsene B2s og B4ms
Rapporter alle public IP-adresser uten DDoS-beskyttelse
🚫 Deny (blokker)
📋 Audit (logg/varsle)
Nydelig! 🎓 Deny = hardkode et forbud. Audit = overvåk og varsle. Mange bruker Audit først for å se omfanget, deretter oppgraderer til Deny.
🧠 Sjekk forståelsen · flervalg
Hva er den viktigste forskjellen mellom RBAC og Azure Policy?
Yes! 🔥 RBAC = tilgangskontroll (hvem). Policy = ressurskontroll (hva). De utfyller hverandre.
De to fungerer komplementært. RBAC: «hvem har nøkkelen». Policy: «hvilke rom finnes». Svar C.
§ 05 — Tags

Tags – organisering og sporbarhet

Tags er nøkkel-verdi-par du legger på Azure-ressurser for å organisere dem. De er enkle men kraftige – og er forutsetningen for god kostnadsstyring.

En tag ser slik ut:

Miljø: Produksjon Kostsenter: IT-Drift Prosjekt: NovaTech-CRM Eier: kari.hansen

Hva brukes tags til?

⚠️ Tags arves IKKE automatisk
Tags arves ikke nedover i hierarkiet som GPO-er eller RBAC. Setter du en tag på Resource Group, gjelder den ikke automatisk på ressursene inne i den. Du kan bruke Azure Policy (Append-effekt) til å tvinge taginheritance.
⚡ Interaktiv øvelse · Tag-strategi sequence builder
Sett opp riktig governance-strategi med Tags
NovaTech vil ha full kostnadskontroll. Klikk stegene i riktig rekkefølge for å sette opp en fungerende Tag-strategi.
0 / 4 plassert
Bruk Azure Cost Management filtrert på Kostsenter-tag
Definer tag-strategi: Miljø, Kostsenter, Eier
Sett opp budsjett-varsler per Kostsenter
Opprett Azure Policy som krever disse taggene på alle ressurser
Perfekt flyt! 🌟 Definer → Håndhev med Policy → Analyser med Cost Management → Varsle ved overskridelse.
🧠 Sjekk forståelsen · flervalg
Hva er det viktigste å vite om Tags og arv i Azure-hierarkiet?
Viktig! 🎓 Dette er en klassisk feil. Tags arves IKKE automatisk. Du trenger Azure Policy (Append) for å tvinge tag-nedarving.
Husk: Tags ≠ GPO-er. De arves ikke automatisk. En tag på RG smitter ikke automatisk over på VMs inne i RG-en. Svar B.
§ 06 — Kostnadsstyring

Azure Cost Management – hold kontroll på fakturaen

Azure Cost Management er verktøyet i Azure Portal som gir deg oversikt over forbruk og kostnader. Du trenger grunnleggende forståelse av dette til eksamen.

📊 Cost Analysis

  • Se kostnader fordelt på tjeneste, region, Resource Group, eller Tag
  • Filtrer på «Kostsenter»-tag for å se hva IT-Drift bruker
  • Sammenlign måneder og trender

🔔 Budgetter og varsler

  • Sett et månedlig budsjett (f.eks. 50.000 kr)
  • Varsle via e-post ved 80% og 100% av budsjettet
  • Varsle relevante team (Kostsenter-eier)

Koblingen mellom Tags og Cost Management er avgjørende: uten tags vet du ikke hvem som bruker pengene. Med tags kan du vise: «Markedsføring-avdelingen brukte 120% av budsjettet denne måneden».

🧠 Sjekk forståelsen · flervalg
Hva er sammenhengen mellom Tags og Azure Cost Management?
Riktig! 💡 Tags er kostnadssporingens ryggrad. Uten Tags: én stor faktura, ingen fordeling. Med Tags: full oversikt per Kostsenter/Prosjekt/Miljø.
Tags endrer ikke pris (A er feil). Cost Management fungerer uten Tags (B er feil), men er mye mer verdifullt med. Svar C.
🔥 § 07 — Final boss

Mixed challenge
– kan du Azure governance?

Seks spørsmål som dekker hele modulen. Disse er designet med distractors som krever faktisk forståelse.

⚔️ Boss 1 av 6 · Hierarki-orden
I hvilket Azure-hierarkinivå definerer du vanligvis en faktureringsenhet med egne kostnadskontroller?
Riktig! Subscription er fakturaenheten i Azure. Én subscription = én faktura. Ressurser faktureres til sin subscription.
Management Group er for governance, Resource Group er for livssyklus, Resource er selve tjenesten. Fakturering = Subscription. Svar B.
⚔️ Boss 2 av 6 · RBAC-scope
Du gir en bruker Reader-rollen på Management Group-nivå. Hvad har brukeren tilgang til å SE?
Ja! RBAC arves nedover i hierarkiet. Reader på MG = Reader på alt under. Same prinsipp som GPO-arv og NTFS-arv.
RBAC-arv gjelder i hele hierarkiet. MG er øverst, alt under arver. Svar C.
⚔️ Boss 3 av 6 · Policy vs RBAC
En bruker med Contributor-tilgang prøver å opprette en VM i East US, men en Azure Policy sier «Kun Norway East tillatt». Hva skjer?
Spot on! 🎯 Azure Policy er en hård regel – den gjelder uansett RBAC-nivå. Policy Deny blokkerer selv Owner!
Policy og RBAC er to forskjellige lag. RBAC sier «hvem kan prøve». Policy sier «hva er lov». Policy Deny vinner. Svar C.
⚔️ Boss 4 av 6 · Resource Group
Hva skjer med alle VM-er, VNet og storage accounts hvis du sletter en Resource Group?
Viktig å huske! ⚠️ Resource Group = livssyklus-enhet. Slett RG = slett alt inne. Bruk dette bevisst for opprydning (f.eks. slett et dev-miljø med én operasjon).
Ressurser i en RG er knyttet til den. Sletter du RG-en, sletter du alt. Svar C.
⚔️ Boss 5 av 6 · Tags-arv
Du setter tag «Miljø: Produksjon» på en Resource Group. En ny VM opprettes inne i RG-en. Hvilken tag har VM-en?
Riktig! 🎯 Tags arves IKKE automatisk. VM-en er tagless med mindre du setter tag manuelt eller bruker Azure Policy (Append) for automatisk tag-nedarving.
Husk: Tags ≠ RBAC/GPO. Tags arves ikke automatisk nedover. VM-en er uten tag. Svar B.
⚔️ Boss 6 av 6 · Komplett scenario
Eksamen-stil: Bedriften vil at alle ressurser alltid har taggen «Kostsenter», og at ingen kan opprette ressurser utenfor Norway East. Hvilken Azure-funksjonalitet løser begge disse kravene?
Topp! 🏆 Azure Policy er verktøyet for å håndheve regler på ressurser. To Policy-definisjoner: én for region (Deny), én for tag (Deny/Append).
RBAC styrer tilgang, ikke ressursegenskaper. Navnekonvensjon er ikke teknisk håndhevbart. Policy er svaret. Svar C.
💪 6/6? Du har knust Azure governance-pensumet!
§ 08 — Oppsummering

Nøkkelpunktene du må huske

📋 Modul 5 – Cheat sheet

→ NESTE – SISTE MODUL

Modul 6: Azure-nettverk

Den siste og kanskje viktigste modulen! Vi tar VNet, subnett, NSG, Hub-Spoke-topologi, Azure Firewall, VPN Gateway og en introduksjon til AKS og ACR. Alt dette er høy prioritet på eksamen. 🚀

VNet + subnett NSG-regler Hub-Spoke Azure Firewall VPN Gateway P2S AKS + ACR