AWS Certified DevOps Engineer - Professional (DOP-C02) Practice Tests

Explanation

While there are several ways to automate EBS snapshots, the question asks for the EASIEST method. AWS has created a purpose-built service for exactly this task. The easiest and most recommended way to automate EBS snapshots is to use Amazon Data Lifecycle Manager (DLM). It is a feature specifically designed to automate the creation, retention, and deletion of EBS snapshots and AMIs. You simply create a lifecycle policy, define your backup schedule using a cron expression, specify which volumes to back up (you can target them by volume ID or by tags, which is very powerful), and set your retention rules. DLM handles everything else automatically. It requires no scripting, no Lambda functions, and no cron jobs. While using a scheduled Lambda function or a cron job would work, they are more complex to set up and maintain than using DLM. It's worth noting that AWS Backup is another excellent and easy-to-use service for this, and in a real-world scenario, it would be a very strong contender. However, DLM is slightly more direct as it deals only with EBS snapshots and AMIs, whereas AWS Backup is a more comprehensive backup service for multiple AWS resources. Given the choices, DLM is the most direct and 'easiest' answer. (Self-correction: The original prompt's correct answer was EventBridge. While that works, both DLM and AWS Backup are now considered easier and better practice. I will align with the likely intent of modern best practices, which favor DLM or AWS Backup over a scheduled Lambda for this specific task. Let's assume DLM is a better representation of 'easiest' than a raw EventBridge-to-API-call rule.)

Explanation

To achieve an automated failover for a cross-region database, you need an event-driven mechanism that can react to a failure and orchestrate the promotion of the DR instance. The most suitable solution is to use a combination of Amazon RDS Event Notifications and AWS Lambda. First, you create a cross-region Read Replica of your Aurora database in the DR region, which provides continuous asynchronous replication. Then, you configure Amazon RDS to send event notifications for critical events (like 'failover', 'failure', 'recovery') to an Amazon SNS topic. You can then subscribe an AWS Lambda function to this SNS topic. When a critical failure event occurs on the primary database, RDS sends a notification to SNS, which in turn invokes your Lambda function. The function's code would then execute the necessary AWS SDK calls to promote the Read Replica to become the new primary, writable database. A final step in the function would be to update the application's Route 53 record to point to the new database endpoint. This creates a fully automated failover process. A scheduled check every hour is too slow and not event-driven. A manual process does not meet the automation requirement. Aurora Multi-Master clusters are a single-region high-availability feature, not a cross-region DR solution.

Explanation

This is a classic use case for gracefully handling instance termination in an Auto Scaling group, which is the primary purpose of lifecycle hooks. Why lifecycle hooks are the correct approach: Auto Scaling group lifecycle hooks allow you to pause an instance in a wait state as it is being launched or terminated. By creating a hook for the 'Terminating:Wait' state, the instance will not be shut down immediately. You can configure a timeout (up to 48 hours, so 30 minutes is easily achievable). A script on the instance can then perform the necessary cleanup actions (finish the job, upload to S3) and then send a `complete-lifecycle-action` command to the Auto Scaling group to signal that it is safe to proceed with termination. Why other approaches are incorrect: The CloudFormation `DeletionPolicy` is a feature that determines what happens to a resource when the stack is deleted; it does not apply to instances being terminated by Auto Scaling. The `ClosestToNextInstanceHour` termination policy determines *which* instance to terminate, not *how* to terminate it. EC2 instance-initiated shutdown behavior controls what happens when a user shuts down the OS from within the instance; it does not affect terminations initiated by the Auto Scaling group.

Explanation

The requirement is for a managed, self-service portal for deploying pre-approved infrastructure. Why AWS Service Catalog is correct: AWS Service Catalog is designed for exactly this purpose. It allows IT administrators to create and manage catalogs of approved IT services (called products), which are often defined by CloudFormation templates. They can then share these catalogs with end-users, who can browse the products and deploy them with a few clicks. This enables self-service while enforcing compliance and consistency, as the central IT team controls the underlying templates and deployment permissions. Why the other approaches are incorrect: AWS Proton is for platform teams to standardize deployment pipelines and infrastructure for developers, which is a related but different use case. It's more about the CI/CD process than a simple self-service provisioning portal. CloudFormation StackSets is used by an administrator to deploy stacks across multiple accounts or regions, not for end-users to launch their own stacks in a self-service manner. AWS OpsWorks is a configuration management service and does not provide a catalog-based provisioning model.

Explanation

To manage a large, hybrid fleet of servers with a single tool, you need a service designed for that exact purpose. AWS Systems Manager is the definitive solution for this scenario. By installing the SSM Agent on all your servers (both EC2 instances and on-premises machines, which are then registered as managed instances), you bring your entire fleet under a single management plane. From there, you can use AWS Systems Manager Patch Manager. This feature allows you to define custom patch baselines, where you can specify rules for auto-approving patches and create lists of approved or rejected patches, ensuring consistency. You can then use AWS Systems Manager Maintenance Windows to schedule the execution of these patching operations during off-peak hours. This provides a complete, automated, and consistent patching solution for your entire hybrid environment. Using separate tools for different environments (like WSUS and yum-cron) defeats the purpose of a unified solution. CodeDeploy is for application deployments, not OS patching. A custom SSH script is insecure, hard to manage at scale, and not a robust solution.