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, runtime requirements, 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-C02 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.
Simple Python dependency pinning example:
1boto3==1.37.38
2requests==2.32.3
The exam point is not the package manager itself. It is that dependency identity belongs in the build path, not in “whatever happened to be installed on the build laptop.”
Simple Lambda configuration example:
1import os
2
3STAGE = os.environ["STAGE"]
4TABLE_NAME = os.environ["TABLE_NAME"]
Again, the point is that the same artifact should adapt through configuration, not through source-code edits per environment.
| 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 |
DVA-C02 usually rewards the answer that preserves a clean promotion path across environments.