Run a mock round

Stages:

1. Trigger on push or pull request.
2. Build: compile, install dependencies, produce an immutable artefact (container image) tagged with the commit SHA.
3. Static checks: lint, type check, format, secret scanning, and dependency vulnerability scanning.
4. Test: unit, integration and end-to-end tests; fail fast and run slower suites in parallel.
5. Publish artefacts to a registry with the version tag.
6. Deploy to staging automatically, then to production using an approval gate or progressive rollout.
7. Verify with smoke tests, health checks, and automated rollback on failure.

Principles: build once and promote the same artefact, keep pipelines fast and reproducible, treat infrastructure and pipeline definitions as code, and make rollbacks easy. Mention blue/green and canary deployments, plus feature flags to decouple deploy from release.

IaC defines infrastructure (networks, servers, databases, DNS, IAM) in version-controlled declarative files, applied by a tool such as Terraform, Pulumi, CloudFormation or Ansible.

Benefits:

• Reproducibility: environments are created identically from the same code.
• Reviewability: changes go through pull requests with diffs and approvals.
• Auditability: version history shows who changed what and when.
• Disaster recovery: rebuild infrastructure on demand.

Key practices: state management and locking (Terraform remote state), module reuse, environment separation through variables/workspaces, drift detection, and policies (OPA/Sentinel) to enforce guardrails. Immutable infrastructure plus IaC fits container-based platforms especially well.

A VM virtualises hardware: each VM runs a full guest OS on a hypervisor, so it is heavy (GBs) and slow to boot (minutes) but strongly isolated.

A container virtualises the OS: containers share the host kernel and package only the application and its dependencies. They are lightweight (MBs), start in seconds and give consistent environments across dev and prod. Isolation is weaker than a VM, which is why sandboxing and runtime hardening matter.

In practice: containers for packaging and scaling application workloads, VMs (or managed node pools) as the underlying infrastructure, and sometimes both, for example a Kubernetes node running many pods.

Defence in depth:

• Identity: least-privilege IAM roles, workload identity, no long-lived static keys, and RBAC scoped per namespace.
• Network: private subnets, security groups/network policies, TLS everywhere, and a service mesh or ingress with WAF where needed.
• Images: minimal base images, non-root users, read-only filesystems, image scanning in CI, and a policy that only signed images deploy.
• Secrets: keep them in a dedicated manager (Vault, AWS Secrets Manager) injected at runtime, never baked into images or committed.
• Runtime: pod security standards, resource limits, admission controllers, and audit logging.
• Operations: patch cadence, backups with restore drills, and automated compliance scans.

Mention the shared responsibility model: the provider secures the cloud, you secure what you put in it.