What questions would you ask before designing a container strategy for a new project?

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 (ECS/Fargate, Cloud Run, AKS/EKS/GKE)? This determines whether you need Compose alone, a real orchestrator (Swarm or Kubernetes), or a cloud-native container service with its own specific conventions.
• Is multi-host scale or high availability across machine failures a real, near-term requirement, or a hypothetical "maybe someday"? (See the Kubernetes stack's equivalent judgment question — this directly determines whether Compose is sufficient or a full orchestrator is warranted.)

Questions about the application(s) and their shape

• Is this a single monolithic application, or genuinely several independent services with different scaling/resource profiles? The latter benefits far more from container-level isolation and independent deployability than the former.
• What language/runtime, and does it have a real build/compile step (relevant for whether multi-stage builds are a meaningful optimization) or native dependencies that constrain base image choice (relevant for the Alpine/musl compatibility question)?
• What are the actual persistent-data needs — does this application need genuinely stateful storage (pointing toward volumes, or a StatefulSet-equivalent concept 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) for a team with no prior experience has a real, often underestimated learning-curve cost that should be weighed honestly, not assumed 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 (a private registry requirement, 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 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 first 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 in this conversation 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 regardless of context.