Deployment practice questions

An Elastic Beanstalk source bundle is a zip (or war) archive whose application files must sit at the root of the archive, with optional environment configuration in an .ebextensions directory inside the bundle.

Zipping the project folder itself puts every file one directory too deep, so the platform cannot locate the application entry files — the deployment succeeds but startup fails, which is exactly the symptom described. A missing .ebextensions directory is harmless because it is optional. ECR is unrelated to Beanstalk source bundles, and the 250 MB unzipped limit is a Lambda constraint, not a Beanstalk one.

1. Open the uploaded archive and check whether files sit at the root or inside a parent folder.
2. Re-create the bundle by zipping the contents of the project folder, not the folder itself.
3. Keep any environment customization files in an .ebextensions directory inside the bundle.
4. Redeploy the corrected bundle and confirm the application starts.

Exam tip: Zip the contents of the project folder for Elastic Beanstalk — a bundle whose files are nested one level deep deploys but fails to start.

Lambda layers share dependencies across functions, but everything in the function package plus its layers must fit within the 250 MB unzipped limit — layers are a code-sharing mechanism, not a size workaround.

Because layer contents count toward the same 250 MB unzipped ceiling, splitting a 300 MB package across layers changes nothing about the total. The real fix for a package this large is repackaging the function as a container image, which allows up to 10 GB. The distractors invent restrictions that do not exist: layers routinely carry third-party libraries, a function can attach up to 5 layers, and layers belong to zip packaging rather than container packaging.

1. Total the unzipped size of the function package plus every attached layer.
2. Compare that total against the 250 MB unzipped limit — layers do not get their own separate budget.
3. If the total exceeds 250 MB, repackage the function as a container image of up to 10 GB in Amazon ECR.
4. Reserve layers for their real purpose: sharing common dependencies across multiple functions.

Exam tip: Layers count toward the 250 MB unzipped limit — when a package outgrows it, the answer is a container image, not more layers.

Lambda layers extract dependencies shared by multiple functions into a separately versioned archive that each function attaches — up to 5 layers per function, all counting toward the 250 MB unzipped limit.

With the utilities library in a layer, an update means publishing one new layer version and pointing the functions at it, rather than rebuilding and redeploying ten packages — exactly the scenario layers are designed for. Downloading code from S3 at invoke time adds latency and a new failure mode. Merging functions is an architecture change disguised as a packaging fix. AppConfig manages configuration data, not executable libraries.

1. Package the shared utilities library as a Lambda layer archive.
2. Publish the layer and attach its version to each of the ten functions.
3. On a library change, publish a new layer version and update the functions' layer references.
4. Verify the combined function-plus-layers size stays within the 250 MB unzipped limit.

Exam tip: When many functions share the same dependency, publish it once as a Lambda layer and version it independently of the functions.

Lock files make builds reproducible by freezing the exact dependency tree, guaranteeing that the artifact built and tested today is byte-for-byte rebuildable from the same commit later.

Committing a lock file (or fully pinned requirements) means CI installs exactly the versions that were tested, eliminating the drift between builds of the same commit. Always installing the newest versions is precisely what causes the problem. Moving dependencies into a layer only relocates the unpinned resolution step. Memory allocation is a runtime sizing decision with no effect on dependency resolution.

1. Generate a lock file that pins every dependency, direct and transitive, to an exact version.
2. Commit the lock file to the Git repository next to the dependency manifest.
3. Configure CI to install strictly from the lock file during sam build or the equivalent packaging step.
4. Update dependencies deliberately by regenerating the lock file in a reviewed commit.

Exam tip: Pin dependencies with a committed lock file so the artifact you tested is the artifact every future build reproduces.

In a SAM project, CodeUri points at the function's source directory and Handler names the entry point within it — for Python, Handler: app.lambda_handler requires app.py at the root of CodeUri to define lambda_handler.

"Unable to import module 'app'" means the runtime could not find or load the module named in the handler string, so the first check is whether app.py with a lambda_handler function actually sits at the root of src/orders/. Deployment-bucket permissions would have failed the deploy itself, the template's own location is irrelevant to handler resolution, and memory sizing cannot cause an import failure.

1. Read the Handler value and split it: module name app, function name lambda_handler.
2. Confirm app.py exists at the root of the CodeUri directory, not in a subfolder.
3. Confirm the file defines a function with the exact name lambda_handler.
4. Run sam build and inspect .aws-sam/build/ to verify the packaged layout matches the handler path.

Exam tip: Handler import errors mean the file name, function name, or CodeUri directory disagrees with the Handler string — check the paths before anything else.

Build output is separate from source: sam build writes resolved artifacts and a rewritten template to .aws-sam/build/, and sam deploy ships from there — the directory is generated, not authored.

Because .aws-sam/build/ is fully regenerated by every build, it belongs in .gitignore alongside node_modules and local .env files; the repository holds what humans author — source, template.yaml, manifests, and lock files. Committing the whole directory or just its rewritten template stores derived output that will drift from source, and moving build output into the source tree destroys the source-versus-artifact separation that makes builds trustworthy.

1. Add .aws-sam/ to .gitignore along with other generated paths such as node_modules.
2. Keep the authored template.yaml, dependency manifests, and lock files committed at the project root.
3. Let CI run sam build to regenerate .aws-sam/build/ from source on every pipeline run.
4. Publish the built artifacts to the artifact store (S3) rather than to Git.

Exam tip: Never commit generated build output — the repository holds what you author, and the build regenerates .aws-sam/build/ from it every time.