Question 1

Iedereen logt in met het root-account van AWS

Accepted Answer

1. Zet hardware-MFA op het root-account en berg de sleutel fysiek op
2. Verwijder access-keys van het root-account, daar is geen legitiem gebruik voor
3. Maak per persoon een IAM-user of liever een Identity Center-account
4. Documenteer waar het rootwachtwoord en MFA-device liggen, twee personen weten dit

Wanneer ons inschakelen: 
Is het root-wachtwoord onbekend, AWS-support kan helpen via accountverificatie. Reken op meerdere dagen.

Question 2

Iedere developer heeft AdministratorAccess

Accepted Answer

1. Inventariseer wie echt admin nodig heeft, vaak slechts 1 of 2 personen
2. Geef developers PowerUserAccess of een aangepaste policy zonder IAM-rechten
3. Zet IAM Access Analyzer aan om ongebruikte permissies te zien
4. Review elk kwartaal en knip rechten weg die niemand gebruikt

Wanneer ons inschakelen: 
Voor compliance-trajecten (ISO, SOC2) hoort least-privilege bij de baseline. Plan tijd.

Question 3

Iedereen heeft losse IAM-users met eigen wachtwoord

Accepted Answer

1. Activeer IAM Identity Center op je organization-account
2. Koppel aan Entra ID, Google Workspace of de ingebouwde directory
3. Maak permission-sets per rol (Developer, ReadOnly, Billing) en wijs toe per account
4. Verwijder oude IAM-users zodra iedereen via SSO werkt

Wanneer ons inschakelen: 
Werk je in meerdere AWS-accounts, AWS Organizations plus Identity Center is praktisch verplicht.

Question 4

Niet alle IAM-users hebben MFA

Accepted Answer

1. Maak een policy die alle acties weigert tot MFA actief is, behalve self-service MFA-setup
2. Hang die policy aan een groep en zet alle users erin
3. Communiceer 1 week vooraf en lever stappenplan met authenticator-app aan
4. Controleer via IAM-credential-report dat iedereen MFA heeft

Wanneer ons inschakelen: 
SMS-MFA is zwak. Gebruik TOTP-app of beter een security-key.

Question 5

App gebruikt persoonlijke access-keys in productie

Accepted Answer

1. Maak een IAM-role met alleen de rechten die de app nodig heeft
2. Hang de role aan EC2-instance, Lambda of ECS-task definition
3. Verwijder de access-keys uit env-vars en git-history
4. Roteer alle keys die ooit in code stonden, ze kunnen al gelekt zijn

Wanneer ons inschakelen: 
Lekte een key in een publieke repo, schakel meteen GuardDuty in en review CloudTrail van de afgelopen 90 dagen.

Question 6

Documentatie zegt Azure AD, portal zegt Entra ID, wat is wat

Accepted Answer

1. Lees 'Azure AD' in oude docs als 'Entra ID' tenzij anders blijkt
2. PowerShell-modules AzureAD en MSOnline zijn deprecated, gebruik Microsoft.Graph
3. Entra ID Free zit bij elke M365-tenant, P1/P2 licenties geven extra features
4. Conditional Access en Identity Protection vereisen P1 of P2

Wanneer ons inschakelen: 
Voor B2B/B2C-scenarios is Entra External ID het nieuwe product. Plan een aparte review.

Question 7

Iedereen is Owner op de Azure-subscription

Accepted Answer

1. Geef Owner alleen op subscription-niveau aan 1 of 2 personen
2. Developers krijgen Contributor op resource-group-niveau van hun project
3. Reader voor mensen die alleen monitoring nodig hebben
4. User Access Administrator alleen aan iemand die rollen mag delegeren

Wanneer ons inschakelen: 
Voor groeiende organisaties, gebruik management-groups en Azure Policy om consistent toe te wijzen.

Question 8

GCP-project waar iedereen Editor is

Accepted Answer

1. Vervang Editor door specifieke rollen zoals Compute Admin of Storage Object Viewer
2. Gebruik folders om dev, test en prod te scheiden met eigen IAM
3. Zet Organization Policy aan om externe accounts te blokkeren waar nodig
4. Audit met Policy Analyzer welke principals welke rechten daadwerkelijk hebben

Wanneer ons inschakelen: 
Custom roles maken kan, maar onderhoud is werk. Probeer eerst predefined roles.

Question 9

GCP-service-account-key json staat in repo

Accepted Answer

1. Roteer of disable de gelekte key direct in IAM
2. Voor GKE/Cloud Run, gebruik Workload Identity zodat geen key nodig is
3. Voor externe CI/CD, gebruik Workload Identity Federation met OIDC
4. Schoon git-history op met git-filter-repo of BFG, force-push

Wanneer ons inschakelen: 
Was de key publiek, controleer billing en audit-logs op misbruik. Crypto-mining is vaak het eerste teken.

Question 10

AWS-keys per ongeluk gepusht naar GitHub

Accepted Answer

1. Disable de keys direct in IAM, niet alleen 'verwijder commit'
2. Maak nieuwe keys aan en update de app of CI
3. Schakel CloudTrail-review en GuardDuty in om misbruik te zien
4. Zet pre-commit-hooks of Gitleaks/TruffleHog aan om herhaling te voorkomen

Wanneer ons inschakelen: 
Bij ongeautoriseerde resources (vooral GPU-instances), open een AWS-support-ticket. Misbruik kan worden gerefund.

Question 11

Geen idee of t3, m6i of c7g voor deze workload

Accepted Answer

1. Webserver met wisselende load: t-family met unlimited mode
2. Steady CPU-load (API, batch): m-family
3. CPU-zwaar (build, encoding): c-family
4. ARM-varianten (Graviton, t4g/c7g/m7g) zijn 20 procent goedkoper als je software ARM aankan

Wanneer ons inschakelen: 
Twijfel: Compute Optimizer geeft aanbevelingen op basis van werkelijk gebruik.

Question 12

Cloud-rekening loopt op door batchjobs

Accepted Answer

1. Geschikt voor batchjobs, CI-runners, rendering, training, niet voor stateful productie
2. Bouw retries en checkpoints in de app, instance kan binnen 2 minuten weg
3. Gebruik Spot Fleet of een mix van on-demand plus spot voor balans
4. Reken niet op specifieke instance-types altijd beschikbaar, mix

Wanneer ons inschakelen: 
Voor production-traffic, on-demand of Reserved blijven veiliger.

Question 13

On-demand prijzen over 24/7 workloads voelen veel te hoog

Accepted Answer

1. Inventariseer wat echt 24/7 draait in de afgelopen 3 maanden
2. Begin met 1-jaars commitment op de basislaag, niet op piek
3. Compute Savings Plans (AWS) zijn flexibeler dan EC2-Reserved
4. Review utilization maandelijks, ondergebruik betekent verspilling

Wanneer ons inschakelen: 
Bij grote bedragen, vraag enterprise-discount of EDP via je AWS/Azure-account-manager.

Question 14

Site valt om bij piek of we betalen overuren in rust

Accepted Answer

1. Definieer min, max en desired count, plus een metric zoals CPU of request-count
2. Test scale-out actief, niet alleen op papier
3. Plan scale-in voorzichtig, abrupte teruggang verlaagt cache-hit en breekt long-running requests
4. Gebruik launch-templates met dezelfde AMI/image en bootstrap-script

Wanneer ons inschakelen: 
Stateful apps (sessies, lokale bestanden) eerst stateless maken via Redis, S3 of database.

Question 15

Lambda is traag bij eerste request, snel daarna

Accepted Answer

1. Verklein deployment-package, minder dependencies = sneller
2. Vermijd zware init-code, lazy-load wat kan
3. Voor latency-kritisch: Provisioned Concurrency, kost wel geld
4. Overweeg ARM (Graviton2)-runtime, vaak iets sneller en goedkoper

Wanneer ons inschakelen: 
Bij sub-100ms-eis, Lambda is misschien gewoon de verkeerde keuze, kijk naar App Runner of ECS Fargate.

Question 16

S3-bucket groeit en niemand ruimt op

Accepted Answer

1. Identificeer welke prefix oude data bevat (logs, backups, exports)
2. Maak een lifecycle-rule: na 30 dagen naar Standard-IA, na 90 naar Glacier
3. Voor logs die je echt niet meer nodig hebt, expire na N dagen
4. Test eerst op een prefix, niet de hele bucket in 1 keer

Wanneer ons inschakelen: 
Voor compliance-data, controleer retentie-eisen voor je delete-rules zet.

Question 17

Blob-rekening van Azure groeit hard

Accepted Answer

1. Hot voor data die je dagelijks leest
2. Cool voor data die je maandelijks leest, goedkoper opslag duurder lezen
3. Cold/Archive voor backups en compliance, urenlang rehydrate-tijd
4. Lifecycle-management policy automatiseert verschuiving op basis van last-modified

Wanneer ons inschakelen: 
Voor analytics op grote sets, ADLS Gen2 met Hot is vaak goedkoper dan veel kleine reads op Cool.

Question 18

RDS-backup-strategie onduidelijk

Accepted Answer

1. Zet automated backups op minimaal 7 dagen, voor productie 30
2. Maak periodieke handmatige snapshots voor langere retentie
3. Test restore minimaal 1 keer per kwartaal in een test-account
4. Read-replica voor leeszware workloads of cross-region DR, niet als backup-vervanger

Wanneer ons inschakelen: 
Voor strikte RPO/RTO, kijk naar Multi-AZ plus cross-region replicas, hoort bij DR-plan.

Question 19

EBS-volumes en snapshots, hoe vaak en hoe lang

Accepted Answer

1. Gebruik Data Lifecycle Manager (DLM) of AWS Backup voor scheduling
2. Daily snapshots met 7-dagen retentie is een prima default
3. Voor productie-DBs: hourly tijdens kantooruren, daily 's nachts
4. Verwijder ongebruikte volumes (status: available), die kosten ook geld

Wanneer ons inschakelen: 
Voor cross-region DR, copy snapshots naar een ander region en versleutel met aparte KMS-key.

Question 20

Nieuwe VPC opzetten, welke CIDR

Accepted Answer

1. Vermijd 10.0.0.0/16 als default, dat botst overal mee
2. Kies een uniek block in de 10.x.x.x/16 range per VPC
3. Houd ruimte voor groei, /16 is ruim, /20 kan klap krijgen
4. Documenteer welk subnet welk doel heeft (public, private, db)

Wanneer ons inschakelen: 
Bij multi-cloud of on-prem-koppeling, plan IP-allocatie centraal in een spreadsheet of IPAM.

Question 21

Wat is verschil public en private subnet

Accepted Answer

1. Public: load-balancer, NAT-gateway, bastion (als je die nog gebruikt)
2. Private: app-servers, databases, alles wat geen direct internet hoeft
3. Outbound vanuit private gaat via NAT-gateway in public subnet
4. Multi-AZ: minimaal 2 subnets per type, 1 per AZ

Wanneer ons inschakelen: 
Wil je geen NAT-kosten, gebruik VPC-endpoints (gateway voor S3/DynamoDB, interface voor andere services).

Question 22

NAT-gateway is een grote post op AWS-rekening

Accepted Answer

1. Voor S3 en DynamoDB, gebruik gateway-endpoints, gratis en bypassen NAT
2. Voor andere AWS-services, interface-endpoints (PrivateLink) bypassen ook NAT
3. Ontwikkelomgevingen met weinig traffic kunnen 1 NAT delen tussen AZs (acceptabel risico)
4. Audit met VPC Flow Logs welke top-talkers door NAT gaan

Wanneer ons inschakelen: 
Bij honderden GB per dag, overweeg een dedicated NAT-instance of egress-architectuur.

Question 23

Security-group of NACL, wanneer wat

Accepted Answer

1. Default workflow: alles via security-groups, NACLs alleen als extra laag
2. NACLs zijn handig om hele IP-ranges te blokkeren op subnet-niveau
3. Onthoud: NACL is stateless, je moet inbound en outbound apart toestaan
4. Test wijzigingen niet in productie, NACL-deny is moeilijk te debuggen

Wanneer ons inschakelen: 
Voor strikte segmentatie, kijk naar AWS Network Firewall of Security Groups for Pods (EKS).

Question 24

Kantoor moet bij private cloud-resources

Accepted Answer

1. Aan cloud-kant: VPN-gateway plus customer-gateway met je publieke IP
2. Aan kantoor-kant: IPsec-config in firewall (Fortigate, Sophos, Mikrotik)
3. Pre-shared keys via wachtwoordkluis, niet email
4. Test failover van een tunnel-down-situatie

Wanneer ons inschakelen: 
Bij meerdere kantoren, AWS Transit Gateway of Azure Virtual WAN. Direct Connect/ExpressRoute alleen bij echt grote bandbreedte.

Question 25

Geen idee waar AWS-rekening vandaan komt

Accepted Answer

1. Activeer Cost Explorer in de billing-console (gratis)
2. Filter op service, region en linked-account om te zien wat domineert
3. Activeer cost-allocation-tags zodat je per project of klant kunt splitsen
4. Maak een wekelijkse anomalie-detection-rule die een mail stuurt bij afwijking

Wanneer ons inschakelen: 
Voor diepere analyse, exporteer CUR (Cost and Usage Report) naar S3 en analyseer met Athena.

Question 26

Cloud-rekening verraste je deze maand

Accepted Answer

1. AWS Budgets: maak budget op maandniveau plus alert op 50, 80 en 100 procent
2. Azure Cost Management: budget-alerts per subscription en resource-group
3. GCP Billing: budget-alerts per project, koppel aan Pub/Sub voor automation
4. Stuur alerts naar een gedeelde inbox of Slack, niet 1 persoon

Wanneer ons inschakelen: 
Bij een runaway-resource (mining, lekke key), nodig om kill-switch via Lambda of Functions te overwegen.

Question 27

Niet weten welk team welke cloud-kosten maakt

Accepted Answer

1. Definieer minimaal: Environment, Team, Project, CostCenter
2. Activeer tags als cost-allocation-tag in de billing-console
3. Forceer tags via SCP/Azure Policy/Org Policy bij creatie
4. Run maandelijks een rapport van untagged resources en pin teams aan op opruimen

Wanneer ons inschakelen: 
Bij groei: gebruik infra-as-code (Terraform) om tags consistent toe te passen, handmatig blijft achter.

Question 28

Je vermoedt dat veel resources niets doen maar wel kosten

Accepted Answer

1. Identificeer EBS-volumes met status 'available' (unattached), die kosten
2. Zoek RDS-instances met 0 connections in de afgelopen 7 dagen
3. Old EIPs niet attached zijn duur per uur
4. Test/dev-resources die buiten kantooruren niet stoppen, schedule via Lambda of Automation

Wanneer ons inschakelen: 
Tools als Cost Optimizer, Trusted Advisor (Business Support) of derden geven dashboards.

Question 29

Azure-rekening loopt zonder duidelijke reden op

Accepted Answer

1. Open Cost Management in de portal, filter op subscription en tijd
2. Group by resource type om te zien of compute, storage of netwerk domineert
3. Activeer Advisor-aanbevelingen, vaak vrij directe kostenbesparingen
4. Maak budgets per RG plus action-groups voor email of webhook

Wanneer ons inschakelen: 
Voor enterprise EA/MCA-klanten, exporteer naar storage en analyseer in Power BI of Fabric.

Question 30

On-prem-server moet naar de cloud, lift-and-shift

Accepted Answer

1. Inventariseer met Azure Migrate appliance: CPU, RAM, disk, dependencies
2. Right-size op basis van actueel gebruik, niet aankoop-specs
3. Replicate via Azure Migrate Server Migration of AWS MGN
4. Test cutover in dev eerst, plan onderhoudsvenster voor productie

Wanneer ons inschakelen: 
Voor gevoelige workloads, koppel met ExpressRoute of VPN tijdens migratie. Public-internet replicatie kan, maar trager.

Question 31

On-prem AD moet synchroniseren met Entra ID

Accepted Answer

1. Kies tussen Entra Connect Sync (server) of Entra Cloud Sync (agent)
2. Voor MKB met 1 forest is Cloud Sync vaak voldoende en simpeler
3. Activeer Password Hash Sync, optioneel Pass-through Authentication of ADFS
4. Plan staged rollout: filter eerst op een OU, dan uitbreiden

Wanneer ons inschakelen: 
Voor complexe forests, multi-domain of dezelfde UPN-suffixen, plan een proof-of-concept.

Question 32

Geen idee of er iets vreemds gebeurt in cloud-account

Accepted Answer

1. AWS: GuardDuty aanzetten in alle regions, ook regions die je niet gebruikt
2. Azure: Defender for Cloud Standard tier op subscriptions met productie
3. GCP: Security Command Center Standard is gratis, Premium meer detectie
4. Stuur findings naar SIEM of een gedeelde inbox, niemand kijkt vanzelf

Wanneer ons inschakelen: 
Bij een actieve detectie (crypto-mining, IAM-anomalie), volg incident-response: containment, eradication, recovery.

Question 33

Onduidelijk of cloud-storage versleuteld is

Accepted Answer

1. S3: 'Default encryption' op SSE-S3 of SSE-KMS, plus block public access
2. EBS: 'EBS encryption by default' aan in account-settings
3. Azure Disk Encryption / Storage Service Encryption: aan via policy
4. GCP encrypt at rest is default, voor extra controle gebruik CMEK

Wanneer ons inschakelen: 
Voor strikte compliance, KMS-keys met CMK (customer-managed) en key-rotation.

Question 34

KMS-keys nooit geroteerd

Accepted Answer

1. Activeer 'Automatic key rotation' op CMK in KMS, jaarlijks
2. Audit welke services welke keys gebruiken via key-policy en CloudTrail
3. Geen handmatige sleutel-export, KMS-keys verlaten KMS niet
4. Voor multi-region, gebruik multi-region keys vanaf de start

Wanneer ons inschakelen: 
Voor HIPAA/PCI-omgevingen, gebruik CloudHSM of dedicated HSMs.

Question 35

S3-bucket met versioning groeit veel sneller dan verwacht

Accepted Answer

1. Activeer een lifecycle-rule: NoncurrentVersionExpiration na bv. 30 dagen
2. Verwijder ook expired delete-markers via dezelfde rule
3. Audit met S3 Storage Lens welke prefixen het bloat veroorzaken
4. Overweeg of versioning echt nodig is voor de use-case, of beter object-lock

Wanneer ons inschakelen: 
Voor backup-use-case, S3 Object Lock met compliance-mode is robuuster dan versioning alleen.

Question 36

Iemand heeft per ongeluk een bucket publiek gezet

Accepted Answer

1. Zet Block Public Access direct aan op bucket en account
2. Check S3 server-access-logs en CloudTrail voor download-activiteit
3. Bepaal wat in de bucket stond, verwerkers en welke betrokkenen geraakt zijn
4. Documenteer tijdlijn voor incident-rapport

Wanneer ons inschakelen: 
Bij persoonsgegevens: AVG-melding bij AP binnen 72 uur als risico voor betrokkenen.

Question 37

Azure-deploy faalt met quota-error

Accepted Answer

1. Open 'Usage + quotas' op de subscription, filter op region en resource-provider
2. Verzoek quota-verhoging via portal, vaak binnen uren goedgekeurd
3. Voor compute, kijk per VM-family, niet alle quotas zijn 1 totaal
4. Plan voor groei, vraag verhoging voor je deploy faalt

Wanneer ons inschakelen: 
Bij sterk afwijkende vraag (GPU, grote families), kan handmatige review duren. Open ticket via support.

Question 38

Welke IaC-tool, Terraform, Pulumi, CDK of OpenTofu

Accepted Answer

1. Terraform: grootste ecosysteem, HCL, license veranderde naar BSL in 2023
2. OpenTofu: open-source fork van Terraform, drop-in compatible voor de meeste cases
3. Pulumi: gewone programmeertalen (TS, Python, Go), fijn voor devs
4. AWS CDK: alleen AWS, TypeScript/Python, genereert CloudFormation

Wanneer ons inschakelen: 
Voor MKB: kies 1 en blijf erbij. Migratie tussen tools is duur.

Question 39

Secrets staan in env-files of CI-variabelen

Accepted Answer

1. Verplaats DB-wachtwoorden, API-keys, certificaten naar de secret-store
2. App haalt secrets via SDK met IAM/RBAC, geen plaintext config
3. Activeer auditing en rotatie waar de service dat aanbiedt
4. CI/CD haalt secrets via OIDC of korte tokens, geen langlevende keys

Wanneer ons inschakelen: 
Voor cross-cloud of multi-tenant, HashiCorp Vault is robuust maar onderhoudswerk.

Question 40

GitHub Actions deploy gebruikt langlevende AWS-keys

Accepted Answer

1. Maak een IAM OIDC-provider voor token.actions.githubusercontent.com
2. Maak een role met trust-policy beperkt tot je org/repo en environment
3. Workflow gebruikt aws-actions/configure-aws-credentials met role-to-assume
4. Verwijder de oude AKIA-keys uit repo-secrets

Wanneer ons inschakelen: 
Azure en GCP hebben vergelijkbare OIDC-setup (Federated Identity Credentials, Workload Identity Federation).

Question 41

AWS prijs voor 1 server voelt veel te hoog

Accepted Answer

1. Steady-state webserver of database: Hetzner Cloud of dedicated levert vaak factor 3 tot 5 voordeel
2. Heb je ECS, Lambda, managed RDS, GuardDuty actief nodig: AWS heeft een reden
3. Combinatie kan: app op Hetzner, S3-equivalent op Cloudflare R2 of Backblaze B2
4. Reken egress mee, AWS-egress is duur, Hetzner heeft inclusief verkeer

Wanneer ons inschakelen: 
Voor compliance-eisen (data-locatie, certificering), check welke regio's en certificeringen je nodig hebt voor je migreert.

Question 42

S3-bill wordt gedomineerd door egress

Accepted Answer

1. R2: geen egress-kosten, opslag iets duurder, ideaal voor publieke assets
2. B2: lage opslag plus lage egress (zeker via partners als Cloudflare)
3. Migratie: rclone of aws-cli kan met endpoint-override sync doen
4. Houd backups dual: 1 originele plus 1 secundaire provider

Wanneer ons inschakelen: 
Voor compliance-data of strikte SLA, AWS S3 blijft de safe-default. Niet alle workloads passen.

Question 43

Latency-gevoelige API moet dichter bij gebruiker

Accepted Answer

1. Match runtime aan code: Workers ondersteunen JS/WASM, Vercel ondersteunt Node-edge
2. Geen lange CPU-jobs, edge-runtimes hebben strikte limits per request
3. State via Workers KV, D1, R2, Durable Objects, of remote DB met connection-pooling
4. Test cold-start en limit-error in productie-load

Wanneer ons inschakelen: 
Hebben de meeste users dezelfde region, edge is overkill. Een regional Lambda of App Service is simpeler.

Question 44

Cloud-region viel uit en wij vielen mee

Accepted Answer

1. Run minimaal Multi-AZ voor productie: 2 of 3 AZs binnen 1 region
2. Database: Multi-AZ standby of Aurora met multi-AZ writers
3. Backup naar een ander region, niet alleen ander AZ
4. Plan en oefen DR-procedure, run-book die niet alleen in iemands hoofd zit

Wanneer ons inschakelen: 
Voor RTO/RPO van minuten, plan active-active multi-region. Reken op 2x baseline kosten plus complexiteit.

Question 45

Azure, AWS of GCP voor een NL-MKB-cloud

Accepted Answer

1. Heb je al M365 en Entra ID, kies Azure: identity-overhead bestaat al, kosten zijn beheersbaar
2. Bouw je een SaaS-product met heterogene workloads, AWS heeft de breedste catalog en marktplaats
3. Doe je veel BigQuery, Vertex AI of Looker, GCP zit dichter op je werk
4. Multi-cloud in MKB is meestal accidenteel, niet strategisch, en kost meer beheer dan het oplevert

Wanneer ons inschakelen: 
Bij subsidie-eisen of compliance-eisen die EU-data-residency expliciet vragen, valideer EU-only beschikbaarheid van de specifieke services, niet alleen de region.

Question 46

Google Workspace naar Microsoft 365 (of andersom) overwegen

Accepted Answer

1. Inventariseer wie waar woont: mailbox-grootte, gedeelde drives, agenda-machtigingen
2. Bouw een test-tenant en migreer eerst één afdeling, niet de hele club tegelijk
3. Gebruik een migratie-tool (BitTitan, MigrationWiz, CloudM) voor mailboxes en bestanden, niet IMAP-export
4. Plan een paralelle periode van twee tot vier weken waarin oude omgeving leesbaar blijft

Wanneer ons inschakelen: 
Bij gedeelde postvakken, distributielijsten of legacy public folders, breng eerst in kaart wie ze echt gebruikt. De helft is vaak weg te schonen voor je migreert.

Question 47

App-hosting bij Hetzner of DigitalOcean voor een klein product

Accepted Answer

1. Hetzner Cloud: prijs-leider, EU-data-centers (Falkenstein, Helsinki), eenvoudige UI
2. DigitalOcean: iets duurder, betere docs en marketplace voor één-klik-deploys
3. Plan backup naar een tweede provider (Backblaze, Wasabi), niet alleen snapshot in dezelfde cloud
4. Zet monitoring en updates expliciet in scope, anders is het je weekend

Wanneer ons inschakelen: 
Bij data-locatie-eisen of strenge SLA: AWS of Azure blijft de safe-default. Niet alle workloads passen op een budget-cloud.

Question 48

S3-compatible storage zoeken voor backup, AWS S3 voelt te duur

Accepted Answer

1. Wasabi: vaste opslag-prijs, geen egress-kosten binnen quota, S3-compatible
2. Backblaze B2: lage opslag, lage egress, scriptbaar via b2-cli of S3-API
3. Cloudflare R2: zero-egress, ideaal als je vanaf Cloudflare ook serveert
4. Test restore voor je gaat: een backup die je niet getest hebt, is geen backup

Wanneer ons inschakelen: 
Bij compliance- of contract-eisen die expliciet AWS of Azure vragen: kies een EU-region binnen die provider, mix met budget-storage werkt dan niet.

Question 49

Microsoft-partner adviseert Azure landing zone, klinkt als overkill

Accepted Answer

1. Begin met één production en één non-production subscription, niet twaalf
2. Forceer MFA, named admin accounts, en kosten-alerts vanaf dag een, dat is wel must
3. Skip Sentinel en Defender for Cloud-Plan-2 tot je daadwerkelijk een SOC of MDR hebt
4. Voeg Azure Policy alleen toe waar je een echte regel hebt, niet "best practice" uit een PDF

Wanneer ons inschakelen: 
Bij regulated industries (zorg, financieel) of toekomstige NIS2-rol: dan loont een complete landing zone wel, maar laat het ontwerp expliciet aansluiten op de wet, niet op een sjabloon.

Question 50

Klant of accountant vraagt schriftelijk om EU-data-residency

Accepted Answer

1. Selecteer je tenant of subscription bij creatie op een EU-region (West Europe in NL, Frankfurt voor AWS, europe-west4 voor GCP)
2. Lees de DPA van de cloud, daarin staat hoe ondersteunend personeel buiten de EU mogelijk inzage heeft
3. Documenteer voor je verwerkersregister waar de data staat en welke sub-verwerkers er zijn
4. Schakel diagnostische data-sharing buiten de EU expliciet uit waar dat een toggle is

Wanneer ons inschakelen: 
Bij eisen zoals SecNumCloud of "EU-only sovereign cloud": dan praat je over OVHcloud, IONOS of een specifiek Microsoft Cloud for Sovereignty-aanbod, niet de standaard region.

Question 51

We ontdekken dat ons AWS-root account geen MFA heeft

Accepted Answer

1. Stop met andere taken. Eerst MFA aan op root: log in als root, ga naar IAM > Security credentials > Multi-factor authentication, registreer een hardware-token of TOTP-app op een telefoon die niet van die ene admin is.
2. Bewaar de MFA recovery codes in een wachtwoordkluis met meerdere personen toegang. Een persoon met root-MFA en uitsluitend op hun eigen telefoon: dat is je volgende incident.
3. Roteer het root-wachtwoord direct na het aanzetten van MFA. Was het ergens in een wiki of mail? Aannemen dat het al gelekt is, niet hopen dat het meeviel.
4. Activeer CloudTrail in alle regio's en controleer de laatste dertig dagen op login-events vanaf root. Onbekende IP's of regio's: dan ben je ingebroken en is dit een gegevenslek-vraag, geen IT-vraag meer.
5. Stel een policy in dat root vanaf nu niet voor dagelijks werk gebruikt wordt. Maak admin-users in IAM Identity Center, beleg root in een kluis, gebruik hem alleen voor wat alleen root kan (account sluiten, support-plan wijzigen).

Wanneer ons inschakelen: 
CloudTrail toont onbekende sessies, of er staan resources die jullie niet kennen (cryptominer-instances in obscure regio's): meld bij AWS Support, betalingsstop op de creditcard via je bank, en bel ons. Dit gaat verder dan deze ticket.

Question 52

GCP-project per ongeluk verwijderd, of we willen iets uit een verwijderd project halen

Accepted Answer

1. Check de status: gcloud projects list --filter='lifecycleState:DELETE_REQUESTED' of in de console Resource Manager > Manage Resources > filter 'Pending deletion'. Staat het er nog: tijd genoeg.
2. Herstel: in de console klik op het project en kies Restore Project, of cli: gcloud projects undelete PROJECT_ID. De resources binnen het project moeten dan zelf weer ingeschakeld worden, sommige services hebben een korte heractivatie.
3. Verlopen periode: data is weg en niet terug te halen. Voor toekomstige preventie: zet billing-account-policies en organisatie-policy zo dat alleen specifieke rollen projecten mogen verwijderen.
4. Voor productie-projecten: gebruik organisatie-niveau Project Lien (gcloud resource-manager liens create). Een lien blokkeert verwijdering totdat hij expliciet weggehaald wordt, een tweede stap die ongelukken voorkomt.
5. Documenteer: welke projecten zijn 'mag dood' en welke 'absoluut niet'. Naamgeving als '-prod' of '-test' suffix helpt en is gratis.

Wanneer ons inschakelen: 
Project verwijderd buiten de 30-dagen window met productie-data erin: dat is geen recovery-vraag meer maar een impact-assessment. Wij helpen om te bepalen of er backups (BigQuery exports, Cloud Storage replicaties) ergens anders staan.

Question 53

Cloud-rekening loopt op door data-transfer kosten waarvan we niet wisten

Accepted Answer

1. Open Cost Explorer (AWS), Cost Management (Azure) of Billing > Reports (GCP) en groepeer op service-categorie. Zoek naar 'Data Transfer', 'Bandwidth' of 'Network'. Boven de 10-15% van het totaal: het loont om te kijken.
2. Bepaal de stromen: cross-region replicaties, NAT-gateway naar internet, gebruikers die buiten de region downloaden. Vooral inter-region replicatie is een rustige maar continue kostenpost.
3. Voor S3/GCS: zet niet alle buckets op cross-region replication 'voor de zekerheid'. Voor backups is regionaal vaak voldoende; cross-region alleen als de RTO/RPO dat vereist.
4. Voor uitgaand verkeer naar gebruikers: zet een CDN ervoor (CloudFront, Cloud CDN, Azure Front Door). De origin-egress wordt dan klein, en CDN-egress is goedkoper. Voor video of grote downloads is dit eigenlijk altijd zinvol.
5. Stel een budget alert in op de data-transfer-categorie specifiek, niet alleen op totaal. Een uitschieter wil je in dagen merken, niet aan het eind van de maand.

Wanneer ons inschakelen: 
Eenmalige uitschieter onverklaarbaar groot (bijvoorbeeld een tienvoud), of structurele groei zonder gebruikersgroei: dat hint op een misconfiguratie of zelfs ongewenste activiteit. Wij draaien graag een korte audit.

Question 54

Grafana Cloud of zelf Prometheus en Grafana draaien?

Accepted Answer

1. Tel je metrics-cardinality, niet alleen aantal series
2. Onder een paar miljoen actieve series past Grafana Cloud free of pro
3. Self-host pas overwegen als data-residency of audit eisen het verplichten
4. Reken bij self-host iemand mee die long-term storage en upgrades doet

Wanneer ons inschakelen: 
Voor multi-tenant-setup of strenge data-residency-eisen, vraag offerte bij beide opties.

Question 55

We willen IAM least-privilege maar elke policy eindigt als AdministratorAccess

Accepted Answer

1. Inventariseer de drie tot vijf werkpaden die echt voorkomen: developer, deploy-bot, read-only voor finance, ops, en eventueel een data-rol.
2. Start per pad met een AWS-managed policy zoals PowerUserAccess of ReadOnlyAccess, niet met een eigen policy from scratch.
3. Zet CloudTrail aan, draai twee weken mee en kijk welke acties die rollen feitelijk doen. Wat niet voorkomt, knip je weg in een eigen policy.
4. Zet een service-control-policy in AWS Organizations als vangrail boven alles, zodat zelfs Administrator geen regio's of services kan gebruiken die jullie niet willen.
5. Review elk kwartaal met IAM Access Analyzer. Die meldt ongebruikte rechten en is een goede trigger om verder af te knippen.

Wanneer ons inschakelen: 
Werken jullie met productie-data van klanten of zit je in een gereguleerde sector, dan is een eenmalige audit op de policies door iemand met IAM-routine de moeite waard.

Question 56

Iemand heeft port 22 op 0.0.0.0/0 in een security-group gezet

Accepted Answer

1. Sluit per direct de regel: vervang 0.0.0.0/0 door je kantoor-IP, of beter, verwijder de regel helemaal.
2. Voor SSH naar private instances gebruik je AWS Systems Manager Session Manager of Azure Bastion of GCP IAP. Geen publiek SSH meer nodig.
3. Zet AWS Config of Defender for Cloud of Security Command Center aan met een regel die port 22 of 3389 op 0.0.0.0/0 als non-compliant markeert.
4. Review alle bestaande security-groups en NSG's. CloudTrail of Activity Log laat zien wie de regel toevoegde, dat is meestal goed om uit te zoeken.
5. Leg vast in een SCP of Azure Policy dat publieke SSH/RDP-regels worden geweigerd, niet alleen gemarkeerd.

Wanneer ons inschakelen: 
Stond de instance al weken open en heeft hij toegang tot productie-data, behandel het als incident en haal er iemand bij die forensics doet.

Question 57

Eén VPC voor alles of een VPC per app, wat is verstandig?

Accepted Answer

1. Begin met één VPC per omgeving en /16 CIDR die ruim genoeg is om in 5 jaar niet vol te lopen, bijvoorbeeld 10.0.0.0/16 voor prod en 10.1.0.0/16 voor staging.
2. Splits per AZ in een public en private subnet, en zet alle workloads in private. Public is alleen voor load-balancers en NAT-gateways.
3. Gebruik aparte subnets of security-groups per app, niet aparte VPC's. Dat houdt routing simpel en NAT-kosten laag.
4. Een aparte VPC pas overwegen als de app een ander security-profiel heeft (bijvoorbeeld klant-tenant-isolatie, betalingsverkeer, of compliance-scope).
5. Documenteer je CIDR-plan in een tabel die je deelt, anders krijg je collisions zodra iemand on-prem of een andere cloud wil koppelen.

Wanneer ons inschakelen: 
Wil je multi-tenant SaaS bouwen waar elke klant netwerk-isolatie nodig heeft, dan is het ontwerp wezenlijk anders. Even meekijken loont voordat je vastloopt.

Question 58

We hebben drie VPC's en peering wordt onhoudbaar

Accepted Answer

1. Tel je peerings: bij 4 VPC's heb je 6 peerings nodig, bij 5 al 10. Zit je daar boven, dan begint transit-gateway zinnig te worden.
2. Zet één transit-gateway per regio op en attach elke VPC. Routing tables op de gateway bepalen wie wie mag bereiken.
3. Reken vooraf de kosten: transit-gateway-attachment kost per uur per VPC plus per GB data. Voor lage-volume-tussenverkeer kan peering goedkoper blijven.
4. Voor cross-region of cross-account: transit-gateway peering of een Cloud-WAN. Niet meer met handmatige routes-per-VPC werken.
5. Bij Azure heet dit Virtual WAN, bij GCP gebruik je Network Connectivity Center. Patroon is hetzelfde, naamgeving anders.

Wanneer ons inschakelen: 
Hebben jullie meer dan tien VPC's of multi-account met cross-region traffic, dan is een netwerk-architect die dit vaker doet de moeite waard.

Question 59

Eén AWS-account voor alles wordt te druk

Accepted Answer

1. Zet AWS Organizations aan in het bestaande account, dat wordt de management-account. Doe daar niets meer in behalve org-beheer en billing.
2. Maak minimaal: log-archive (alle CloudTrail-logs), security (GuardDuty, IAM Access Analyzer aggregator), prod, en non-prod accounts.
3. Zet AWS Identity Center (SSO) aan. Mensen krijgen permission-sets die ze in elk account kunnen gebruiken, niet aparte IAM-users per account.
4. Leg SCP's aan op de OU's: bijvoorbeeld geen root-actions, geen non-EU regio's, geen Security-disable.
5. Zet Control Tower aan als je dit voor het eerst doet, dat doet de grondslag (CloudTrail, Config, log-archive) voor je.

Wanneer ons inschakelen: 
Voor 5+ accounts of als regulators meekijken, is een Control-Tower-baseline plus een korte governance-sessie meestal aan te raden.

Question 60

We willen alert als de cloud-rekening boven X EUR komt

Accepted Answer

1. Stel een AWS Budget of Azure Cost Management Budget of GCP Budget in op je verwachte maandbedrag plus 20 procent. Bij overschrijding e-mail naar finance en CTO.
2. Voeg een tweede budget toe voor forecast: actie als de voorspelling boven plafond uitkomt halverwege de maand. Dat triggert eerder.
3. Maak een derde alert per dag: bijvoorbeeld bij dagelijkse uitgave boven 1/25 van je maandbudget. Dat vangt runaway-resources zoals een vergeten GPU-instance.
4. Stuur alerts naar Slack of Teams via SNS+Lambda of Logic App, niet alleen e-mail. Mensen lezen e-mail vaak te laat.
5. Controleer elk kwartaal of het bedrag nog klopt. Een verouderd budget triggert false-positives en wordt dan genegeerd.

Wanneer ons inschakelen: 
Schiet de rekening al weken omhoog zonder dat duidelijk is waarom, dan is een uurtje cost-explorer-werk samen meestal genoeg om de bron te vinden.

Question 61

Savings Plan of Reserved Instance, wat past bij ons compute-gebruik?

Accepted Answer

1. Kijk in Cost Explorer onder Recommendations naar je laatste 60 dagen aan compute-gebruik. AWS doet zelf een voorstel.
2. Voor wisselende workloads: Compute Savings Plan, 1 jaar, no upfront. Geeft korting zonder lock-in op type of regio.
3. Voor zeer vast gebruik (database, fixed app-server) en weet je dat die instance er volgend jaar nog draait, een Standard RI 1 of 3 jaar.
4. Dek nooit 100 procent van je gebruik. Mik op 70-80 procent gedekt door commitments, de rest on-demand voor flexibiliteit.
5. Op Azure heet dit Reservations of Savings Plans, op GCP CUDs (Committed Use Discounts). Patroon is gelijk.

Wanneer ons inschakelen: 
Voor commitments boven een paar duizend euro per maand is een korte FinOps-review met iemand die dit dagelijks doet meestal de inschrijving waard.

Question 62

Onze EC2- of VM-rekening voelt te hoog voor wat de servers doen

Accepted Answer

1. Open AWS Trusted Advisor (Business Support of hoger), Azure Advisor, of GCP Recommender. Die geven concrete suggesties per instance.
2. Filter op instances met < 20 procent CPU over 14 dagen en < 50 procent geheugen. Dat zijn kandidaten voor één maat kleiner.
3. Test de migratie eerst in staging. Sommige workloads tikken af en toe piekgebruik aan dat in een gemiddelde wegvalt.
4. Voor compute die echt idle is buiten kantooruren: schedule stop/start via Instance Scheduler of Azure Automation. Bespaart een groot deel van de uurkosten.
5. Plan rightsizing als kwartaalwerk, niet eenmalig. Workloads veranderen, recommendations veranderen mee.

Wanneer ons inschakelen: 
Praat je over honderden instances, dan loont een tool zoals Spot.io of CloudHealth. Voor onder de 50 instances is handmatig met Advisor genoeg.

Question 63

Hoe voorkomen we dat iemand per ongeluk een S3-bucket publiek maakt?

Accepted Answer

1. Schakel S3 Block Public Access op account-niveau in, met alle vier de instellingen aan. Dat overrulet elke bucket-policy of ACL die anders zegt.
2. Run AWS Config-regel s3-bucket-public-read-prohibited en s3-bucket-public-write-prohibited als continue check.
3. Schakel S3 Object Ownership op Bucket Owner Enforced. Dat zet ACL's helemaal uit, zodat alleen IAM-policy of bucket-policy toegang geeft.
4. Voor buckets die wel publiek moeten zijn (statische website, downloads), gebruik CloudFront ervoor met Origin Access Control. Bucket blijft privé.
5. Op Azure is dit Storage Account Public Access disabled, op GCP is het Public Access Prevention. Zet beide aan op org-niveau.

Wanneer ons inschakelen: 
Heb je honderden buckets en weet je niet wat erin zit, dan is een Macie-scan plus een korte review zinnig voordat je hard gaat dichtzetten.

Question 64

Moeten we KMS-keys roteren en zo ja hoe?

Accepted Answer

1. Voor symmetric customer-managed keys: zet Automatic Key Rotation aan. AWS maakt elk jaar nieuw key-material, oude data blijft leesbaar via key-versies.
2. Asymmetric keys roteren niet automatisch. Daar maak je een nieuwe key, gebruik je beide aliassen, en migreert software stapsgewijs.
3. Audit met CloudTrail welke key wat versleutelt. Een KMS-key zonder gebruik is meestal te schedulen voor deletion (7-30 dagen wachttijd).
4. Op Azure heet dit Key Vault key rotation policy, op GCP Cloud KMS rotation period. Patroon hetzelfde.
5. Documenteer welke key welke data versleutelt en wie key-admin is. Bij een audit is dat de eerste vraag.

Wanneer ons inschakelen: 
Werken jullie met PCI-data of patiëntgegevens en is rotatie-frequentie contractueel vastgelegd, dan is een korte review met je security-officer de moeite waard.

Cloud-platforms