Back to AWS Certified Developer - Associate (DVA-C02)

Deployment

Prepare artifacts, test applications, automate testing, and deploy using CI/CD services (~24% of exam).

Covers preparing application artifacts including dependency management, directory structure organization, code repositories, resource requirements, and environment-specific configurations with AWS AppConfig. Also covers testing applications in development environments including deployed code testing, integration tests with mock APIs, development endpoints and API Gateway stages, stack updates to staging environments, and event-driven application testing. Additionally covers automating deployment testing including test events, API resource deployment, version management with Lambda aliases and container tags, IaC templates (SAM, CloudFormation), environment management, and Amazon Q Developer for automated tests. Finally covers CI/CD deployment including Lambda packaging, API Gateway stages and custom domains, IaC template updates, deployment strategies (blue/green, canary, rolling), version control, orchestrated workflows, and application rollbacks.
5 minutes 5 Questions

Deployment in AWS refers to the process of releasing and managing application code and infrastructure in the AWS cloud environment. For the AWS Certified Developer - Associate exam, understanding deployment strategies and services is crucial. **AWS Elastic Beanstalk** is a Platform-as-a-Service (P…

Concepts covered: Managing code dependencies, Environment variables in deployments, Lambda aliases, Configuration files management, Container image management, Infrastructure as Code (IaC), Amazon ECR (Elastic Container Registry), Application directory structure, Lambda deployment packaging, Code repositories for deployment, AWS CodeCommit, Resource requirements specification, Memory and CPU allocation, AWS AppConfig, Environment-specific configurations, Feature flags with AppConfig, Testing deployed code on AWS, Writing integration tests, Mocking external dependencies, Mock APIs for testing, API Gateway stages, Development endpoints, AWS SAM template deployment, Deploying to staging environments, Testing event-driven applications, Lambda test events, Creating application test events, JSON payloads for Lambda testing, API Gateway test payloads, Deploying API resources to environments, Container image tags for versioning, AWS Amplify branches, AWS Copilot environments, AWS SAM templates, AWS CloudFormation templates, Managing environments in AWS services, Amazon Q Developer for automated tests, Lambda deployment packages (ZIP), Lambda container images, API Gateway custom domains, API Gateway stage variables, Updating IaC templates, AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, Blue/green deployment strategy, Canary deployment strategy, Rolling deployment strategy, Linear deployment strategy, Git-based deployment triggers, Orchestrated deployment workflows, Application rollbacks, Version control with labels and branches, Runtime configuration for deployments, Staging variables in Lambda functions

Test mode:
Start practice test
DVA-C02 - Deployment Example Questions

Test your knowledge of Deployment

Question 1

A software development team at a logistics company is building a package tracking application using AWS Lambda and Amazon DynamoDB. They have implemented AWS AppConfig feature flags to manage a new real-time notification system. The team configured three feature flag variants: 'sms_only', 'email_only', and 'multi_channel'. They want 'multi_channel' to be assigned to enterprise customers who have 'accountType' set to 'enterprise' in their context, while other customers should receive variants based on a 50/50 percentage split between 'sms_only' and 'email_only'. After deploying the configuration, the team notices that enterprise customers are correctly receiving the 'multi_channel' variant, but non-enterprise customers are all receiving the 'sms_only' variant instead of the expected 50/50 distribution. The team confirms the configuration syntax is valid and deployment was successful. What should the team examine to identify why the percentage-based allocation is failing for non-enterprise customers?

Correct Answer: Verify that a consistent user identifier is being passed in the evaluation context, as the same identifier results in the same variant assignment due to deterministic hashing

The correct answer is to verify that a consistent user identifier is being passed in the evaluation context, as the same identifier results in the same variant assignment due to deterministic hashing.

AWS AppConfig feature flags use deterministic hashing when performing percentage-based variant allocation. This means that for a given user identifier, the system will always return the same variant. This is by design to ensure a consistent user experience - you don't want a user to flip between variants on each request.

The key insight here is that if the team is not passing a unique user identifier (or is passing the same identifier for all non-enterprise users, or no identifier at all), the deterministic hash will produce the same result every time, causing all users to receive the same variant ('sms_only' in this case). The 50/50 split only works correctly when different user identifiers are passed, allowing the hash function to distribute users across variants.

The other options are incorrect:

  • Checking the deployment strategy growth factor is not relevant here. The deployment strategy controls how quickly a new configuration is rolled out to hosts, not how percentage-based variant allocation works. The team already confirmed deployment was successful.

  • The configuration format (JSON vs YAML) does not affect percentage allocation functionality. AWS AppConfig supports both formats, and the team confirmed the configuration syntax is valid. Format choice does not impact how percentage splits are calculated.

  • The AppConfig Lambda extension polling interval has no relationship to variant calculation completion. The extension caches configuration data locally, and variant evaluation is a fast, synchronous operation that doesn't depend on polling timing. This would cause configuration staleness issues, not consistent single-variant assignment.

Question 2

A development team at a pharmaceutical company uses AWS Copilot to deploy their clinical trial management system. The team has environments named 'dev', 'test', and 'prod'. A new architect, Marcus, notices that deployments to the 'test' environment are taking significantly longer than expected. Upon investigation, he discovers that the 'test' environment is configured to use a NAT Gateway in a single Availability Zone, causing network bottlenecks during container image pulls from Amazon ECR. The infrastructure team has already provisioned a highly available networking setup with NAT Gateways in multiple Availability Zones in an existing VPC. Marcus needs to reconfigure the 'test' environment to leverage this existing VPC infrastructure to improve deployment performance and network resilience. The environment currently has two services deployed that must continue operating after the change. What is the most appropriate strategy for Marcus to address this networking configuration challenge using AWS Copilot?

Correct Answer: Delete the existing test environment, then create a new test environment using the --import-vpc-id flag to reference the pre-provisioned VPC with multi-AZ NAT Gateways, and redeploy the services

The correct approach is to delete the existing test environment and create a new one using the --import-vpc-id flag to reference the pre-provisioned VPC with multi-AZ NAT Gateways, then redeploy the services.

AWS Copilot does not support in-place modification of the underlying VPC infrastructure for an existing environment. The VPC configuration is a foundational infrastructure component that is determined at environment creation time. Once an environment is created with a specific VPC (either Copilot-managed or imported), changing to a different VPC requires recreating the environment.

The --import-vpc-id flag during 'copilot env init' allows you to specify an existing VPC that has already been provisioned outside of Copilot. This is the correct mechanism to use pre-existing networking infrastructure including VPCs with NAT Gateways in multiple Availability Zones.

The second option is incorrect because modifying the manifest.yml file to add a VPC ID will not work for an already-deployed environment. The VPC association is immutable after environment creation, and copilot env deploy cannot change the underlying VPC infrastructure.

The third option is incorrect because copilot env override is used for customizing CloudFormation templates with additional resources or modifications, but it cannot change the fundamental VPC association of an existing environment. VPC changes of this magnitude are not supported through overrides.

The fourth option is incorrect because there is no --override-vpc-id parameter for copilot env init. Additionally, copilot env init is used to create new environments, not modify existing ones, and there is no in-place VPC replacement capability in Copilot.

Question 3

A data analytics firm has deployed an AWS Glue development endpoint with 4 G.2X workers to develop ETL scripts for processing customer behavior data. The endpoint is attached to a Zeppelin notebook and resides within a VPC with a NAT Gateway. The development team successfully runs PySpark code that reads from S3 and writes transformed data back to S3. However, when attempting to write output data to an Amazon Redshift cluster located in the same VPC, the write operation fails with a connection refused error after 30 seconds. The Redshift cluster security group allows inbound traffic on port 5439 from the VPC CIDR range. The IAM role attached to the development endpoint has AmazonRedshiftDataFullAccess and AWSGlueServiceRole policies. The team verified that the Redshift cluster is operational and accessible from EC2 instances in the same subnet. What should the team investigate to resolve the Redshift connectivity issue from the development endpoint?

Correct Answer: Verify that the development endpoint is configured with the same VPC, subnet, and security group that allow communication with the Redshift cluster subnet

The correct answer is to verify that the development endpoint is configured with the same VPC, subnet, and security group that allow communication with the Redshift cluster subnet.

When an AWS Glue development endpoint is created within a VPC, it requires proper network configuration including VPC, subnet, and security group settings. The 'connection refused' error after 30 seconds is a classic symptom of network connectivity issues, not authentication or driver problems.

The key insight here is that even though the Redshift security group allows inbound traffic from the VPC CIDR range, the Glue development endpoint's security group must also allow outbound traffic to the Redshift cluster on port 5439. Additionally, the endpoint must be in a subnet that can route to the Redshift cluster's subnet. The fact that EC2 instances in the same subnet can connect to Redshift but the Glue endpoint cannot strongly suggests the endpoint may be configured with different network settings.

The second option about enhanced VPC routing and NAT Gateway bandwidth is incorrect because enhanced VPC routing affects how Redshift routes traffic for COPY/UNLOAD operations, not inbound JDBC connections. NAT Gateway bandwidth wouldn't cause a 'connection refused' error.

The third option about IAM permissions and Glue Connection is incorrect because the error is 'connection refused' which is a network-level issue, not an authentication or authorization error. IAM credential issues would result in different error messages related to authentication failures.

The fourth option about JDBC driver versions and Spark connector libraries is incorrect because driver or library issues would result in class not found errors or compatibility exceptions, not 'connection refused' network errors.

More Deployment questions
1647 questions (total)
Start 100 question test