Free Amazon Web Services DVA-C02 Practice Exam with Questions & Answers | Set: 5

The simplest and most efficient way to avoid hardcoding configuration such as a DynamoDB table name is to use Lambda environment variables. Environment variables are designed for runtime configuration and allow changing values without updating application code logic. The developer can store the table name in an environment variable (for example, TABLE_NAME) and read it from the runtime environment using the standard language method (such as os.environ in Python, process.env in Node.js, etc.).

This approach has very low operational overhead: updating the table name becomes a configuration change (in the Lambda console, IaC templates, or CI/CD pipeline) rather than a code change. It also keeps deployment packages stable and avoids unnecessary dependencies.

Option B is not suitable because /tmp is ephemeral storage that can be cleared between invocations and is not intended for configuration management.

Option C is heavier than necessary. Lambda layers are great for shared libraries and dependencies, but using a layer to store a single changing table name is awkward and forces a layer update and function reconfiguration when the value changes.

Option D does not solve the problem because a global variable is still set in the code. If the table name changes, the code must still be modified and redeployed.

Therefore, storing the table name in a Lambda environment variable is the most efficient solution.

The Immutable deployment method is the best choice when a company requires minimal downtime and automatic rollback in case of a failure. Here ' s why:

In Immutable deployments, a new set of instances is launched with the updated version. These instances are tested and validated before they replace the old instances. This ensures zero downtime and immediate rollback if the deployment fails.

All at once (A) causes downtime because the update replaces all instances simultaneously.

Rolling deployments (B) update a few instances at a time, but if a failure occurs midway, downtime or partial unavailability can happen.

Snapshots (C) are not a deployment strategy in Elastic Beanstalk.

Problem: Large bundle size increases Lambda deployment time.

Lambda Layers: Layers let you package dependencies separately from your function code. This optimizes the deployment package, making updates faster.

Modularization: Breaking down dependencies into layers improves code organization and reusability.

The requirement has two parts: (1) authenticate users with a third-party SAML IdP , and (2) after authentication, allow those users to access AWS services like Amazon S3 and DynamoDB. The AWS pattern for this is to federate the external identity into AWS and then exchange that identity for temporary AWS credentials .

Amazon Cognito identity pools are designed to provide AWS credentials to authenticated users (via AWS STS) so the users can call AWS services directly or through an application backend. Identity pools support federation with external identity providers, including SAML 2.0 . When a user authenticates with the third-party SAML IdP, the identity pool can accept the SAML assertion, map the user to an IAM role, and return temporary, scoped credentials (AccessKeyId/SecretAccessKey/SessionToken) associated with that role. Those credentials can be restricted using IAM policies to only the required S3 buckets, DynamoDB tables, and actions, satisfying least privilege.

Option A is incorrect because a Cognito user pool is primarily a user directory and OIDC/OAuth provider for application authentication; while user pools can integrate with SAML IdPs for federation, user pools alone do not directly issue AWS service credentials. The key requirement here is access to S3/DynamoDB, which is the role of an identity pool . Option C is not appropriate because IAM is not intended to provide end-user sign-up/sign-in for external users; it is for AWS identities and permissions. Option D is unrelated: CloudFront signed URLs control access to CloudFront-distributed content and do not authenticate users with SAML or provide AWS credentials.

Therefore, B meets both requirements: federate SAML authentication through a Cognito identity pool and provide temporary AWS credentials for accessing S3 and DynamoDB.

CloudFormation and Lambda Environment Variables:

CloudFormation is an excellent tool to manage infrastructure as code, including the log group resource.

Lambda functions can access environment variables at runtime, making them a suitable way to pass configuration information like the log group ARN.

CloudFormation Template Modification:

In your CloudFormation template, define the log group resource.

In the Lambda function resource, add an Environment section:

YAML

Environment:

Variables:

LOG_GROUP_ARN: !Ref LogGroupResourceName

Use code with caution.

content_copy

The !Ref intrinsic function retrieves the log group ' s ARN, which CloudFormation generates during stack creation.

Using the ARN in Your Lambda Function:

Within your Lambda code, access the LOG_GROUP_ARN environment variable.

Configure your logging library (e.g., Python ' s logging module) to send logs to the specified log group.

AWS CodeBuild integrates natively with AWS Secrets Manager , allowing secrets to be securely injected into build environments without being exposed in logs. When referenced using the secrets-manager mapping in the env section of buildspec.yml, CodeBuild automatically retrieves and decrypts the secret at runtime.

AWS documentation states that Secrets Manager provides encryption at rest using AWS KMS, fine-grained IAM access control, and automatic rotation support. Secrets retrieved this way are masked in build logs by default, satisfying the requirement that secrets do not appear in logs.

Parameter Store (Option C) can store encrypted values, but Secrets Manager is AWS’s preferred service for managing secrets, especially when rotation and auditing are required. Options B and D introduce unnecessary steps and higher operational overhead.

Therefore, Secrets Manager with CodeBuild environment variables is the most secure and operationally efficient solution.

The requirement is to rotate database credentials at least weekly . The AWS service that is purpose-built for storing and automatically rotating secrets is AWS Secrets Manager . Secrets Manager supports rotation schedules (including daily, weekly, or custom intervals) and integrates with supported databases through rotation Lambda functions. With rotation enabled, Secrets Manager can periodically generate a new password, update the secret value, and apply the new credential to the database user, while allowing applications to retrieve the current credential securely at runtime.

Option C matches this best practice: create a database user, store the username/password in a Secrets Manager secret, and enable rotation (daily rotation more than satisfies a weekly requirement). Applications on EC2 can retrieve the secret at startup or on a refresh interval using the AWS SDK, and can cache it according to best practices to reduce API calls, while still supporting rotation.

Option A (Parameter Store secure string) encrypts parameters, but Parameter Store does not provide the same managed secret rotation workflow for database credentials; rotating the KMS key is not the same as rotating the database password. Option B is not applicable as stated for RDS for Microsoft SQL Server: IAM database authentication is supported for specific engines (commonly MySQL and PostgreSQL) and is not the standard mechanism for SQL Server password rotation. Option D is insecure and operationally fragile: embedding long-lived credentials in user data and environment variables makes rotation difficult and increases exposure risk.

Therefore, the most secure and compliant configuration is C : store DB credentials in AWS Secrets Manager and enable automated rotation on an interval that meets or exceeds the weekly rotation requirement.

In AWS X-Ray, filter expressions can filter trace data based on indexed fields that X-Ray can query efficiently. Custom data can be added to segments in two main ways: annotations and metadata. The critical difference is that annotations are indexed and can be used for filtering, while metadata is not indexed and is intended for additional diagnostic context that you do not typically query on.

Therefore, if the developer wants user-specified custom attributes to be usable in X-Ray filter expressions, the developer should record those attributes as annotations in the segment document. Once recorded as annotations, the developer can write filter expressions that match annotation keys/values and return only the relevant traces.

Option B is incorrect because metadata is not indexed and cannot be used in filter expressions for trace search the same way annotations can.

Option C is incorrect because segment documents have a defined schema; adding arbitrary “new segment fields” is not the intended method for searchable custom attributes.

Option D is unrelated: sampling rules control which requests get traced in the first place. They are not used to filter returned results by custom attributes after traces are recorded.

By default, an Auto Scaling group uses EC2 status checks to determine instance health. EC2 status checks confirm that an instance is running and reachable at the infrastructure level, but they do not validate that the application is healthy behind the load balancer. In this scenario, the ALB is returning HTTP 502 errors and the target group shows instances as unhealthy, meaning the application is failing health checks (or not responding correctly). However, because the Auto Scaling group is using the default EC2 health check type, it does not consider these instances unhealthy for replacement.

AWS recommends configuring the Auto Scaling group to use ELB health checks when instances serve traffic behind an ALB or NLB. With ELB health checks enabled, Auto Scaling evaluates target health as reported by the load balancer target group. If the ALB marks an instance unhealthy, the Auto Scaling group will treat that instance as unhealthy and terminate and replace it automatically, restoring capacity with healthy targets.

Why the other options are insufficient:

Cooldown period (A) affects scaling timing, not health replacement logic.

Lifecycle hook changes (B) can help with initialization timing, but they do not cause Auto Scaling to replace instances based on ALB target health unless ELB health checks are enabled.

Health check grace period (D) delays health evaluation after launch, which can reduce premature replacement, but it still won’t replace instances based on ALB target group status unless the health check type is ELB.

Therefore, switching the Auto Scaling group health check type to Elastic Load Balancing (ELB) is the correct fix.

This solution will meet the requirements by allowing the developer to control what data is sent to X-Ray and CloudWatch from the application code. The developer can filter out any PII from the trace messages before sending them to X-Ray and CloudWatch, ensuring that no PII goes outside of the EC2 instances. Option B is not optimal because it will automatically instrument all incoming and outgoing requests from the application, which may include PII in the trace messages. Option C is not optimal because it will require additional services and costs to use Amazon Macie and AWS Lambda, which may not be able to detect and hide all PII from the trace messages. Option D is not optimal because it will use Open Telemetry instead of X-Ray, which may not be compatible with CloudWatch and other AWS services.

AWS Lambda is a service that lets developers run code without provisioning or managing servers. Lambda provides a local file system that can be used to store temporary files during invocation. The local file system is mounted under the /tmp directory and has a limit of 512 MB. The temporary files are accessible only by the Lambda function that created them and are deleted after the function execution ends. The developer can store temporary files that are less than 10 MB in the /tmp directory and access and modify them multiple times during invocation.

This solution will meet the requirements by using AWS Serverless Application Model (AWS SAM) templates and gradual deployments to automatically test the Lambda functions. AWS SAM templates are configuration files that define serverless applications and resources such as Lambda functions. Gradual deployments are a feature of AWS SAM that enable deploying new versions of Lambda functions incrementally, shifting traffic gradually, and performing validation tests during deployment. The developer can enable gradual deployments through AWS SAM templates by adding a DeploymentPreference property to each Lambda function resource in the template. The developer can set the deployment preference type to Canary10Percent30Minutes, which means that 10 percent of traffic will be shifted to the new version of the Lambda function for 30 minutes before shifting 100 percent of traffic. The developer can also use hooks to test the deployment, which are custom Lambda functions that run before or after traffic shifting and perform validation tests or rollback actions.

The solution that will meet the requirements is to add a new stage to the pipeline. Use AWS CodeBuild as the provider. Add the new stage before the stage that deploys code revisions to the test environment. Write a buildspec that fails the CodeBuild stage if any test does not pass. Use the test reports feature of CodeBuild to integrate the report with the CodeBuild console. View the test results in CodeBuild. Resolve any issues. This way, the developer can run the unit tests automatically during the CI/CD process and catch any bugs before deploying to the test environment. The developer can also use the test reports feature of CodeBuild to view and analyze the test results in a graphical interface. The other options either involve running the tests manually, running them after deployment, or using a different provider that requires additional configuration and integration.