Deployment
Deployment Artifacts, Dependencies, Resources, and Environment Configuration
ImportantPrepare reproducible deployment artifacts with the correct files, dependencies, resource requirements, source provenance, and environment-specific configuration.
Aligned to AWS Certified Developer - Associate (DVA-C02) Version 2.1, verified August 23, 2026.
Why this matters
A release can fail before code starts. Packaging layout, compatible dependencies, approved source, measured resources, and configuration separation determine whether the same tested application can be deployed reliably.
Must Know
- A deployable artifact must contain the runtime-expected handler or entry point, compatible dependencies, and the directory structure expected by the deployment tool.
- Lambda ZIP archives and container images are separate package models. Layers can share compatible dependencies with ZIP-based functions but are not a separate function package type.
- Build from an approved commit or tag and tie the resulting immutable artifact to that source revision; a repository URL or branch name alone does not identify deployed bytes.
- Declare measured memory and compute requirements in the deployment configuration rather than relying on manual post-deployment changes.
- Keep environment-specific values outside the immutable application artifact so the same artifact can be promoted with approved dev, test, and production configuration.
- AWS AppConfig organizes application, environment, configuration profile, and versioned configuration so runtime settings and feature flags can be deployed with validation and controlled rollout.
- Configuration files, environment variables, image references, layers, and dependency manifests all have different lifecycle and secrecy requirements.
Compare and Distinguish
- ZIP package vs container image: both deploy Lambda code, but their build layout, runtime/dependency packaging, image repository, and update workflow differ.
- Artifact vs configuration: the artifact is the versioned executable output; configuration supplies approved environment values without rebuilding it.
- Layer vs bundled dependency: a layer can share compatible content across ZIP functions; bundling keeps the dependency version inside each artifact.
- Commit/tag vs artifact digest: source identifiers establish provenance, while an immutable artifact identifier proves which built output is deployed.
- AppConfig vs Secrets Manager: AppConfig manages application configuration and controlled deployment; Secrets Manager protects and rotates secrets.
Scenario examples
- Scenario: Lambda reports that it cannot import the handler. Put the handler and compatible dependencies at the package paths expected by the runtime.
- Scenario: One binary must move from test to production with different endpoints and flags. Promote the immutable artifact and bind the approved AppConfig/environment values.
- Scenario: A containerized workload requires a measured amount of CPU and memory. Record those values in deployment configuration and reference an approved image.
- Scenario: Operations must reproduce a deployed build. Record the approved source revision and immutable artifact identity in the build output.
Exam traps
- A ZIP that contains the right files under the wrong parent directory can still fail handler discovery.
- A mutable latest image tag is weak artifact provenance.
- An environment variable is not a dependency package, and a source branch is not runtime configuration.
- Do not rebuild the artifact merely to change an approved environment value.
- Do not store rotating secrets in AppConfig simply because they are configuration-like values.
- The target role prepares application requirements; it does not administer operating systems or container clusters.
Key takeaways
- Build deterministic artifacts from approved source.
- Match package layout and dependencies to the target runtime.
- Carry measured resource requirements in declared configuration.
- Separate immutable code from environment-specific configuration and secrets.
- Use controlled configuration deployment for runtime values and feature behavior.
How it works
- The build checks out an approved revision and resolves pinned compatible dependencies.
- It creates a ZIP, image, or other service-supported artifact with deterministic layout.
- The deployment definition supplies resource requirements and immutable artifact identity.
- The target environment supplies approved configuration and secrets through their own managed surfaces.
When to use it
- Use a ZIP package for a supported Lambda runtime and dependency layout that fits the ZIP model.
- Use a Lambda container image when image-based dependency/runtime packaging is required.
- Use a layer for compatible shared ZIP-function content when its independent lifecycle is useful.
- Use AppConfig for validated, deployable application settings and feature flags.
- Use CodeArtifact when an approved managed package repository is part of dependency distribution.
Security and governance implications
- Scan and pin dependencies according to the repository policy and do not include developer credentials in the artifact.
- Restrict who can publish or retag artifacts and configuration versions.
- Keep secrets out of images, ZIP archives, manifests, and ordinary configuration files.
- Grant the build and deploy roles only the source, artifact, configuration, and target actions they require.
Failure signals and diagnosis
- For handler/import errors, inspect archive root, entry point, dependency compatibility, runtime, and architecture.
- For environment-only defects, compare artifact identity first, then configuration and secret versions.
- For unreproducible builds, inspect unpinned dependencies, uncommitted inputs, timestamps, and mutable tags.
- For resource failures, compare observed requirements with declared memory/compute rather than changing every setting.
More detail
- Organize module roots, templates, manifests, and build output so the selected tool packages the intended unit.
- Use compatible dependency builds for the target runtime and processor architecture.
- Treat an artifact identifier, source revision, and environment configuration version as separate provenance facts.
- Apply only existing approved resource and environment requirements; designing a delivery platform is outside this task.
Ready for the quiz?
- What proves which source produced a deployed artifact?
- How does a Lambda layer differ from a container-image package?
- Why should production configuration not require recompilation?
- Where should measured memory and compute needs be recorded?
- When is Secrets Manager preferable to AppConfig?
Related objectives
- D3.1 — Prepare application artifacts to be deployed to AWS
- 3.1.1 — Manage the dependencies of the code module (for example, environment variables, configuration files, container images) within the package
- 3.1.2 — Organize files and a directory structure for application deployment
- 3.1.3 — Use code repositories in deployment environments
- 3.1.4 — Apply application requirements for resources (for example, memory, cores)
- 3.1.5 — Prepare application configurations for specific environments (for example, by using AWS AppConfig)