09.MOD · Warm-up

How modern teams run cloud

Console clicks and downloaded JSON keys belong to 2018. Here's what cyber-forward cloud teams do instead in 2026.

The cloud reference chapters showed you the primitives: IAM policies, VPC firewalls, bucket settings, KMS keys. Cyber-forward teams rarely touch these by hand. They are produced by code, tested before deployment, applied at scale, and re-evaluated continuously. The same primitives are in play; the workflow around them has shifted.

This page is a warm-up: a tour of six patterns you'll meet on a modern cloud team. If you read it before the labs, the labs themselves stop being "click this; verify that" and start being "I see what they're really teaching."

The big shift

The cloud console is for reading, not writing.

The single change underneath almost everything here: cloud changes are made by code, not by clicks. Every resource — every IAM role, every bucket, every firewall rule — exists because a Git commit said so. A pull request edits the Terraform; CI lints it, plans it, and (after review) applies it. The console is where you go to read the current state and debug; production changes go through Git.

This sounds bureaucratic. It is also why a modern cloud environment can be rebuilt from scratch in an afternoon, why a misconfiguration can be reverted in one commit, and why "who created this bucket and when?" has a real answer.

01

Infrastructure as Code

Console click-ops

Provision in the UI, hope you remember

Engineer logs in, clicks through the wizard, makes a bucket. Three months later, nobody can reproduce that bucket's configuration. Production drifts from what's "supposed" to exist.

Declarative IaC

Resources live in Git, applied by CI

Bucket is one file in a Terraform repository. CI runs terraform plan on every PR; reviewers approve; merge triggers terraform apply. Drift is detected and corrected on a schedule.

What you'll meet

Terraform / OpenTofu — the de facto standard. Pulumi — same idea, real programming languages instead of HCL. AWS CDK, Azure Bicep, Google Config Connector — provider-native options. Drift detection: Atlantis, Terraform Cloud, Spacelift. Policy as code: OPA / Conftest, Sentinel, tfsec, Checkov — lint the IaC before it ships.

Why the labs still matter: when Terraform's plan output says "this will create an S3 bucket with these properties," you still need to read what those properties mean. The lab's policy-walkthrough exercise is exactly what an IaC reviewer does on every PR — just transposed into HCL.

02

Cloud Security Posture Management

Quarterly audit

Spreadsheet, sample, hope

Security team sample-audits 20 of 800 buckets each quarter. Misconfigurations between audits go undetected. Findings ship as a spreadsheet.

CSPM

Continuous scan of every resource

A CSPM platform inventories every resource in every account, evaluates each one against a benchmark (CIS, NIST, PCI), and produces a real-time prioritized findings feed. Misconfigurations surface within minutes, not quarters.

What you'll meet

Native: AWS Security Hub, Microsoft Defender for Cloud, GCP Security Command Center. Multi-cloud: Wiz, Orca Security, Lacework, Prisma Cloud, CrowdStrike Falcon Cloud Security. Open-source: Prowler, ScoutSuite. The modern term has expanded to CNAPP (Cloud-Native Application Protection Platform), which bundles CSPM + CWPP + identity analytics + attack-path mapping.

03

Identity — SCIM-driven, just-in-time

Standing access + IAM users

Long-lived keys, always-on admin

Engineers have IAM users with admin permissions and access keys in their ~/.aws/credentials. The keys live there until someone leaves the company. Admin is permanent because revoking it breaks tickets.

IdP → SCIM → SSO → JIT

Federated, ephemeral, conditional

Identities live in Okta / Entra. SCIM provisions group membership to AWS IAM Identity Center, Azure RBAC, GCP IAM. Engineers federate in; sessions are short-lived. Admin permissions are eligible, not active — activated via PIM / IAM Identity Center session policies / Vault, with justification and time limits.

What you'll meet

IdPs: Okta, Microsoft Entra ID, Google Workspace, JumpCloud. JIT elevation: Entra PIM, AWS IAM Identity Center session policies, HashiCorp Vault, Teleport, ConductorOne, Sym, Opal. Cloud Infrastructure Entitlement Management (CIEM): Microsoft Entra Permissions Management, Wiz CIEM, SailPoint.

04

Secrets — never on disk

.env files

Secrets in config; rotated never

Database connection strings, API keys, signing keys live in .env files, deployment manifests, CI variables. Rotation is "we should do that someday."

Secrets manager + workload identity

Pulled at runtime via an identity

Secrets live in AWS Secrets Manager / Azure Key Vault / GCP Secret Manager / HashiCorp Vault. Workloads fetch them at startup using their managed identity / IAM role / service account. The secret is never in the deployment artifact.

What you'll meet

Cloud-native: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager. Multi-cloud: HashiCorp Vault, 1Password Secrets Automation, Doppler, Infisical. Kubernetes: External Secrets Operator, SOPS, Sealed Secrets. Pre-commit guards: GitGuardian, TruffleHog, gitleaks.

05

Container-native security

VM + EDR

One agent per host

Workloads run on VMs. CrowdStrike or SentinelOne sits on each VM. Compliance comes from a scan and a checkbox.

CNAPP + Kubernetes

Workloads as containers, security at every layer

Containers on Kubernetes. Image scanning at build (Trivy, Snyk). Admission control rejects bad images at deploy (Kyverno, OPA Gatekeeper). Runtime detection via eBPF (Falco, Tetragon). Pod-to-pod traffic encrypted with a service mesh.

What you'll meet

Image scanning: Trivy, Snyk, Grype, Anchore. Admission control: Kyverno, OPA Gatekeeper. Runtime security: Falco, Tetragon, CrowdStrike Falcon Cloud Workload Protection. Service mesh: Istio, Linkerd, Cilium. Confidential computing: AWS Nitro Enclaves, Azure Confidential VMs, gVisor, Kata Containers.

06

Observability & detection

Per-account CloudTrail

Logs in S3, read on incident

CloudTrail is on; logs land in a bucket; nobody reads them unless someone says "what happened?"

SIEM + cloud-native threat detection

Continuous correlation, alerting, automation

Logs from every cloud, every SaaS, every endpoint stream into a SIEM. Detection rules fire on suspicious patterns (impossible travel, new region usage, role enumeration). A SOAR playbook can revoke credentials, isolate a container, or page the on-call within minutes.

What you'll meet

Cloud-native: AWS GuardDuty, AWS Detective, Defender for Cloud, GCP Chronicle / SCC. SIEM: Splunk, Microsoft Sentinel, Sumo Logic, Datadog, Elastic SIEM, Panther. SOAR: Splunk SOAR, Tines, Torq, XSOAR. Modern principle: alerts are actionable or they're a waste of pager time. Tune ruthlessly.

The point

Every modern practice on this page compiles down to the same primitives the labs teach. The IAM policy a CSPM tool flags as overly permissive is the same JSON you read in the S3 lab. The runtime that Terraform provisions is the same VPC the AWS Network chapter describes. The mechanics didn't get easier; they got automated, codified, and continuously enforced.

When something breaks — and at every cyber-forward company, something breaks every day — the engineer who can read the IAM JSON, understand the VPC architecture, and recognize an SSRF-to-IMDS chain is the one who diagnoses it. The IaC didn't deploy itself; the CSPM didn't alert itself; the secrets manager didn't rotate itself. Knowing the primitives is what lets you operate the abstractions above them.

Go do the labs.

References

Formatted in APA 7. Alphabetized by first author's last name.

  1. Center for Internet Security. (n.d.). CIS benchmarks. https://www.cisecurity.org/cis-benchmarks/
  2. Cloud Native Computing Foundation. (n.d.). Cloud-native landscape. https://landscape.cncf.io/
  3. Gartner. (2023). Market guide for cloud-native application protection platforms. (Industry analyst report — defines CNAPP category.)
  4. HashiCorp. (n.d.). Terraform: Infrastructure as code. https://developer.hashicorp.com/terraform
  5. Hunt, P., Grizzle, K., Ansari, M., Wahlstroem, E., & Mortimore, C. (2015). System for cross-domain identity management: Protocol (Request for Comments No. 7644). Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/rfc7644
  6. Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero trust architecture (NIST Special Publication No. 800-207). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207