Application Artifacts — DVA-C02 Study Guide

What an artifact is, and how you package it

A deployment artifact is the immutable bundle you hand to AWS to run, and the rule that governs everything else on this page is that it is self-contained: it carries the code plus every runtime dependency, with one deliberate exception, secrets and per-environment config, injected at deploy or run time so the same build promotes unchanged from dev to prod. Turning your Lambda, ECS, or CloudFormation-deployed code into that bundle means picking a packaging format and size envelope, understanding how AWS SAM (the Serverless Application Model build-and-deploy tooling, defined next) builds and uploads it, and reading the CloudFormation pieces it deploys through.

One rule sits under everything here: an artifact is self-contained. It must carry the code plus every dependency the code imports at runtime, because the managed execution environment adds nothing you did not package. The single recurring exception, secrets and per-environment values, is not baked in; it is injected at deploy or run time (the last section), so the same artifact promotes unchanged from dev to test to prod.

For AWS Lambda^[2] the artifact comes in one of two package types, and the choice is locked at function creation. You cannot switch a function from one type to the other later; you must create a new function. The diagram below groups each package type with its own size ceiling and store:

.zip archive: your handler plus third-party libraries installed for the function's runtime and architecture (x86_64 or arm64; a package compiled for the wrong architecture fails at invoke). A .zip is capped at 50 MB when uploaded directly through the API, SDK, or console, and 250 MB unzipped including layers and custom runtimes^[3]; larger .zip files must be uploaded from Amazon S3 rather than inline. The .zip is stored by the Lambda service itself.
Container image: a Docker/OCI image up to 10 GB uncompressed^[8], stored in Amazon ECR (Elastic Container Registry, AWS's managed image registry). This is the choice when dependencies, native binaries, machine-learning models, or a custom runtime exceed the .zip limits.

Lambda layers^[4] factor common dependencies out of each .zip so they are not rebundled into every function: a layer is a separate .zip of libraries or a runtime that multiple functions reference. A function can attach up to 5 layers, but a layer's unzipped contents count toward the same 250 MB unzipped quota as the function code. Layers cut duplication and upload size, not the total uncompressed ceiling. Layers apply only to .zip functions; a container-image function bakes its dependencies into the image instead, so it has no layers.

The two Lambda package types: a .zip (50 MB / 250 MB unzipped, up to 5 layers) stored by Lambda, vs a container image (up to 10 GB) in Amazon ECR.

SAM and CloudFormation: building and deploying the artifact

This section covers the engine that deploys the artifact: AWS CloudFormation (AWS's infrastructure-as-code service, which provisions a declared set of resources together as a stack) and AWS SAM (Serverless Application Model), which sits on top of it. The single most-tested fact: SAM is not a separate engine. An AWS SAM template is an extension of CloudFormation^[5]. It adds shorthand serverless resource types (for example AWS::Serverless::Function), and the line Transform: AWS::Serverless-2016-10-31 is a CloudFormation macro that expands those shorthand resources into standard CloudFormation resources at deploy time. Because SAM resources sit beside plain CloudFormation resources in one template, anything you can write in raw CloudFormation you can also write in SAM.

The SAM build-and-ship flow has three steps that map directly onto how the artifact reaches AWS:

sam build^[6]: resolves and installs each function's dependencies and gathers the result into a local .aws-sam/build directory. This is where the self-contained artifact is assembled.
sam package: uploads those built artifacts to Amazon S3 (or to Amazon ECR for container images) and rewrites the template's local code paths to the uploaded S3/ECR URIs, producing a deployable template that points at the stored artifact.
sam deploy: submits that template to CloudFormation, which creates or updates the stack (sam deploy runs the package step for you if you have not already).

The CloudFormation pieces you need to recognize when reading or shipping a template:

Parameters are the per-environment knobs (the next section uses them); Mappings are static lookup tables (e.g., region → AMI); Outputs export values such as an API URL for other stacks to consume.
Intrinsic functions wire resources together: Ref returns a resource's primary identifier (or a parameter's value), Fn::GetAtt returns a specific attribute of a resource (e.g., a bucket's ARN), and Fn::Sub substitutes variables into a string.
A change set^[9] is a preview of exactly what an update would add, modify, or delete before you execute it: the safe way to update a stack.
Nested stacks let one parent template reference child templates so large architectures are composed from reusable modules instead of one monolithic file.
Drift detection^[10] reports where a stack's actual resource configuration has diverged from its template because someone changed a resource out-of-band (e.g., edited it in the console).

Artifact stores, summarized: Lambda .zip artifacts and CloudFormation/SAM templates live in Amazon S3; container images live in Amazon ECR; and your language packages (the npm, PyPI, or Maven dependencies that sam build pulls in) can be hosted privately in AWS CodeArtifact^[11], AWS's managed package repository, so builds resolve dependencies from a controlled, versioned source.

The SAM artifact pipeline: sam build assembles the artifact, sam package uploads it to S3 (.zip/templates) or ECR (images), and sam deploy hands the rewritten template to CloudFormation as a stack.

Keeping configuration out of the artifact

This section answers the one deliberate exception to "package everything": environment-specific configuration and secrets do not belong inside the artifact. Bake them in and you must build a separate artifact per environment, which breaks the guarantee that what you tested is byte-for-byte what you ship. Instead you build the artifact once and inject the differences at deploy or run time. The diagram below splits those injection points by when they apply: deploy time versus run time.

CloudFormation / SAM Parameters carry the deploy-time differences. The same template produces a dev stack or a prod stack purely by passing different parameter values (instance size, table name, log level). You change the inputs, never the template, so the artifact and its template stay identical across environments.
AWS AppConfig^[7] (a feature of AWS Systems Manager) decouples configuration from code so you can change application behavior without a code deployment. It sources configuration data from its own hosted store, SSM Parameter Store, Secrets Manager, or S3, and, its defining feature, runs validators that check the data is syntactically and semantically correct before any rollout, so a bad config never reaches your application. Reach for AppConfig when a question stresses changing a feature flag, an operational setting, or behavior at runtime without redeploying.
SSM Parameter Store holds plain configuration values an application fetches at runtime by name (e.g., an endpoint URL); a SecureString parameter additionally encrypts the value with AWS KMS. It is the simple store when you just need a named value, not the validation-and-rollout machinery of AppConfig.
Secrets (database passwords, API keys) are never packaged into the artifact at all; they are referenced at runtime from AWS Secrets Manager or an SSM SecureString. That boundary belongs to sensitive-data management: the artifact carries only the code that fetches the secret, never the secret itself.

The through-line: the artifact is immutable and identical everywhere; Parameters vary it at deploy time and AppConfig / Parameter Store / Secrets Manager vary it at run time.

One immutable artifact, environment differences injected by timing: Parameters at deploy time; AppConfig, Parameter Store, and Secrets Manager at run time.

Exam-pattern recognition: artifacts, SAM, and CloudFormation

DVA-C02 Domain 3 questions describe a packaging or template situation and ask which choice fits. Map the keyword in the stem to the answer, using the models built above.

Packaging keywords:

"dependencies exceed the size limit," "large ML model," "native binary," "custom runtime," "up to 10 GB" → container image in Amazon ECR (the .zip ceiling is 50 MB direct / 250 MB unzipped; the image ceiling is 10 GB).
"share a common library across many functions," "avoid rebundling dependencies" → Lambda layers (up to 5 per function, counting toward the same 250 MB unzipped quota).
"change a function from .zip to container image" → not possible in place. You must create a new function; the package type is fixed at creation.
"upload a .zip larger than 50 MB" → upload from Amazon S3 (direct upload is capped at 50 MB).

SAM / CloudFormation keywords:

"shorthand serverless resources," Transform: AWS::Serverless-2016-10-31, "AWS::Serverless::Function" → AWS SAM, which expands via the Transform macro into standard CloudFormation.
"preview changes before applying an update" → change set, not a blind stack update.
"someone changed a resource outside the template," "actual config diverged" → drift detection.
"reference one resource's attribute (ARN) in another" → Fn::GetAtt; "resource's primary ID or a parameter value" → Ref; "substitute a variable into a string" → Fn::Sub.
"compose large infrastructure from reusable modules" → nested stacks.

Configuration / promotion keywords:

"change behavior without redeploying code," "feature flag," "validate config before rollout" → AWS AppConfig.
"same artifact across dev/test/prod," "differ only by environment" → build once, inject via CloudFormation/SAM Parameters (deploy time) and AppConfig/Parameter Store (run time).
"store the database password / API key the app reads at runtime" → Secrets Manager or an SSM SecureString, never the deployment package.
"private repository for npm/PyPI/Maven dependencies the build pulls" → AWS CodeArtifact.

Why common distractors are wrong (each ties back to a rule above):

A .zip is not the answer when dependencies exceed its quota. The size envelope built in the first section pushes that to a container image in ECR.
SAM is not a separate deployment engine to choose instead of CloudFormation. By the extension rule above it is CloudFormation plus a macro, so "SAM vs CloudFormation" as exclusive alternatives is a false choice.
A plain stack update is the wrong pick when the stem wants a preview. That is exactly what a change set provides.
Baking environment values or secrets into the artifact is wrong by the promotability rule: it forces a per-environment build and leaks secrets into the bundle.

Package type	Max size	Stored in	Supports layers	Changeable after function creation	Best for
.zip archive	50 MB upload / 250 MB unzipped (incl. layers)	Lambda service (or S3 for upload >50 MB)	Yes (up to 5)	No (must create new function)	Small functions; pure-language or prebuilt dependencies
Container image	10 GB uncompressed	Amazon ECR	No (dependencies baked into image)	No (must create new function)	Large dependency sets, native binaries, custom runtimes

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

A deployment artifact is self-contained: it carries every runtime dependency

A deployment artifact is the immutable bundle you hand to AWS to run, and it must include the code plus every library the code imports at runtime, because the managed execution environment adds nothing you did not package. The one deliberate exception is environment-specific configuration and secrets, which are injected at deploy or run time so the same bundle promotes unchanged across dev, test, and prod. Configuration files and other static assets do travel inside the package; only per-environment values and credentials stay out.

Trap Assuming the managed runtime supplies common third-party libraries so you can leave them out of the bundle. Only the language's standard library and AWS SDK are present, so any other dependency you import must be packaged.

Match the Lambda .zip to the function's runtime AND architecture

A Lambda .zip archive holds your handler plus third-party libraries compiled for the function's runtime and CPU architecture: x86_64 or arm64. A package built for the wrong architecture passes upload but fails at invoke, because native dependencies are architecture-specific. When you switch a function between arm64 and x86_64, rebuild the dependencies for the new architecture.

Trap Assuming a working x86_64 .zip runs unchanged on arm64. Native extensions are compiled per-architecture and break at invoke, not at upload.

A Lambda .zip is capped at 50 MB direct upload and 250 MB unzipped

A Lambda .zip is limited to 50 MB when uploaded directly through the API, SDK, or console, and to 250 MB unzipped, a ceiling that includes the function code plus all attached layers and custom runtimes. A .zip larger than 50 MB cannot be uploaded inline; you upload it to Amazon S3 first and point Lambda at the S3 object. The 250 MB unzipped figure is the hard ceiling on total uncompressed size.

Trap Trying to push a .zip over 50 MB straight through the console or API. Anything larger must be staged in S3 and referenced from there.

3 questions test this

Use a container image in ECR when dependencies exceed the .zip limits

When a function's dependencies, native binaries, machine-learning models, or custom runtime exceed the .zip ceiling, package it as a container image instead. Lambda accepts an image up to 10 GB uncompressed, stored in Amazon ECR (Elastic Container Registry, AWS's managed image registry). The image bakes in its own dependencies, so it has no layers. Reach for .zip for small, pure-language or prebuilt-dependency functions; reach for a container image when size or native tooling rules .zip out.

Trap Picking a .zip for a large ML model or native-binary workload. It blows past the 250 MB unzipped cap, where a 10 GB container image is the intended path.

2 questions test this

A Lambda function's package type is fixed at creation

You choose .zip or container image when you create a Lambda function, and you cannot switch a function from one package type to the other afterward. To change type you create a new function. The package type is an immutable property, unlike code or configuration, which you can update in place.

Trap Assuming you can convert an existing .zip function to a container image in place. The type is locked at creation, so you must stand up a new function.

Lambda layers factor shared dependencies out of each function's .zip

A Lambda layer is a separate .zip of libraries or a runtime that multiple functions reference, so a common dependency is uploaded and stored once rather than rebundled into every function. A function can attach up to 5 layers. Layers cut duplication and per-function upload size, but a layer's unzipped contents still count toward the same 250 MB unzipped quota as the function code. They reduce duplication, not the total uncompressed ceiling. Layers apply only to .zip functions; a container-image function bakes its dependencies into the image and has no layers.

Trap Treating layers as a way around the 250 MB limit. A layer's unzipped size counts toward that same ceiling.

6 questions test this

SAM is an extension of CloudFormation, not a separate deployment engine

An AWS SAM (Serverless Application Model) template is an extension of CloudFormation: it adds shorthand serverless resource types such as AWS::Serverless::Function, and those expand into standard CloudFormation resources at deploy time. Because SAM resources sit beside plain CloudFormation resources in one template, anything you can write in raw CloudFormation you can also write in a SAM template. There is no separate SAM provisioning service to choose instead of CloudFormation.

Trap Treating "SAM vs CloudFormation" as mutually exclusive engines. SAM is CloudFormation plus a macro, so it is never an alternative to it.

Transform: AWS::Serverless-2016-10-31 is the macro that turns a template into SAM

The line Transform: AWS::Serverless-2016-10-31 at the top of a template is the CloudFormation macro that marks it as a SAM template and expands the shorthand serverless resources into standard CloudFormation resources during deployment. Spotting that exact Transform value (or an AWS::Serverless::* resource type) is how you identify a template as SAM rather than plain CloudFormation.

sam build, package, deploy map onto how the artifact reaches AWS

The SAM CLI ships an artifact in three steps. sam build resolves and installs each function's dependencies into a local .aws-sam/build directory. This is where the self-contained artifact is assembled. sam package uploads those built artifacts to Amazon S3 (or to Amazon ECR for container images) and rewrites the template's local code paths to the uploaded URIs. sam deploy submits that rewritten template to CloudFormation to create or update the stack, and it runs the package step for you if you have not already.

Trap Thinking sam build is the step that uploads the artifact to S3. Build only assembles dependencies locally; sam package (or sam deploy) is what uploads to S3 and rewrites the code URIs.

4 questions test this

Know what Parameters, Mappings, and Outputs do in a template

A CloudFormation template uses Parameters as the per-environment input knobs (instance size, table name, log level) that vary one template into different stacks; Mappings as static lookup tables resolved at deploy time (for example region to AMI ID); and Outputs to export values such as an API URL or bucket name for other stacks or operators to consume. Passing different Parameter values is what lets the same template produce a dev stack or a prod stack without editing it.

Trap Using Mappings to feed per-environment values like instance size or table name. Mappings are static lookup tables, so caller-supplied per-environment differences belong in Parameters.

Ref, Fn::GetAtt, and Fn::Sub each wire templates differently

CloudFormation intrinsic functions connect resources. Ref returns a resource's primary identifier (or a parameter's value), typically the name or ID. Fn::GetAtt returns a specific attribute of a resource, such as a bucket's ARN or a DynamoDB table's stream ARN, which Ref does not give you. Fn::Sub substitutes variables into a string, letting you interpolate references inline. Pick Fn::GetAtt when you need an attribute like an ARN; pick Ref when the primary ID or a parameter value is enough.

Trap Using Ref to get a resource's ARN. Ref returns the primary identifier, so an ARN or other attribute needs Fn::GetAtt.

Use a change set to preview a stack update before executing it

A change set is a preview of exactly what a stack update would add, modify, or delete, generated before you execute it, the safe way to update a stack because you confirm the blast radius first, including any resource replacements. When a question asks how to see the impact of a template change before applying it, the answer is a change set, not a blind stack update.

Trap Running a plain stack update when the stem wants a preview of the changes. Only a change set shows what will change before you commit.

Nested stacks compose large architectures from reusable child templates

Nested stacks let one parent template reference child templates as resources, so a large architecture is built from reusable, modular pieces instead of one monolithic file. Each child is its own stack the parent provisions, which keeps templates within size limits and lets common patterns (a standard VPC, a logging bucket) be reused across stacks.

Trap Reaching for cross-stack references (Export/Fn::ImportValue) when the goal is to provision and manage child templates as one unit. That lifecycle composition is what nested stacks provide, while exports only share values between independently managed stacks.

Drift detection reports where a stack diverged from its template

Drift detection compares a stack's actual resource configuration against what its template declares and reports any differences caused by out-of-band changes, for example, someone editing a resource directly in the console or CLI. It is the tool for catching configuration that no longer matches the source-of-truth template, not for previewing a planned update.

Trap Reaching for a change set to find manual console edits. Change sets preview intended updates, while drift detection surfaces unintended out-of-band changes.

1 question tests this

A company's compliance team requires validation that CloudFormation-managed infrastructure has not changed from its deployed configuration…

Know where each artifact type is stored

Lambda .zip artifacts and CloudFormation/SAM templates are stored in Amazon S3; container images live in Amazon ECR; and your language packages (the npm, PyPI, or Maven dependencies a build pulls in) can be hosted privately in AWS CodeArtifact, AWS's managed package repository. CodeArtifact gives builds a controlled, versioned source for dependencies rather than pulling them from public registries directly.

Trap Reaching for S3 or ECR to host private npm, PyPI, or Maven packages. Hosting those package registries is CodeArtifact's job, while S3 holds .zip/templates and ECR holds container images.

Use AppConfig to change behavior without redeploying code

AWS AppConfig (a feature of AWS Systems Manager) decouples configuration from code so you can change application behavior (a feature flag, an operational setting) without a code deployment. Its defining feature is validators that check the configuration is syntactically and semantically correct before a rollout, so a bad config never reaches the running application. It can source data from its own hosted store, SSM Parameter Store, Secrets Manager, or S3. Reach for AppConfig when the stem stresses changing behavior at runtime or validating config before it goes live.

Trap Choosing plain Parameter Store when the question stresses validating config before rollout or toggling a feature flag without a deploy. That validation-and-rollout machinery is AppConfig, not a bare named value.

Use SSM Parameter Store for simple named config values

SSM Parameter Store holds plain configuration values an application fetches at runtime by name, such as an endpoint URL or a numeric setting. A SecureString parameter additionally encrypts the value with AWS KMS, which is how you store a sensitive value without Secrets Manager. Choose Parameter Store when you just need a named value retrieved at runtime, not the validation-and-rollout machinery of AppConfig.

Trap Reaching for Secrets Manager for any sensitive value when no rotation or generation is needed. A KMS-encrypted SecureString parameter stores a secret in Parameter Store at lower cost.

Build the artifact once; inject per-environment differences at deploy and run time

Bake environment-specific values into the artifact and you must build a separate bundle per environment, which breaks the guarantee that what you tested is byte-for-byte what you ship. Instead build the artifact once and vary it externally: CloudFormation/SAM Parameters supply the deploy-time differences, while AppConfig and Parameter Store supply the run-time differences. The artifact and its template stay identical across dev, test, and prod.

Never package secrets into the artifact: reference them at runtime

Database passwords, API keys, and other secrets are never packaged into the deployment artifact; the bundle carries only the code that fetches the secret. At runtime the application reads the value from AWS Secrets Manager or an SSM SecureString parameter. Embedding the secret in the package leaks it into every copy of the artifact and ties the build to one environment.

Trap Putting a database password or API key in an environment variable baked into the package. It leaks into the artifact; fetch it at runtime from Secrets Manager or a SecureString instead.

Elastic Beanstalk config files must be .config files inside an .ebextensions folder at the bundle root

To customize an Elastic Beanstalk environment (install packages, set options), place YAML or JSON configuration files with the .config extension in a folder named exactly .ebextensions (leading dot required) at the root of the source bundle. Files outside that folder, without the .config extension, or in a folder misnamed 'ebextensions' are silently ignored. When zipping, include hidden dot-folders (for example zip -r app.zip * .[^.]*) and produce a bundle with no parent folder so .ebextensions sits at the root.

Trap Naming the folder 'ebextensions' without the leading dot, or zipping with a wrapping parent folder. Elastic Beanstalk then ignores the config files entirely.

6 questions test this

Elastic Beanstalk uses a Procfile for multiple processes and cron.yaml for worker periodic tasks

An Elastic Beanstalk source bundle is a single ZIP (or a WAR for Java) with special files at its root. A Procfile declares multiple long-running processes (the main one must be named 'web' and is listed first) and Elastic Beanstalk restarts any that exit; it is also how you pass JVM options per Java process. A worker environment's periodic background jobs are defined in a cron.yaml at the root, each with a name, URL path, and a CRON schedule. The multi-container ECS-managed Docker platform instead uses a Dockerrun.aws.json v2 at the root (with a .dockercfg in S3 for private-registry auth).

Trap Hand-rolling a startup script for several processes. Elastic Beanstalk monitors and restarts processes only when they are declared in a root Procfile (web first).

4 questions test this

An Elastic Beanstalk application-version source bundle must be in-region and readable

When you create an Elastic Beanstalk application version from a source bundle in S3, the bucket must be in the same AWS Region as the environment, or the call fails with an invalid-S3-location error. If the bundle lives in a custom bucket with a restrictive policy, also grant the IAM identity creating the version s3:GetObject (and s3:GetObjectVersion) on the bundle object, or the create fails with access denied.

Trap Assuming a valid, existing S3 bundle is enough. A different-Region bucket fails as 'invalid S3 location', and a restrictive bucket policy fails as access denied without explicit s3:GetObject.

2 questions test this

An Elastic Beanstalk application version lifecycle policy prunes old versions automatically

Elastic Beanstalk caps application versions per Region; to avoid hitting the quota, configure an application version lifecycle policy that auto-deletes old versions by a MaxCount rule (keep the N most recent) or a MaxAge rule. Set DeleteSourceFromS3 to true to also remove the source bundles from S3, or false to keep them for compliance. Elastic Beanstalk never deletes a version currently deployed to any environment, and it applies the policy each time you create a new version.

Trap Worrying a lifecycle policy will remove an in-use version. Elastic Beanstalk protects versions deployed to any environment; DeleteSourceFromS3 only controls whether the S3 bundle is also deleted.

4 questions test this

A Python Lambda layer must put dependencies under a python/ directory at the .zip root

Lambda extracts layer contents into /opt, and the Python runtime searches /opt/python for imports, so a Python layer .zip must contain a top-level 'python/' directory with the libraries inside it. A layer whose modules sit at the archive root (or under any other folder) extracts to the wrong place and the function fails with 'Unable to import module' / ModuleNotFoundError even though the libraries are present.

Trap Zipping the dependencies at the layer root. Python only finds them under /opt/python, so they must be wrapped in a top-level python/ directory.

4 questions test this

Override a CloudFormation stack policy for one update with --stack-policy-during-update-body

A stack policy that denies updates to a protected resource (such as an RDS database) blocks even an authorized urgent change. To update the protected resource for a single operation without permanently editing the stack policy, run update-stack with --stack-policy-during-update-body (or --stack-policy-during-update-url) specifying a temporary policy that allows the needed action. The override applies only to that update; the original stack policy stays intact afterward.

Trap Calling SetStackPolicy to permanently loosen the policy for one urgent change. The temporary --stack-policy-during-update-body override leaves the original policy unchanged.

4 questions test this

CloudFormation stack policies gate on Update:Modify, Update:Replace, and Update:Delete

Stack policy statements use granular update actions: Update:Modify (in-place changes that keep the physical ID), Update:Replace (changes that recreate the resource with a new physical ID), and Update:Delete (removal). To protect a resource from being recreated or removed while still allowing harmless in-place edits, Deny Update:Replace and Update:Delete (or Allow Update:Modify and Deny Update:Replace). When a stack policy is set, all resources are protected by default, so guarding one resource means an Allow for the rest plus a targeted Deny.

Trap Denying all Update:* to protect a resource when in-place changes must still be allowed. Deny only Update:Replace and Update:Delete so Update:Modify edits still go through.

3 questions test this

Continuous CloudFormation drift detection uses the AWS Config managed rule plus EventBridge and SNS

For scheduled, continuous drift detection across stacks and accounts, enable the AWS Config managed rule cloudformation-stack-drift-detection-check: it runs DetectStackDrift, marking a stack COMPLIANT when IN_SYNC and NON_COMPLIANT when DRIFTED. Pair it with an EventBridge rule matching the Config compliance-change events to notify via SNS. This is the low-overhead automated answer, versus the manual CLI sequence detect-stack-drift then poll describe-stack-drift-detection-status then describe-stack-resource-drifts.

Trap Scripting repeated detect-stack-drift CLI calls for ongoing monitoring. The low-overhead continuous solution is the AWS Config managed rule with EventBridge and SNS.

4 questions test this

Protect versioned S3 artifacts with Object Lock, MFA Delete, and noncurrent-version lifecycle rules

On a versioning-enabled artifact bucket, choose the protection by requirement. Object Lock governance mode blocks deletes for most users but lets holders of s3:BypassGovernanceRetention override; compliance mode blocks deletes for everyone including root until retention expires, and supports legal holds. MFA Delete (enabled only by the root account via CLI/API) requires MFA to permanently delete a version or change versioning state. To prune by version, NoncurrentVersionExpiration with NewerNoncurrentVersions keeps the N most recent noncurrent versions and expires older ones after NoncurrentDays, and NoncurrentVersionTransition moves them to a cheaper class first.

Trap Reaching for governance mode when the rule says even the root account must never delete. That requires compliance mode; governance mode is overridable with the bypass permission.

5 questions test this

ECR enhanced scanning uses Amazon Inspector for continuous OS + language-package vulnerability scans

ECR basic scanning covers only operating-system packages. To scan both OS and programming-language dependencies (Python, Java, etc.) and to keep re-scanning images as new CVEs are published, enable enhanced scanning on the private registry with a continuous scan filter. It integrates with Amazon Inspector. Inspector emits scan-finding events to EventBridge, so an EventBridge rule to SNS gives automated alerts when new findings appear.

Trap Choosing basic scanning for language-dependency CVEs or ongoing monitoring. Basic scans only OS packages once; continuous OS+language scanning requires enhanced scanning via Inspector.

4 questions test this

What an artifact is, and how you package it

SAM and CloudFormation: building and deploying the artifact

Keeping configuration out of the artifact

Exam-pattern recognition: artifacts, SAM, and CloudFormation

Decision tree

Cheat sheet

References