What questions would you ask before designing a container strategy for a new project?
Quick Answer
Ask about the deployment target (a single host, an orchestrator, a specific cloud platform), the number and nature of services involved (a monolith vs. genuinely independent services), the team's existing container/orchestration expertise, security and compliance requirements (data sensitivity, regulatory constraints on where images/data can live), and CI/CD integration needs. The goal is gathering enough concrete information to make deliberate choices about base images, registry, orchestration layer, and security posture, instead of defaulting to a generic, one-size-fits-all container setup.
Detailed Answer
This question tests whether a candidate gathers information deliberately before committing to a container architecture, rather than reflexively applying a generic template. A strong answer organizes the questions into clear categories.
Questions about the deployment target
- Where will this actually run — a single server, a multi-host cluster, a specific cloud provider's container service like ECS/Fargate, Cloud Run, or AKS/EKS/GKE? This determines whether you need Compose alone, a real orchestrator like Swarm or Kubernetes, or a cloud-native container service with its own conventions.
- Is multi-host scale or high availability across machine failures a real, near-term requirement, or a hypothetical "maybe someday"? This directly determines whether Compose is enough or a full orchestrator is warranted.
Questions about the applications and their shape
- Is this a single monolithic application, or several genuinely independent services with different scaling/resource profiles? The latter benefits far more from container-level isolation and independent deployability.
- What language/runtime, and does it have a real build or compile step (relevant for whether multi-stage builds are worth it), or native dependencies that constrain base image choice (relevant for Alpine/musl compatibility)?
- What are the actual persistent-data needs? Does this application need genuinely stateful storage — pointing toward volumes, or a StatefulSet-equivalent if orchestrated — or is it fully stateless?
Questions about team context and expertise
- What container/orchestration experience does the team already have? Adopting Kubernetes, or even just Docker generally, has a real, often underestimated learning-curve cost for a team with no prior experience. Weigh that honestly, don't assume it away.
- What's the existing CI/CD tooling, and how well does it integrate with container-based builds — registry access, build-caching support, secret-handling capability?
Questions about security and compliance requirements
- Is there sensitive data involved that constrains where images or registries can live, like a private registry requirement or geographic data-residency constraints?
- Are there specific compliance requirements — image signing, vulnerability scanning gates, audit logging — that should be built into the pipeline from day one, rather than retrofitted later?
- What's the actual threat model? Is this internet-facing and handling untrusted input, warranting stronger hardening (non-root, dropped capabilities, read-only filesystems) from the start? Or is it an internal-only tool with a much lower immediate risk profile?
Why asking questions first, rather than jumping to an answer, is itself the right signal
A candidate who immediately says "just containerize everything with Docker and deploy to Kubernetes," without asking any of the above, is skipping the actual analysis a real architecture decision requires. The right container strategy depends entirely on the answers to these questions. A senior engineer's real value here is knowing which questions actually change the recommendation — deployment target and team expertise are usually the two most consequential — not having one favorite stack applied identically to every situation.