DOP-C02 Flashcards — Free AWS Certified DevOps Engineer Professional DOP-C02 Study Cards

Upload the recipe to a custom cookbook repository and assign it to the 'Configure' lifecycle event in the stack settings.

In AWS OpsWorks, lifecycle events (such as Configure) are tied to layers, not individual instances. To run a custom recipe on all instances during the Configure event, you must upload the recipe to a custom cookbook repository (e.g., S3 or Git) and then assign that recipe to the Configure lifecycle event in the stack's layer settings. This ensures OpsWorks Chef runs the recipe on every instance in that layer whenever the Configure event fires (e.g., after scaling or instance state changes).

Configure the CloudFormation deployment action in CodePipeline with 'ActionMode' set to 'CREATE_UPDATE' and check the 'Rollback on failure' option.

The CloudFormation deployment action in CodePipeline supports a 'Rollback on failure' option when 'ActionMode' is set to 'CREATE_UPDATE'. When enabled, if the stack update fails, CloudFormation automatically rolls back the stack to the last known good state (the previously deployed stack). This directly addresses the team's requirement to revert to a stable state after a failed deployment due to a deprecated AMI.

Immutable update.

Immutable updates in AWS Elastic Beanstalk launch a completely new environment with the new application version. If the new environment fails health checks, Elastic Beanstalk automatically terminates it, leaving the original environment untouched. This ensures zero downtime and a safe rollback, which matches the requirement to keep the old environment intact if health checks fail.

Use predictive scaling with a scheduled scaling policy for known peak times.

Predictive scaling uses historical traffic data to forecast future demand and proactively adjust capacity before a spike occurs. This prevents the CPU from reaching critical levels that cause health check failures, ensuring the ALB always has healthy hosts. Scheduled scaling alone would not adapt to unexpected spikes, but predictive scaling combined with dynamic scaling provides both proactive and reactive resilience.

Deploy EC2 instances across multiple Availability Zones using an Auto Scaling group.

Deploying EC2 instances across multiple Availability Zones (AZs) using an Auto Scaling group is the most effective action because it eliminates the single point of failure at the AZ level. If one AZ experiences an outage, the Auto Scaling group automatically launches replacement instances in the remaining healthy AZs, ensuring application availability without requiring any application-level changes. This directly addresses the goal of improving resilience by leveraging AWS's fault-isolated infrastructure.

Use CloudWatch ALB metrics (HTTPCode_ELB_5XX_Count) and create a CloudWatch Alarm on the Sum statistic with a threshold based on total request count.

ALB automatically publishes the `HTTPCode_ELB_5XX_Count` metric to CloudWatch, and you can create a CloudWatch alarm using the `Sum` statistic over a 5-minute period. To detect when the error rate exceeds 5%, you need to combine this metric with the `RequestCount` metric in a math expression (e.g., `m1/m2*100 > 5`) or use a composite alarm, as the alarm threshold must be based on the ratio of 5xx errors to total requests, not just the raw count.

Increase the batch size in the CloudWatch agent configuration.

Increasing the batch size in the CloudWatch agent configuration reduces the number of HTTP API calls made to CloudWatch Logs, which lowers CPU overhead from frequent network I/O and serialization. The agent buffers log events and sends them in larger, less frequent batches, directly addressing high CPU consumption without discarding any log data.

Increase the task definition memory to 2048 MiB while keeping CPU at 512 units.

The application is experiencing OutOfMemoryError, indicating the current 1024 MiB memory allocation is insufficient. Increasing memory to 2048 MiB while keeping CPU at 512 units directly resolves the memory constraint without unnecessary CPU cost. ECS Fargate allows independent scaling of CPU and memory within valid combinations, and this change maintains a cost-effective approach by only increasing the resource that is actually constrained.

Check the security group and network ACL rules to ensure inbound traffic is allowed.

Since the instance is running, status checks pass, and the system log shows no errors, the issue is not with the operating system or underlying hardware. The most likely cause is a network-layer restriction, such as security group or network ACL rules blocking inbound traffic. Checking these rules is the correct next step because they control traffic at the instance and subnet levels, respectively, and misconfigurations here are a common cause of unreachability despite healthy instance status.

Attach an IAM role to the EC2 instance and use the instance profile to obtain temporary credentials from the instance metadata service.

Attaching an IAM role to the EC2 instance and using the instance profile allows the application to obtain temporary credentials from the EC2 instance metadata service (IMDS). These credentials are automatically rotated by AWS before they expire, and they are never stored on disk—they are fetched on-demand from the metadata endpoint (http://169.254.169.254/latest/meta-data/iam/security-credentials/). This satisfies both the requirement for automatic rotation and the prohibition against disk storage.

Modify the KMS key policy to include a condition that allows kms:Decrypt only if the SAML assertion contains the specific attribute.

KMS key policies are resource-based policies that can use IAM condition keys. To enforce a requirement based on a SAML assertion, you must first configure the IAM role's trust policy to map the SAML attribute to a session tag using sts:TagSession. Then, the KMS key policy can include a condition such as aws:PrincipalTag/attribute_name to allow kms:Decrypt only when that session tag matches the expected value. This ensures compliance at the key level, independent of S3 bucket policies. Note that saml:sub and other SAML condition keys are not supported in KMS key policies; they are only valid in IAM trust policies.

Configure Secrets Manager to automatically rotate the secret every 30 days using a Lambda rotation function, and have the application retrieve the secret using the Secrets Manager API.

AWS Secrets Manager natively supports automatic rotation of secrets using a Lambda function that updates both the secret in Secrets Manager and the password in the RDS MySQL instance. This solution meets the 30-day rotation requirement without modifying application code, as the application retrieves the current secret via the Secrets Manager API, which automatically handles versioning and caching.

Configure CodeBuild to cache dependencies in an Amazon S3 bucket.

Caching dependencies in an Amazon S3 bucket allows CodeBuild to reuse previously downloaded Maven/Gradle dependencies across builds, eliminating the need to re-download them each time. Since the codebase and dependencies are stable, this directly reduces the build time by avoiding repeated network transfers of large artifact repositories.

Create a separate pipeline for each allowed branch, with the approval step only in the production pipeline.

It enforces branch-based deployment at the pipeline level, ensuring that only changes from specific branches trigger the production pipeline with the approval step. This approach is secure and maintainable as it leverages AWS CodePipeline's native ability to trigger on branch events, avoiding custom logic or manual verification. By isolating production deployments to a dedicated pipeline, the team reduces the risk of unauthorized or untested code reaching production.

Configure a CodeCommit trigger that invokes an AWS Lambda function to validate file sizes and reject the push.

AWS CodeCommit supports custom triggers that invoke AWS Lambda functions on repository events, including pushes. By configuring a trigger for the 'push' event, a Lambda function can inspect each file in the push payload, check its size against the 50 MB threshold, and programmatically reject the push by returning an error response. This approach enforces the policy at the repository level without requiring client-side changes.