DVA-C02 Deployment: 321 practice questions

12 of the 321 Deployment questions in the Certsqill DVA-C02 bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for DVA-C02? Take the free 5-min readiness check →

1. Use the AWS SAM CLI to invoke and step through: Which approach best meets this requirement?

1. Create a development API Gateway stage and configure its stage variables.

   API Gateway stages provide named deployment environments with stage-specific configuration and variables, but a stage is a deployed API environment rather than the local debugging mechanism required here.
2. Use the AWS SAM CLI to invoke and step through the function locally. ✓

   The AWS SAM CLI supports local testing and step-through debugging of serverless applications before deployment, directly satisfying the need to reproduce the event and inspect execution locally.
3. Extend a CloudFormation template with AWS SAM resources and deploy the transformed stack.

   AWS SAM templates provide infrastructure-as-code shorthand that is transformed into CloudFormation resources for deployment, but this approach does not itself provide the requested local step-through workflow.
4. Place shared debugging libraries in a Lambda layer and attach it to the function.

   Lambda layers package shared libraries or dependencies separately from function code and can be reused, but dependency packaging does not establish the requested local invocation and step-through debugging process.

The AWS SAM CLI is the appropriate choice because it supports local invocation and step-through debugging before deployment.

2. Create and review a CloudFormation change set before: Which approach should the team use?

1. Add a review action in CodePipeline before the deployment action.

   An approval action pauses a pipeline; a change set provides the resource-level preview to review.
2. Execute the stack update and depend on CloudFormation rollback if the update fails.

   Rollback normally returns a failed stack operation to its last known stable state, but it does not provide the requested pre-execution preview of replacements or deletions.
3. Deploy the SAM template because its transformation automatically previews resource replacements.

   SAM transforms infrastructure definitions; transformation alone is not an inspection of changes to an existing stack.
4. Create and review a CloudFormation change set before executing the stack update. ✓

   A change set previews the resource changes that the stack update would make, helping the team identify potential replacements or deletions before execution.

Use a CloudFormation change set because it previews the resource changes before the update executes.

3. Connect repository branches to separate Amplify Hosting: Which approach directly provides this mapping?

1. Define build phases and artifacts in a versioned CodeBuild buildspec.

   A CodeBuild buildspec defines build phases, commands, artifacts, and related settings; it does not establish separate deployment environments for repository branches.
2. Store frontend build settings in an amplify.yml repository file.

   The build file defines build settings; branch connections determine deployment environments.
3. Arrange source, build, test, and deploy actions as CodePipeline stages.

   CodePipeline stages automate ordered release actions and pass artifacts between them, but this describes workflow sequencing rather than mapping branches to separate environments.
4. Connect repository branches to separate Amplify Hosting environments. ✓

   Amplify Hosting can connect repository branches to separate continuous deployment environments, supporting isolated development and production workflows.

Amplify Hosting directly supports connecting repository branches to separate continuous deployment environments.

4. Invoke a Lambda alias targeting the approved version: Which approach best satisfies these requirements?

1. Invoke the function through an immutable Amazon ECR image tag.

   An ECR tag identifies an image; Lambda aliases provide the required function-version routing.
2. Invoke a Lambda alias targeting the approved version and configure a routing weight for a second published version. ✓

   The alias is stable while its weighted configuration directs a controlled share of invocations to the second version.
3. Deploy the approved code as an Elastic Beanstalk application version.

   Elastic Beanstalk application versions are labeled deployable source-code iterations for Elastic Beanstalk environments. They do not provide the Lambda alias behavior needed for a stable Lambda identifier and controlled traffic split.
4. Connect the integration deployment to a dedicated Amplify repository branch.

   Amplify branches can provide separate continuous deployment environments, but that mechanism applies to Amplify Hosting deployments rather than selecting a published Lambda version and shifting Lambda invocation traffic.

Use a Lambda alias targeting an immutable published version; aliases also support controlled traffic splitting between published versions.

5. Create a change set: Which approach should the developer use?

1. Bootstrap the environment before applying the template update.

   CDK bootstrapping provisions deployment resources such as an assets bucket and deployment roles for CDK deployments; it does not provide the requested preview of an existing stack update.
2. Apply the template update directly to the stack.

   Direct execution does not provide the change preview that reduces the risk of unintended replacement or deletion. The change-set workflow addresses that risk before execution.
3. Execute the update and use rollback only if it fails.

   CloudFormation normally rolls back a failed update to the last known stable state, but rollback protects consistency after failure rather than previewing intended changes beforehand.
4. Create a change set, review its resource changes, and execute it. ✓

   A CloudFormation change set previews the resource changes that a stack update would make before execution. Reviewing that preview helps identify unintended replacement or deletion before the update runs.

Use a CloudFormation change set to preview resource changes before executing the stack update.

6. Package the shared library in a Lambda layer and attach: Which solution best meets these requirements?

1. Package the shared library in a Lambda layer and attach the layer to the functions. ✓

   A Lambda layer packages shared libraries separately from function deployment code and can be reused across functions and versions.
2. Store the shared library as an encrypted Parameter Store SecureString and retrieve it at runtime.

   Parameter Store SecureString protects sensitive configuration with KMS, but it is a configuration mechanism rather than the supplied mechanism for separately packaging shared libraries.
3. Place the shared library in encrypted Lambda environment variables and reference it from each function.

   Environment-variable encryption protects variable values at rest, but environment variables are not the mechanism for packaging and reusing shared libraries.
4. Store the shared library as a Secrets Manager secret and retrieve it when each function starts.

   Secrets Manager is intended to store credentials and other secrets for runtime retrieval, not to package reusable function dependencies separately.

Use a Lambda layer because it separates shared libraries from function code and supports reuse across functions and versions.

7. Use the AWS SAM CLI to invoke and step through: Which approach best meets this requirement?

1. Use the AWS SAM CLI to invoke and step through the function locally with representative test events. ✓

   AWS SAM CLI supports local testing and step-through debugging of serverless applications before deployment, providing the requested short feedback loop for Lambda code and events.
2. Publish test events to EventBridge and route matching events to the Lambda function and other targets.

   EventBridge rules match event patterns and can send matching events to multiple targets, but publishing through the event bus does not satisfy the requirement for local invocation and step-through debugging.
3. Send test messages through an Amazon SQS event source mapping and make the handler tolerate duplicate deliveries.

   SQS event source mappings can deliver messages more than once, making idempotent handlers important, but this approach tests queue-triggered delivery rather than locally stepping through JSON events before deployment.
4. Configure API Gateway request validation to test required parameters and request-body schemas before invocation.

   API Gateway request validators can reject invalid requests at the API boundary, but this does not provide local step-through debugging of the Lambda implementation.

Use AWS SAM CLI local invocation and debugging to test representative Lambda events before deployment.

8. Use a CodeDeploy canary deployment configuration: Which deployment configuration best meets these requirements

1. Use a CodeDeploy all-at-once deployment configuration with CloudWatch alarms and automatic rollback.

   All-at-once does not provide an initial limited exposure period; it shifts traffic to the new Lambda version at once, despite the available alarm and rollback controls.
2. Use Route 53 weighted records to distribute traffic and monitor a CloudWatch alarm.

   Route 53 weighted routing can distribute traffic according to record weights, but the stated deployment mechanism is a CodeDeploy Lambda deployment, whose canary configurations directly provide the required staged traffic shift.
3. Use a CodeDeploy linear deployment configuration with CloudWatch alarms and automatic rollback.

   Linear shifting moves traffic in equal increments, so it does not match the requirement to expose only a small initial percentage and then shift the remainder after observation.
4. Use a CodeDeploy canary deployment configuration with CloudWatch alarms and automatic rollback. ✓

   A CodeDeploy canary exposes an initial percentage of Lambda traffic before shifting the remainder. CodeDeploy deployment groups can use CloudWatch alarms and automatic rollback for failed deployments.

A CodeDeploy canary initially exposes a small percentage of Lambda traffic, then shifts the remainder. CloudWatch alarms and automatic rollback provide the required failure response.

9. Publish each release as a new Lambda version and deploy: Which approach best meets this requirement?

1. Store each release under a unique Amazon ECR image tag and deploy the tag.

   Immutable ECR tags prevent an existing image tag from being overwritten, but this mechanism addresses ECR image artifacts rather than the Lambda versioning approach required here.
2. Connect each release to a separate Amplify Hosting branch.

   Amplify branch-based deployments provide separate continuous deployment environments for repository branches; they do not establish immutable Lambda function versions.
3. Publish each release as a new Lambda version and deploy that version. ✓

   A published Lambda version is an immutable snapshot of function code and configuration. Each release therefore has a stable artifact, and rollback can target an earlier published version.
4. Update $LATEST for each release and invoke $LATEST.

   $LATEST is mutable; subsequent changes replace the code invoked through that identifier.

Publish every Lambda release as a new immutable version and deploy that version.

10. Select the staging AWS CLI profile: Which approach best satisfies these requirements?

1. Select the staging AWS CLI profile, create a CloudFormation change set from the SAM template, review it, and execute it. ✓

   This selects the staging credentials and provides a pre-execution preview of the stack changes before applying the update. SAM is transformed into CloudFormation resources, and a change set previews the resource changes.
2. Select the staging profile and run sam validate before deploying the template directly.

   Template validation does not preview the changes to the existing stack.
3. Use the default AWS CLI profile, deploy the SAM template directly, and inspect the stack events afterward.

   This does not isolate the staging credentials and inspects results only after deployment. A CloudFormation change set is the mechanism supplied for previewing changes before execution.
4. Select the staging AWS CLI profile, deploy the SAM template directly, and rely on CloudFormation rollback if the update fails.

   Rollback normally returns a failed update to the last known stable state, but it occurs after failure and does not preview intended replacements or deletions. The requirement is to inspect a change set before execution.

Use the staging CLI profile and a CloudFormation change set generated from the SAM template. Review the proposed changes before executing the update.

11. Update each intended function configuration to reference: What should the developer do to adopt the new librar

1. Invoke the existing function versions again.

   Invocation does not change the layer version pinned in a function configuration.
2. Publish another layer version without updating the functions.

   Another published layer version still does not change existing function references.
3. Update each intended function configuration to reference layer version 4 and deploy the updated functions. ✓

   Functions reference a specific layer version ARN; publishing a new layer version does not update them automatically.
4. Update only an environment variable containing the library version.

   An environment variable does not change the configured layer version ARN.

Update the functions to reference the new layer version ARN.

12. CodePipeline stages containing ordered actions that pass: Which mechanism should the team use?

1. CodePipeline stages containing ordered actions that pass artifacts between stages ✓

   CodePipeline is designed for ordered release stages, with actions passing artifacts between stages. This directly supports repeatable promotion across environments.
2. AWS CLI named profiles selected with the --profile option for each environment

   Named profiles separate CLI configuration and credentials, but selecting a profile does not create an ordered release workflow or pass artifacts between stages.
3. A CodeBuild buildspec defining build phases, commands, and artifacts

   A buildspec defines CodeBuild execution details and artifacts, but it does not by itself orchestrate ordered promotion across multiple deployment environments.
4. A SAM template transformed into CloudFormation resources for deployment

   A SAM template describes serverless infrastructure for CloudFormation deployment. It does not provide the ordered workflow orchestration required to promote artifacts between environments.

Use CodePipeline stages and actions to orchestrate ordered artifact promotion across environments.

Other DVA-C02 domains

• Development with AWS Services — 424 questions →
• Security — 343 questions →
• Troubleshooting and Optimization — 238 questions →
• All 1326 DVA-C02 questions →