Question 1

Everyone logs in with the AWS root account

Accepted Answer

1. Add hardware MFA to root and store the key physically
2. Remove root access keys, no legit use case
3. Create an IAM user or better an Identity Center account per person
4. Document where root password and MFA device live, two people know

When to bring us in: 
If the root password is lost, AWS support can help via account verification. Plan multiple days.

Question 2

Every developer has AdministratorAccess

Accepted Answer

1. Inventory who truly needs admin, usually just 1 or 2 people
2. Give developers PowerUserAccess or a custom policy without IAM rights
3. Enable IAM Access Analyzer to spot unused permissions
4. Review each quarter and trim rights nobody uses

When to bring us in: 
For compliance (ISO, SOC2), least-privilege is baseline. Allocate time.

Question 3

Everyone has individual IAM users with their own password

Accepted Answer

1. Enable IAM Identity Center on the org account
2. Connect to Entra ID, Google Workspace or the built-in directory
3. Create permission-sets per role (Developer, ReadOnly, Billing) and assign per account
4. Remove old IAM users once everyone is on SSO

When to bring us in: 
If you run multiple AWS accounts, AWS Organizations plus Identity Center is practically mandatory.

Question 4

Not all IAM users have MFA

Accepted Answer

1. Write a policy denying everything until MFA is active, except self-service MFA setup
2. Attach to a group and put all users in it
3. Announce 1 week ahead with authenticator-app instructions
4. Verify via IAM credential report that everyone has MFA

When to bring us in: 
SMS MFA is weak. Use TOTP or preferably a security key.

Question 5

App uses personal access keys in production

Accepted Answer

1. Create an IAM role with only the rights the app needs
2. Attach the role to the EC2 instance, Lambda or ECS task definition
3. Remove access keys from env vars and git history
4. Rotate any key that ever sat in code, assume it leaked

When to bring us in: 
If a key leaked publicly, enable GuardDuty immediately and review the last 90 days of CloudTrail.

Question 6

Docs say Azure AD, portal says Entra ID, which is which

Accepted Answer

1. Read 'Azure AD' in old docs as 'Entra ID' unless context says otherwise
2. AzureAD and MSOnline PowerShell modules are deprecated, use Microsoft.Graph
3. Entra ID Free comes with every M365 tenant, P1/P2 add features
4. Conditional Access requires Entra ID P1; Identity Protection requires P2

When to bring us in: 
For B2B/B2C scenarios, Entra External ID is the new product. Plan a separate review.

Question 7

Everyone is Owner on the Azure subscription

Accepted Answer

1. Grant Owner only at subscription level to 1 or 2 people
2. Developers get Contributor on the resource group of their project
3. Reader for people who only need monitoring
4. User Access Administrator only to someone who delegates roles

When to bring us in: 
For growing orgs, use management groups and Azure Policy for consistent assignment.

Question 8

GCP project where everyone is Editor

Accepted Answer

1. Replace Editor with specific roles like Compute Admin or Storage Object Viewer
2. Use folders to split dev, test, prod with their own IAM
3. Enable Organization Policy to block external accounts where needed
4. Audit via Policy Analyzer which principals actually have which rights

When to bring us in: 
Custom roles work but maintenance is real. Try predefined roles first.

Question 9

GCP service-account JSON key sits in the repo

Accepted Answer

1. Rotate or disable the leaked key in IAM right away
2. For GKE/Cloud Run, use Workload Identity so no key is needed
3. For external CI/CD, use Workload Identity Federation with OIDC
4. Clean git history with git-filter-repo or BFG, force-push

When to bring us in: 
If the key was public, check billing and audit logs for abuse. Crypto-mining is the usual first sign.

Question 10

AWS keys accidentally pushed to GitHub

Accepted Answer

1. Disable the keys in IAM right away, don't just 'remove commit'
2. Generate new keys and update the app or CI
3. Enable CloudTrail review and GuardDuty to spot abuse
4. Add pre-commit hooks or Gitleaks/TruffleHog to prevent repeats

When to bring us in: 
If unauthorized resources appeared (especially GPU instances), open an AWS support ticket. Abuse can be refunded.

Question 11

No clue whether t3, m6i or c7g for this workload

Accepted Answer

1. Webserver with variable load: t-family with unlimited mode
2. Steady CPU load (API, batch): m-family
3. CPU heavy (build, encoding): c-family
4. ARM variants (Graviton, t4g/c7g/m7g) are 20 percent cheaper if your software runs on ARM

When to bring us in: 
Unsure: Compute Optimizer recommends based on actual usage.

Question 12

Cloud bill creeps up from batch jobs

Accepted Answer

1. Fits batch jobs, CI runners, rendering, training, not stateful production
2. Build retries and checkpoints, instances can vanish within 2 minutes
3. Use Spot Fleet or a mix of on-demand plus spot for balance
4. Don't assume one instance type is always available, mix

When to bring us in: 
For production traffic, on-demand or Reserved stay safer.

Question 13

On-demand pricing on 24/7 workloads feels way too high

Accepted Answer

1. Inventory what really runs 24/7 over the last 3 months
2. Start with 1-year commit on the baseline, not the peak
3. Compute Savings Plans (AWS) are more flexible than EC2 Reserved
4. Review utilization monthly, underuse means waste

When to bring us in: 
For larger spend, ask for enterprise discount or EDP through your AWS/Azure account manager.

Question 14

Site falls over at peak or we pay for idle overnight

Accepted Answer

1. Define min, max, desired and a metric like CPU or request-count
2. Actually test scale-out, not just on paper
3. Plan scale-in carefully, abrupt removal hurts cache hits and breaks long requests
4. Use launch templates with one AMI/image plus bootstrap

When to bring us in: 
Stateful apps (sessions, local files) need to go stateless first via Redis, S3 or DB.

Question 15

Lambda is slow on the first request, fast after

Accepted Answer

1. Shrink deployment package, fewer deps = faster
2. Avoid heavy init code, lazy-load what you can
3. For latency-critical: Provisioned Concurrency, but it costs
4. Consider ARM (Graviton2) runtime, often faster and cheaper

When to bring us in: 
If you need sub-100ms, Lambda may simply be wrong, look at App Runner or ECS Fargate.

Question 16

S3 bucket grows and nobody cleans it

Accepted Answer

1. Identify which prefix holds old data (logs, backups, exports)
2. Add a rule: after 30 days to Standard-IA, after 90 to Glacier
3. For logs you genuinely don't need, expire after N days
4. Test on one prefix first, not the whole bucket at once

When to bring us in: 
For compliance data, verify retention requirements before adding delete rules.

Question 17

Azure Blob bill is climbing fast

Accepted Answer

1. Hot for daily-read data
2. Cool for monthly-read, cheaper storage costlier reads
3. Cold/Archive for backups and compliance, hours to rehydrate
4. Lifecycle management policy automates moves by last-modified

When to bring us in: 
For analytics on large sets, ADLS Gen2 on Hot is often cheaper than many small reads on Cool.

Question 18

RDS backup strategy is unclear

Accepted Answer

1. Set automated backups to at least 7 days, 30 for production
2. Take periodic manual snapshots for longer retention
3. Test a restore at least quarterly in a test account
4. Read replicas for read-heavy or cross-region DR, not as backup substitute

When to bring us in: 
For strict RPO/RTO, look at Multi-AZ plus cross-region replicas, fits in the DR plan.

Question 19

EBS volumes and snapshots, how often and how long

Accepted Answer

1. Use Data Lifecycle Manager (DLM) or AWS Backup for scheduling
2. Daily snapshots with 7-day retention is a sane default
3. Production DBs: hourly during business hours, daily overnight
4. Delete unused volumes (status: available), they also cost

When to bring us in: 
For cross-region DR, copy snapshots to another region and encrypt with a separate KMS key.

Question 20

Setting up a new VPC, which CIDR

Accepted Answer

1. Avoid 10.0.0.0/16 as default, it collides with everything
2. Pick a unique 10.x.x.x/16 block per VPC
3. Leave room to grow, /16 is plenty, /20 can pinch
4. Document which subnet does what (public, private, db)

When to bring us in: 
For multi-cloud or on-prem links, plan IP allocation centrally in a sheet or IPAM.

Question 21

What's the difference between public and private subnet

Accepted Answer

1. Public: load balancer, NAT gateway, bastion (if you still use one)
2. Private: app servers, databases, anything without direct internet need
3. Outbound from private goes via NAT gateway in the public subnet
4. Multi-AZ: at least 2 subnets per type, one per AZ

When to bring us in: 
Want to skip NAT cost, use VPC endpoints (gateway for S3/DynamoDB, interface for other services).

Question 22

NAT gateway is a large line on the AWS bill

Accepted Answer

1. For S3 and DynamoDB, use gateway endpoints, free and bypass NAT
2. For other AWS services, interface endpoints (PrivateLink) also bypass NAT
3. Dev environments with little traffic can share one NAT across AZs (acceptable risk)
4. Audit via VPC Flow Logs which top-talkers go through NAT

When to bring us in: 
At hundreds of GB per day, consider a dedicated NAT instance or egress architecture.

Question 23

Security group or NACL, when which

Accepted Answer

1. Default workflow: everything via security groups, NACLs as extra layer only
2. NACLs help to block entire IP ranges at subnet level
3. Remember: NACL is stateless, allow inbound and outbound separately
4. Don't test changes in production, NACL deny is hard to debug

When to bring us in: 
For strict segmentation, look at AWS Network Firewall or Security Groups for Pods (EKS).

Question 24

Office needs access to private cloud resources

Accepted Answer

1. Cloud side: VPN gateway plus customer gateway with your public IP
2. Office side: IPsec config in firewall (Fortigate, Sophos, Mikrotik)
3. Pre-shared keys via password vault, never email
4. Test failover for a tunnel-down case

When to bring us in: 
For multiple offices, AWS Transit Gateway or Azure Virtual WAN. Direct Connect/ExpressRoute only for truly high bandwidth.

Question 25

No idea where the AWS bill comes from

Accepted Answer

1. Enable Cost Explorer in the billing console (free)
2. Filter by service, region and linked account to see what dominates
3. Enable cost allocation tags to split per project or client
4. Create a weekly anomaly-detection rule that emails on deviation

When to bring us in: 
For deeper analysis, export CUR (Cost and Usage Report) to S3 and query with Athena.

Question 26

Cloud bill surprised you this month

Accepted Answer

1. AWS Budgets: monthly budget plus alerts at 50, 80 and 100 percent
2. Azure Cost Management: budget alerts per subscription and resource group
3. GCP Billing: budget alerts per project, hook to Pub/Sub for automation
4. Send alerts to a shared inbox or Slack, not one person

When to bring us in: 
For a runaway resource (mining, leaked key), worth considering a kill-switch via Lambda or Functions.

Question 27

Don't know which team incurs which cloud cost

Accepted Answer

1. Define at minimum: Environment, Team, Project, CostCenter
2. Activate them as cost-allocation tags in the billing console
3. Enforce via SCP/Azure Policy/Org Policy at creation time
4. Run a monthly untagged-resources report and hold teams accountable

When to bring us in: 
At scale, use IaC (Terraform) for consistent tagging, manual will lag.

Question 28

You suspect lots of resources do nothing yet cost

Accepted Answer

1. Identify EBS volumes in 'available' state (unattached), they cost
2. Find RDS with 0 connections in the last 7 days
3. Unattached old EIPs cost per hour
4. Test/dev that doesn't stop after hours, schedule via Lambda or Automation

When to bring us in: 
Tools like Cost Optimizer, Trusted Advisor (Business Support) or third parties give dashboards.

Question 29

Azure bill rises without clear reason

Accepted Answer

1. Open Cost Management in the portal, filter on subscription and time
2. Group by resource type to see if compute, storage or networking dominates
3. Enable Advisor recommendations, often quick wins
4. Set budgets per RG plus action groups for email or webhook

When to bring us in: 
Enterprise EA/MCA, export to storage and analyze in Power BI or Fabric.

Question 30

On-prem server needs to move to cloud, lift-and-shift

Accepted Answer

1. Inventory with Azure Migrate appliance: CPU, RAM, disk, dependencies
2. Right-size based on actual usage, not purchase spec
3. Replicate via Azure Migrate Server Migration or AWS MGN
4. Test cutover in dev first, plan a maintenance window for prod

When to bring us in: 
For sensitive workloads, pair with ExpressRoute or VPN during migration. Public-internet replication works but is slower.

Question 31

On-prem AD must sync to Entra ID

Accepted Answer

1. Pick Entra Connect Sync (server) or Entra Cloud Sync (agent)
2. For SMB with one forest, Cloud Sync is usually enough and simpler
3. Enable Password Hash Sync, optionally Pass-through Auth or ADFS
4. Plan staged rollout: filter first by OU, then expand

When to bring us in: 
For complex forests, multi-domain or shared UPN suffixes, plan a PoC.

Question 32

No clue if something odd is happening in the cloud account

Accepted Answer

1. AWS: enable GuardDuty in all regions, even unused ones
2. Azure: Defender for Cloud Standard tier on production subscriptions
3. GCP: Security Command Center Standard is free, Premium adds detections
4. Forward findings to SIEM or a shared inbox, nobody watches by default

When to bring us in: 
On active detection (mining, IAM anomaly), follow IR: containment, eradication, recovery.

Question 33

Unclear if cloud storage is encrypted

Accepted Answer

1. S3: 'Default encryption' to SSE-S3 or SSE-KMS, plus block public access
2. EBS: 'EBS encryption by default' on in account settings
3. Azure Disk Encryption / Storage Service Encryption: on via policy
4. GCP encrypt at rest is default, for extra control use CMEK

When to bring us in: 
For strict compliance, KMS with CMK (customer-managed) and key rotation.

Question 34

KMS keys never rotated

Accepted Answer

1. Enable 'Automatic key rotation' on CMK in KMS, yearly
2. Audit which services use which keys via key policy and CloudTrail
3. No manual key export, KMS keys never leave KMS
4. For multi-region, use multi-region keys from the start

When to bring us in: 
For HIPAA/PCI, use CloudHSM or dedicated HSMs.

Question 35

Versioned S3 bucket grows much faster than expected

Accepted Answer

1. Add a lifecycle rule: NoncurrentVersionExpiration after, e.g., 30 days
2. Also expire delete markers in the same rule
3. Audit with S3 Storage Lens which prefixes cause the bloat
4. Consider whether versioning is truly needed, or use Object Lock

When to bring us in: 
For backup use cases, S3 Object Lock with compliance mode is sturdier than versioning alone.

Question 36

Someone accidentally made a bucket public

Accepted Answer

1. Enable Block Public Access on the bucket and account immediately
2. Check S3 access logs and CloudTrail for download activity
3. Determine what was in the bucket, processors, and whose data is affected
4. Document the timeline for the incident report

When to bring us in: 
For personal data: GDPR notification to DPA within 72 hours if risk to data subjects.

Question 37

Azure deploy fails with a quota error

Accepted Answer

1. Open 'Usage + quotas' on the subscription, filter by region and provider
2. Request a quota increase via the portal, often approved in hours
3. For compute, check per VM family, not all quotas are one total
4. Plan ahead, request increases before deploy fails

When to bring us in: 
For unusual demand (GPU, big families) manual review can take longer. Open a support ticket.

Question 38

Which IaC, Terraform, Pulumi, CDK or OpenTofu

Accepted Answer

1. Terraform: biggest ecosystem, HCL, license switched to BSL in 2023
2. OpenTofu: OSS fork of Terraform, drop-in compatible for most cases
3. Pulumi: real programming languages (TS, Python, Go), nice for devs
4. AWS CDK: AWS only, TypeScript/Python, emits CloudFormation

When to bring us in: 
For SMB: pick one and stick. Migration between tools is expensive.

Question 39

Secrets sit in env files or CI variables

Accepted Answer

1. Move DB passwords, API keys, certs into the secret store
2. App fetches via SDK with IAM/RBAC, no plaintext config
3. Enable auditing and rotation where the service supports it
4. CI/CD pulls secrets via OIDC or short-lived tokens, no long-lived keys

When to bring us in: 
Cross-cloud or multi-tenant, HashiCorp Vault is sturdy but adds ops work.

Question 40

GitHub Actions deploy uses long-lived AWS keys

Accepted Answer

1. Create an IAM OIDC provider for token.actions.githubusercontent.com
2. Create a role with trust policy scoped to your org/repo and environment
3. Workflow uses aws-actions/configure-aws-credentials with role-to-assume
4. Delete the old AKIA keys from repo secrets

When to bring us in: 
Azure and GCP have similar OIDC setups (Federated Identity Credentials, Workload Identity Federation).

Question 41

AWS price for one server feels way too high

Accepted Answer

1. Steady-state webserver or DB: Hetzner Cloud or dedicated often 3 to 5x cheaper
2. If you actively use ECS, Lambda, managed RDS, GuardDuty: AWS has a reason
3. A combo works: app on Hetzner, S3-equivalent on Cloudflare R2 or Backblaze B2
4. Count egress, AWS egress is expensive, Hetzner includes traffic

When to bring us in: 
For compliance (data location, certifications), check which regions and certs you need before migrating.

Question 42

S3 bill is dominated by egress

Accepted Answer

1. R2: zero egress cost, storage slightly higher, great for public assets
2. B2: low storage plus low egress (especially via Cloudflare partner)
3. Migrate via rclone or aws-cli with endpoint override
4. Keep backups dual: one primary plus one secondary provider

When to bring us in: 
For compliance data or strict SLA, AWS S3 stays the safe default. Not all workloads fit.

Question 43

Latency-sensitive API needs to sit closer to the user

Accepted Answer

1. Match runtime to code: Workers support JS/WASM, Vercel runs Node-edge
2. No long CPU jobs, edge runtimes have strict per-request limits
3. State via Workers KV, D1, R2, Durable Objects, or remote DB with connection pooling
4. Test cold-start and limit errors under production load

When to bring us in: 
If most users share a region, edge is overkill. A regional Lambda or App Service is simpler.

Question 44

Cloud region went down and so did we

Accepted Answer

1. Run at least Multi-AZ in production: 2 or 3 AZs within one region
2. Database: Multi-AZ standby or Aurora with multi-AZ writers
3. Backup to a different region, not just a different AZ
4. Plan and rehearse DR, a runbook that doesn't live in someone's head

When to bring us in: 
For RTO/RPO in minutes, plan active-active multi-region. Expect 2x baseline cost plus complexity.

Question 45

Azure, AWS or GCP for an NL SMB cloud

Accepted Answer

1. Already on M365 and Entra ID, pick Azure: identity overhead exists, costs are manageable
2. Building a SaaS product with heterogeneous workloads, AWS has the broadest catalog and marketplace
3. Heavy use of BigQuery, Vertex AI or Looker, GCP sits closer to your work
4. Multi-cloud in SMB is usually accidental, not strategic, and costs more admin than it returns

When to bring us in: 
For subsidies or compliance demanding explicit EU data residency, validate EU-only availability for the specific services, not just the region.

Question 46

Considering a move from Google Workspace to Microsoft 365 (or back)

Accepted Answer

1. Map where everyone sits: mailbox size, shared drives, calendar delegations
2. Build a test tenant and migrate one department first, not the whole org at once
3. Use a migration tool (BitTitan, MigrationWiz, CloudM) for mailboxes and files, not IMAP export
4. Plan a two to four week parallel period where the old tenant stays readable

When to bring us in: 
For shared mailboxes, distribution lists, or legacy public folders, map who actually uses them first. Half can usually be cleaned out before migrating.

Question 47

App hosting on Hetzner or DigitalOcean for a small product

Accepted Answer

1. Hetzner Cloud: price leader, EU data centers (Falkenstein, Helsinki), simple UI
2. DigitalOcean: a bit more expensive, better docs and a marketplace for one-click deploys
3. Plan backup to a second provider (Backblaze, Wasabi), not just a snapshot in the same cloud
4. Put monitoring and updates explicitly in scope, otherwise it eats your weekend

When to bring us in: 
For data residency or strict SLA, AWS or Azure stays the safe default. Not every workload fits a budget cloud.

Question 48

Looking for S3-compatible storage for backup, AWS S3 feels too expensive

Accepted Answer

1. Wasabi: flat storage pricing, no egress within quota, S3-compatible
2. Backblaze B2: low storage, low egress, scriptable via b2-cli or S3 API
3. Cloudflare R2: zero egress, ideal if you serve from Cloudflare anyway
4. Test the restore before you trust it: a backup you have not tested is not a backup

When to bring us in: 
For compliance or contracts demanding AWS or Azure explicitly, pick an EU region inside that provider. Mixing in budget storage is not always allowed.

Question 49

Microsoft partner pushes an Azure landing zone, sounds like overkill

Accepted Answer

1. Start with one production and one non-production subscription, not twelve
2. Force MFA, named admin accounts, and cost alerts from day one, that part is non-negotiable
3. Skip Sentinel and Defender for Cloud Plan 2 until you actually have a SOC or MDR
4. Add Azure Policy only where you have a real rule, not "best practice" off a PDF

When to bring us in: 
Regulated industries (healthcare, finance) or a future NIS2 role: a full landing zone earns its keep, but tie the design to the law, not to a template.

Question 50

Customer or accountant asks in writing for EU data residency

Accepted Answer

1. Pick the tenant or subscription region at creation in the EU (West Europe for Azure in NL, eu-central-1 Frankfurt or eu-west-1 Ireland for AWS, europe-west4 for GCP)
2. Read the cloud DPA, which spells out how support staff outside the EU may access data
3. Document for your processing register where the data sits and which sub-processors are involved
4. Turn off diagnostic sharing outside the EU explicitly where that toggle exists

When to bring us in: 
For demands like SecNumCloud or "EU-only sovereign cloud", you are looking at OVHcloud, IONOS, or a specific Microsoft Cloud for Sovereignty offering, not the default region.

Question 51

We discover our AWS root account has no MFA

Accepted Answer

1. Stop other work. MFA on root first: sign in as root, go to IAM > Security credentials > Multi-factor authentication, register a hardware key or a TOTP app on a phone that is not solely on one admin.
2. Store the MFA recovery codes in a vault several people can access. One person with root-MFA on only their personal phone is your next incident.
3. Rotate the root password right after enabling MFA. Was it written somewhere in a wiki or mail? Assume it leaked, do not hope.
4. Enable CloudTrail in every region and review the last thirty days for root login events. Unknown IPs or regions: you are breached and this becomes a data-incident question, not an IT one.
5. Set a policy that root is not used for day-to-day work from now on. Create admin users in IAM Identity Center, vault root, only use it for things only root can do (close account, change support plan).

When to bring us in: 
CloudTrail shows unknown sessions, or resources you do not recognise (cryptominer instances in obscure regions): file with AWS Support, freeze the card through your bank, call us. This goes beyond this ticket.

Question 52

GCP project deleted by accident, or we want to recover something from a deleted project

Accepted Answer

1. Check status: gcloud projects list --filter='lifecycleState:DELETE_REQUESTED' or in the console Resource Manager > Manage Resources > filter 'Pending deletion'. Still there: plenty of time.
2. Restore: in the console click the project and choose Restore Project, or cli: gcloud projects undelete PROJECT_ID. Resources inside the project then need to be re-enabled themselves, some services have a brief reactivation.
3. Window expired: data is gone, not recoverable. For future prevention: set billing-account policies and organisation policy so only specific roles can delete projects.
4. For production projects: use organisation-level Project Lien (gcloud resource-manager liens create). A lien blocks deletion until explicitly removed, a second step that prevents accidents.
5. Document which projects are 'may die' and which are 'absolutely not'. Naming with '-prod' or '-test' suffixes helps and is free.

When to bring us in: 
Project deleted outside the 30-day window with production data in it: not a recovery question any more but an impact assessment. We help to determine whether backups (BigQuery exports, Cloud Storage replication) live elsewhere.

Question 53

Cloud bill rises due to data transfer costs we did not know about

Accepted Answer

1. Open Cost Explorer (AWS), Cost Management (Azure), or Billing > Reports (GCP) and group by service category. Look for 'Data Transfer', 'Bandwidth', or 'Network'. Above 10-15% of total: worth digging in.
2. Identify flows: cross-region replication, NAT gateway to internet, users downloading from outside the region. Inter-region replication especially is a quiet but continuous cost.
3. For S3/GCS: do not set every bucket to cross-region replication 'just in case'. Regional is enough for most backups; cross-region only when RTO/RPO requires it.
4. For outbound traffic to users: put a CDN in front (CloudFront, Cloud CDN, Azure Front Door). Origin egress shrinks and CDN egress is cheaper. For video or large downloads this is almost always sensible.
5. Set a budget alert on the data-transfer category specifically, not only on total. You want to spot a spike in days, not at month-end.

When to bring us in: 
A one-off spike unexplainably large (say tenfold), or structural growth without user growth: hints at misconfiguration or even unwanted activity. We are happy to run a short audit.

Question 54

Grafana Cloud or run Prometheus and Grafana yourself?

Accepted Answer

1. Count metric cardinality, not just series count
2. Under a few million active series, Grafana Cloud free or pro fits
3. Consider self-host only if data residency or audit demands it
4. For self-host, count someone to handle long-term storage and upgrades

When to bring us in: 
For multi-tenant setups or strict data residency, get quotes on both paths.

Question 55

We want least-privilege IAM but every policy ends up as AdministratorAccess

Accepted Answer

1. List the three to five access paths that really exist: developer, deploy bot, read-only for finance, ops, and maybe a data role.
2. For each path, start with an AWS-managed policy like PowerUserAccess or ReadOnlyAccess, not a custom policy from scratch.
3. Turn on CloudTrail, run for two weeks and inspect which actions those roles actually use. Trim what never appears.
4. Use a service-control-policy in AWS Organizations as a guardrail on top, so even Administrator can't touch regions or services you don't want.
5. Review every quarter with IAM Access Analyzer. It surfaces unused permissions and is a good trigger to trim further.

When to bring us in: 
If you handle customer production data or work in a regulated sector, a one-time policy audit by someone with IAM routine is worth it.

Question 56

Someone put port 22 on 0.0.0.0/0 in a security group

Accepted Answer

1. Close the rule now: replace 0.0.0.0/0 with your office IP, or better, remove the rule altogether.
2. For SSH to private instances use AWS Systems Manager Session Manager, Azure Bastion or GCP IAP. No public SSH needed.
3. Turn on AWS Config, Defender for Cloud or Security Command Center with a rule that flags port 22 or 3389 on 0.0.0.0/0 as non-compliant.
4. Review every existing security group and NSG. CloudTrail or Activity Log shows who added the rule, usually worth tracking down.
5. Write into an SCP or Azure Policy that public SSH/RDP rules are denied, not just flagged.

When to bring us in: 
If the instance has been open for weeks and has access to production data, treat it as an incident and bring in someone who does forensics.

Question 57

One VPC for everything or a VPC per app, what's sensible?

Accepted Answer

1. Start with one VPC per environment and a /16 CIDR roomy enough not to fill up in 5 years, e.g. 10.0.0.0/16 for prod and 10.1.0.0/16 for staging.
2. Split per AZ into a public and private subnet, and put all workloads in private. Public is only for load balancers and NAT gateways.
3. Use separate subnets or security-groups per app, not separate VPCs. That keeps routing simple and NAT cost low.
4. Only consider a separate VPC if the app has a different security profile (tenant isolation, payments, compliance scope).
5. Document your CIDR plan in a shared table, otherwise you'll get collisions the moment someone wants to connect on-prem or another cloud.

When to bring us in: 
If you're building multi-tenant SaaS where each customer needs network isolation, the design is materially different. A short review pays off before you commit.

Question 58

We have three VPCs and peering is becoming unmanageable

Accepted Answer

1. Count your peerings: 4 VPCs means 6 peerings, 5 means 10. Above that, transit-gateway starts to make sense.
2. Deploy one transit-gateway per region and attach every VPC. Route tables on the gateway decide who can reach whom.
3. Calculate cost upfront: transit-gateway attachment is hourly per VPC plus per-GB data. For low-volume inter-VPC traffic, peering can stay cheaper.
4. For cross-region or cross-account: transit-gateway peering or Cloud WAN. Stop maintaining manual per-VPC routes.
5. On Azure this is Virtual WAN, on GCP it's Network Connectivity Center. Same pattern, different names.

When to bring us in: 
If you have more than ten VPCs or multi-account with cross-region traffic, a network architect who does this often is worth bringing in.

Question 59

One AWS account for everything is getting crowded

Accepted Answer

1. Enable AWS Organizations in the existing account, which becomes the management account. Don't do anything there except org admin and billing.
2. Create at minimum: log-archive (all CloudTrail logs), security (GuardDuty, IAM Access Analyzer aggregator), prod, and non-prod accounts.
3. Turn on AWS Identity Center (SSO). People get permission sets they can use across accounts, not separate IAM users per account.
4. Attach SCPs at the OU level: e.g. no root actions, no non-EU regions, no Security-disable.
5. Use Control Tower if this is your first time, it lays the baseline (CloudTrail, Config, log-archive) for you.

When to bring us in: 
For 5+ accounts or when regulators look in, a Control Tower baseline plus a short governance session is usually worth setting up.

Question 60

We want an alert when the cloud bill goes above X EUR

Accepted Answer

1. Set an AWS Budget, Azure Cost Management Budget or GCP Budget at your expected monthly spend plus 20 percent. On breach, email finance and CTO.
2. Add a second budget for forecast: trigger if the forecast goes above ceiling mid-month. That fires earlier.
3. Add a third daily alert: e.g. when daily spend exceeds 1/25 of your monthly budget. That catches runaway resources like a forgotten GPU instance.
4. Send alerts to Slack or Teams via SNS+Lambda or Logic App, not just email. People read email too late.
5. Check every quarter that the amount still fits. A stale budget triggers false positives and gets ignored.

When to bring us in: 
If the bill has been climbing for weeks without a clear cause, an hour together in cost explorer usually finds the source.

Question 61

Savings Plan or Reserved Instance, which fits our compute usage?

Accepted Answer

1. In Cost Explorer Recommendations, look at your last 60 days of compute usage. AWS makes its own proposal.
2. For varying workloads: Compute Savings Plan, 1-year, no upfront. Gives discount without locking type or region.
3. For very steady usage (database, fixed app-server) where you know the instance will still run next year, take a Standard RI for 1 or 3 years.
4. Never cover 100 percent of usage. Aim for 70-80 percent covered by commitments, the rest on-demand for flexibility.
5. On Azure this is Reservations or Savings Plans, on GCP CUDs (Committed Use Discounts). Same pattern.

When to bring us in: 
For commitments above a few thousand euro per month, a short FinOps review with someone who does this daily is usually worth the time.

Question 62

Our EC2 or VM bill feels too high for what the servers actually do

Accepted Answer

1. Open AWS Trusted Advisor (Business Support or higher), Azure Advisor, or GCP Recommender. They give concrete per-instance suggestions.
2. Filter on instances with < 20 percent CPU over 14 days and < 50 percent memory. Those are candidates for one size smaller.
3. Test the migration in staging first. Some workloads have occasional peak usage that disappears in an average.
4. For compute that's truly idle outside office hours: schedule stop/start via Instance Scheduler or Azure Automation. Saves a large slice of the hourly cost.
5. Plan rightsizing as quarterly work, not one-off. Workloads change, recommendations change with them.

When to bring us in: 
If you're talking hundreds of instances, a tool like Spot.io or CloudHealth pays off. Below 50 instances, manual with Advisor is enough.

Question 63

How do we prevent someone from accidentally making an S3 bucket public?

Accepted Answer

1. Enable S3 Block Public Access at account level, all four settings on. That overrides any bucket policy or ACL that says otherwise.
2. Run AWS Config rules s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited as continuous checks.
3. Set S3 Object Ownership to Bucket Owner Enforced. That disables ACLs entirely, so only IAM or bucket policy grants access.
4. For buckets that do need to be public (static website, downloads), put CloudFront in front with Origin Access Control. Bucket stays private.
5. On Azure this is Storage Account Public Access disabled, on GCP it's Public Access Prevention. Turn both on at org level.

When to bring us in: 
If you have hundreds of buckets and don't know what's in them, a Macie scan plus a short review is worth it before locking down hard.

Question 64

Should we rotate KMS keys and if so how?

Accepted Answer

1. For symmetric customer-managed keys: enable Automatic Key Rotation. AWS creates new key material yearly, old data remains readable via key versions.
2. Asymmetric keys don't rotate automatically. Create a new key, use both aliases, and migrate software gradually.
3. Audit with CloudTrail which key encrypts what. A KMS key with no usage can usually be scheduled for deletion (7-30 day wait).
4. On Azure this is Key Vault key rotation policy, on GCP Cloud KMS rotation period. Same pattern.
5. Document which key encrypts which data and who is key admin. At an audit, that's the first question.

When to bring us in: 
If you work with PCI data or patient records and rotation frequency is contractually set, a short review with your security officer is worth it.

Cloud platforms