Study DVA-C02 Packaging, Dependencies, and Environment Config: key concepts, common traps, and exam decision cues.
Before AWS can ask whether a release strategy is safe, it first checks whether the application artifact is even packaged correctly. This lesson is about dependency bundles, directory structure, repositories, resource sizing needs, and environment-specific configuration.
Artifact: The deployable package or image that contains the application code and everything needed to run it in a target environment.
Environment-specific configuration: Settings that change between development, test, and production without requiring a different codebase.
AWS wants you to notice:
| Need | Strongest first control | Why |
|---|---|---|
| Same code in dev, test, and prod with different settings | Externalized environment configuration | The artifact stays stable while config changes by environment. |
| Reproducible deployable package | Versioned build artifact with explicit dependencies | Reproducibility beats local-machine assumptions. |
| Serverless app with infrastructure and code together | SAM or CloudFormation-managed packaging flow | Code and deployment shape stay tied to versioned definitions. |
| Containerized app release | Versioned image tag in a repository | Immutable artifact identity matters for rollback and promotion. |
| Resource fit for a deployed workload | Explicit memory and runtime requirements | DVA expects developers to reason about runtime needs before deploy. |
One common exam trap is mixing these together:
If each environment has its own hand-edited code package, you lose:
flowchart LR
A["Source code and dependencies"] --> B["Build versioned artifact"]
B --> C["Store in repository or artifact registry"]
C --> D["Deploy same artifact to environment"]
D --> E["Apply environment-specific configuration"]
Strong answers usually prefer one stable artifact moving through multiple environments rather than multiple similar-but-not-identical artifacts.
| Trap | Better thinking |
|---|---|
| Different settings baked directly into code for each environment | Keep the artifact stable and vary configuration externally. |
| Repository tagging treated as optional release ceremony | Version identity is what makes rollback and promotion intelligible. |
| Packaging without runtime or memory awareness | Artifact prep includes knowing what the target runtime actually needs. |
| Local build assumptions not captured in the package | If the package is not self-contained enough, deployment and runtime break later. |
| Pair | How to separate them |
|---|---|
| artifact version vs environment variable | what is deployed vs how it is configured |
| dependency bundle vs runtime setting | what the app needs to run vs what it should do in a specific environment |
| repository identity vs release target | where the artifact lives vs where it is promoted |
| image tag vs branch name | immutable built artifact label vs source control workspace |