CD Consulting R&D
CD Consulting R&D · KB-DEV · Entry 2 · slide deck · Published 9 September 2026 · Version 1
Sandbox development and test environments: from local containers to governed cloud accounts
Isolation, reproducibility, storage, cloud governance and automated teardown — fourteen slides from the developer laptop to a governed cloud account.
If you test against the wrong environment, or leave one running, fourteen clickable slides show how to isolate, reproduce and tear down.
Introduction
This is the second deck of the series on Microsoft tooling. The first mapped the portals; this one follows a single question through them: where do I run something I am not yet sure of? The answer moves outward with the required fidelity — a Docker container for the fastest loop, a Kubernetes cluster when orchestration behaviour matters, a governed Azure subscription or AWS account when managed services, policy and cost control enter the picture.
Three slides deserve attention. The storage slides (4 to 7) are the practical core: the difference between a bind mount and a managed volume, between an ephemeral Kubernetes volume and a persistent claim, is what decides whether test data survives a rebuild — and whether it should. The controls slide (11) states the rule that this Knowledge Base already applied elsewhere: secrets live outside images and repositories. The decision guide (13) is the one to keep: use the lightest environment that gives enough fidelity.
As in the first deck, the slides were generated by Microsoft 365 Copilot from a prompt by CD Consulting R&D; the text is reproduced unedited, the introduction, the primer and the annotations are ours, and each slide keeps the clickable links of the original.
Contents
- Sandbox development & test environments
- What is a sandbox?
- The layers underneath
- Docker bind mounts
- Docker managed volumes
- Kubernetes volumes
- Azure Files
- Microsoft Azure
- Amazon Web Services
- Infrastructure as Code
- Networking, identity & secrets
- Observability & test data
- Choose the right sandbox level
- A sandbox factory
- Method and provenance
The deck, slide by slide
1. Sandbox development & test environments
Title slide — Isolation, reproducibility, storage, cloud governance and automated teardown. The path the deck follows: Local containers → Kubernetes → Azure → AWS. Reference: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/considerations/sandbox-environments
2. What is a sandbox?
Purpose. An isolated, disposable environment for experimentation, proof of concept work, development and testing without affecting production or other controlled environments. Key points: Isolation boundary · Disposable lifecycle · Safe experimentation · Cost ownership. Reference: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/considerations/sandbox-environments
3. The layers underneath
Architecture. A sandbox combines compute isolation, orchestration, networking, identity, storage, observability and policy. Fidelity increases as the environment moves from a laptop to a governed cloud account. Key points: Compute & runtime · Network & identity · Persistent storage · Policy & telemetry. Reference: https://learn.microsoft.com/en-us/azure/architecture/guide/azure-sandbox/azure-sandbox
4. Docker bind mounts
Technology. A bind mount maps a host file or directory directly into a container. It is ideal for live source-code sharing, but it couples the container to the host path and grants host write access by default. Key points: Live source sync · Host path dependency · Read-only option · Local development. Reference: https://docs.docker.com/engine/storage/bind-mounts/
5. Docker managed volumes
Technology. Docker-managed volumes persist independently of a container lifecycle. They suit databases, caches and test state that must survive container replacement without exposing a specific host path. Key points: Runtime-managed · Container-independent · Database test data · Easy reuse & backup. Reference: https://docs.docker.com/engine/storage/
6. Kubernetes volumes
Technology. Kubernetes mounts storage into Pods for scratch space, configuration, data sharing or durable state. PersistentVolumes and PersistentVolumeClaims separate storage provisioning from application consumption. Key points: Ephemeral volumes · PV & PVC · StorageClass · CSI drivers. Reference: https://kubernetes.io/docs/concepts/storage/volumes/
7. Azure Files
Technology. Azure Files provides fully managed SMB and NFS shares. The same share can support cloud and on-premises clients, VMs and stateful container workloads that require shared persistent storage. Key points: SMB & NFS · Concurrent access · AKS persistence · Hybrid file access. Reference: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-introduction
8. Microsoft Azure
Cloud Sandbox. A governed Azure sandbox can use a dedicated subscription, inherited policy, isolated networking and modular Terraform infrastructure. DevTest Labs adds reusable templates, policies and automated VM schedules. Key points: Dedicated subscription · Azure Policy · Network isolation · Terraform / DevTest Labs. Reference: https://learn.microsoft.com/en-us/azure/architecture/guide/azure-sandbox/azure-sandbox
9. Amazon Web Services
Cloud Sandbox. Innovation Sandbox on AWS automates temporary sandbox accounts with governance policies, spend controls, reusable blueprints and account recycling after use. Key points: Isolated AWS accounts · Guardrails & policies · Budgets & alerts · Automated recycling. Reference: https://docs.aws.amazon.com/solutions/innovation-sandbox-on-aws/
10. Infrastructure as Code
Automation. Treat sandbox environments as versioned products: define infrastructure in code, validate changes through CI/CD, deploy repeatably and destroy resources automatically when work is complete. Key points: Versioned templates · Policy gates · Repeatable builds · Automated teardown. Reference: https://learn.microsoft.com/en-us/azure/architecture/guide/azure-sandbox/azure-sandbox
11. Networking, identity & secrets
Controls. Keep sandbox networks isolated, minimize privileges, protect secrets outside images and repositories, and control outbound access. Isolation should be intentional rather than assumed. Key points: Separate network · Least privilege · Externalized secrets · Restricted egress. Reference: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/considerations/sandbox-environments
12. Observability & test data
Operations. Centralized logs, metrics and traces make disposable environments diagnosable. Test data should be synthetic or sanitized, scoped to the sandbox and removed during teardown. Key points: Logs, metrics, traces · Test result capture · Synthetic datasets · Cleanup evidence. Reference: https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
13. Choose the right sandbox level
Decision Guide. Use the lightest environment that provides enough fidelity: local containers for speed, Kubernetes for orchestration behavior, and cloud sandboxes for managed services, policy and account-level isolation. Key points: Docker: fastest loop · Kubernetes: platform fidelity · Azure: enterprise integration · AWS: account isolation. Reference: https://docs.docker.com/engine/storage/
14. A sandbox factory
Reference Model. A secure access layer triggers a versioned pipeline, provisions isolated compute and storage, runs tests with telemetry, enforces budgets and policies, then removes the environment and residual data. Key points: Request & approve · Provision & configure · Test & observe · Expire & destroy. Reference: https://learn.microsoft.com/en-us/azure/architecture/guide/azure-sandbox/azure-sandbox
Method and provenance
The deck was produced with Microsoft 365 Copilot (PowerPoint generation) on 9 September 2026, from a prompt by CD Consulting R&D, and exported as Sandbox_Development_and_Test_Environments_Clickable.pptx. For this edition the slides were converted to vector graphics (PowerPoint export to PDF, then one SVG per page) after removing the fourteen illustrations that Copilot had generated — each slide’s speaker notes credit them as “Visual on this slide was generated with Microsoft Copilot” — which brought the deck from 32 MB to 64 KB of text and shapes. The text content is reproduced as generated, unedited; the introduction, the primer and this note are by CD Consulting R&D.
Clickable areas. The buttons of the original deck are carried over: each converted slide is overlaid with transparent link areas placed at the exact position of the deck's hyperlinked shapes (geometry read from the PowerPoint file, expressed as a percentage of the slide), and the same links are repeated in text under each slide for keyboard, screen-reader and print use. Targets are those of the deck, unchanged.