AWS Certified DevOps Engineer - Professional Free Sample Questions

The AfterAllowTestTraffic hook is specifically designed for running tests in a blue/green deployment after the test listener is active but before production traffic is shifted. Triggering a Lambda function from this hook allows for external test suites to be run. If the Lambda function exits with an error (non-zero exit code), CodeDeploy will automatically initiate a rollback, preventing the faulty green environment from serving production traffic. BeforeInstall is too early in the lifecycle. AfterInstall happens before the task set is stable and ready for testing. BeforeAllowTraffic is for tasks just before the test listener traffic is allowed, which is also too early for end-to-end tests.

AWS Config conformance packs are designed for this exact purpose. They allow you to package a collection of AWS Config rules and remediation actions that can be easily deployed as a single entity across an entire organization from the management account. This is more scalable and maintainable than managing individual StackSets for EventBridge rules and Lambda functions. Service-managed SCPs can prevent certain actions but cannot remediate existing resources. A single Lambda function in the management account would require complex cross-account permissions to remediate resources in member accounts.

In AWS Step Functions, the Retry block allows for fine-grained control over error handling. To achieve an increasing delay that is less aggressive than the default exponential backoff (which has a BackoffRate of 2.0), you must specify a BackoffRate between 1.0 and 2.0. A value of 1.5 will cause the interval to increase by 50% after each attempt, which is less aggressive than the default doubling. A BackoffRate of 2.0 is the default exponential backoff. Not specifying a BackoffRate also defaults to 2.0. ErrorEquals: ["States.TaskFailed"] is appropriate for catching failures within the Lambda function execution.

Standard SQS queues provide at-least-once delivery, which can result in duplicate messages, especially during consumer failures. FIFO queues provide exactly-once processing (within a 5-minute deduplication interval) and preserve message order. By enabling content-based deduplication, SQS will use a SHA-256 hash of the message body to generate the message deduplication ID, automatically preventing duplicate messages from being sent. This is the most direct and architecturally sound way to solve the duplicate processing issue at the source without complex application logic. While making the Lambda idempotent is a good practice, changing the queue to FIFO is a more robust solution provided by the infrastructure itself.

Amazon S3 caching mode is the best choice here. It allows you to store a cache in an S3 bucket. At the beginning of a build, the cache is downloaded to the local build environment. At the end, the cache is re-uploaded with any changes. This persists dependencies between builds. Local caching (source cache) reuses the Docker container on the build host, which can lead to stale file issues if not managed carefully, violating the 'clean environment' requirement. The Docker layer cache option is for caching layers of a Docker image being built, not general dependencies. 'No cache' is the current slow behavior.

This problem requires advanced CloudWatch functionality. A simple alarm will include all instances. A Lambda function adds complexity. The most elegant solution is to use CloudWatch metric math. By creating an expression like AVG(IF(AGE(m1) > 600, m1)), you can create a dynamic alarm. The METRICS() function can be used to select all CPUUtilization metrics from the Auto Scaling group. The AGE() function returns the age of a metric's latest datapoint in seconds. The IF statement then includes only metrics older than 600 seconds (10 minutes) in the final AVG calculation. This allows a single alarm to dynamically adjust to the fleet while ignoring new instances for a specified period.

This is true. For EC2/On-Premises deployments, AWS CodeDeploy requires the Application Specification File (AppSpec file), which must be named appspec.yml or appspec.yaml, to be located in the root of the directory structure of an application's source code.

Service Control Policies (SCPs) are the correct tool for proactively enforcing permissions boundaries across an entire AWS Organization. By creating an SCP with a Deny effect for the ec2:CreateVolume action and using a condition key aws:RequestTag/ebs:VolumeType with StringNotEquals for gp3, you can prevent the creation of any non-compliant EBS volumes before they are even provisioned. This is a proactive control. AWS Config is a detective control; it detects non-compliance after the resource is created. CloudFormation hooks are specific to CloudFormation and won't prevent manual creation. IAM permissions boundaries apply to entities but are not as broad as SCPs for organizational enforcement.

The correct workflow for deploying a SAM application with a manual review step is as follows: 1. Source: Get the SAM template and code. 2. Build: Use AWS CodeBuild to run sam package. This command packages the application artifacts, uploads them to S3, and produces a new template file (packaged.yaml) with S3 references. 3. Deploy (Create Change Set): Use the AWS CloudFormation provider in CodePipeline with the action CREATE_CHANGESET. This uses the packaged.yaml to create a change set, which shows the proposed changes without applying them. 4. Manual Approval: A manual approval gate is inserted for review. 5. Deploy (Execute Change Set): After approval, use another AWS CloudFormation action with EXECUTE_CHANGESET to apply the previously created changes.