How to pass the AWS DevOps Professional Certification exam with a 100% score

A global logistics firm operating about 320 AWS accounts is using AWS Organizations with all features enabled and has grouped accounts into several organizational units. The company requires a standard set of IAM roles to exist in every newly created account and wants organization-wide CloudTrail logging enforced. The implementation must automatically apply these settings to new accounts and remove them when an account leaves the organization, while keeping operational effort as low as possible. What should the DevOps team do?

• ❏ A. AWS Control Tower

• ❏ B. Create an EventBridge rule in the management account that detects new account creation and invokes a Lambda function to configure CloudTrail and create the IAM roles

• ❏ C. Use AWS CloudFormation StackSets with service-managed permissions from the management account to deploy a CloudTrail trail and required IAM roles to target OUs, enabling automatic deployments to new accounts and automatic stack instance removal when accounts are closed or leave

• ❏ D. Enable an organization trail for all member accounts and create a single IAM role to be shared across the organization

A browser-only expense estimator built with React and Tailwind CSS currently runs in a company data center and is being moved to AWS. The app consists solely of static assets and has no backend services. Because the tool may display confidential budget numbers, the team must ensure HTTP responses include headers such as X-Content-Type-Options, X-Frame-Options, and X-XSS-Protection to align with OWASP guidance. What is the most appropriate approach to implement this on AWS?

• ❏ A. Host the static site on Amazon S3 website hosting and try to add the security headers using an S3 bucket policy

• ❏ B. Serve the S3 website through Amazon CloudFront and configure Origin Custom Headers to include the OWASP headers

• ❏ C. Host the site on Amazon S3 and put Amazon CloudFront in front, then attach a CloudFront response headers policy to inject the required security headers

• ❏ D. Host on Amazon S3 behind CloudFront and use a Lambda@Edge origin-response function to set the security headers

A nationwide retail brand is moving its e-commerce platform to AWS with the web tier on Amazon EC2 and the data tier using PostgreSQL. The site accepts orders at all hours so downtime must be kept to a minimum, and the solution must tolerate failures across the full stack including the database. Marketing expects heavy surges during limited-time drops, and teams are worried about database performance during these peaks. Security also requires that the workload be continuously scanned for vulnerabilities. Which architecture should be implemented to satisfy these requirements?

• ❏ A. Deploy a Multi-AZ Auto Scaling group with an Application Load Balancer, back the data tier with Amazon Aurora configured for multi-master to improve throughput, and use Amazon Macie for automatic security assessments

• ❏ B. Run EC2 instances in a Multi-AZ Auto Scaling group behind an Application Load Balancer, choose RDS for PostgreSQL in a multi-master setup for HA to boost performance, and use Amazon Inspector for continuous assessments

• ❏ C. Place the EC2 fleet in a Multi-AZ Auto Scaling group behind an Application Load Balancer, use Amazon Aurora with multi-master writers for higher throughput and high availability, and enable Amazon Inspector for ongoing vulnerability scans

• ❏ D. Use a Multi-AZ Auto Scaling group of EC2 instances with an Application Load Balancer, deploy Amazon Aurora with multi-master writers for scale, and enable Amazon GuardDuty for automatic vulnerability scanning

A platform engineer at Solstice Media oversees many AWS accounts in AWS Organizations and must ensure that every current and future Amazon CloudWatch Logs log group across the organization continuously streams to an Amazon S3 bucket in a centralized audit account with minimal ongoing effort. What solution should be implemented to achieve this across accounts?

• ❏ A. Schedule recurring CloudWatch Logs export tasks in each account to deliver log data to the central S3 bucket, triggered periodically by Amazon EventBridge

• ❏ B. Use AWS DataSync to copy log files from CloudWatch Logs to the S3 bucket in the audit account and run tasks daily for all log groups

• ❏ C. Configure subscription filters on all log groups to stream to Amazon Data Firehose and set the delivery stream to write to the S3 bucket in the audit account, with an EventBridge rule invoking an AWS Lambda function that calls PutSubscriptionFilter when CreateLogGroup events occur

• ❏ D. Attach a CloudWatch Logs subscription that sends data directly to an S3 bucket in each account and use a Lambda function to attach the subscription to new log groups

A media analytics startup, NovaStream Media, runs its customer portal on Amazon EC2 with deployments handled by AWS CodeDeploy. The application uses Amazon RDS for PostgreSQL for transactional data and Amazon DynamoDB to persist user session state. As the platform engineer, how should the application obtain secure access to both the RDS database and DynamoDB?

• ❏ A. Put both the RDS password and supposed DynamoDB credentials in AWS Secrets Manager and grant the EC2 instance role permission to read the secrets

• ❏ B. Keep IAM user access keys and the RDS password in Secrets Manager and let the EC2 instance role retrieve them

• ❏ C. Store the RDS database credentials in AWS Secrets Manager and attach an EC2 instance profile that can read that secret and call DynamoDB APIs

• ❏ D. Use AWS Systems Manager Parameter Store SecureString for both the RDS credentials and DynamoDB, and allow the instance role to read those parameters

Orion FinTech has a Platform Engineering team and a Security team that manage separate layers of its AWS environment. They use AWS CloudFormation to provision resources across 12 AWS accounts, with AWS Config enabled for governance. The Security team is responsible for operating system hardening and patches, while the Platform team manages application dependencies and deployments. The Platform team must always launch EC2 instances with the newest approved hardened AMI during CloudFormation-based deployments. What is the most scalable way to integrate these workflows so new stacks automatically pick up the latest AMI without tightly coupling the teams?

• ❏ A. Have the Security team publish AMI IDs to an encrypted S3 object from a CloudFormation-created CodePipeline and have the Platform team read the object location via a cross-stack export to obtain the latest AMI ID at deploy time

• ❏ B. Build AMIs with EC2 Image Builder and tag the latest image, then have the Platform team configure CloudFormation to look up the AMI by tag during stack creation

• ❏ C. Use a CloudFormation stack that creates a CodePipeline to build hardened AMIs and write the current AMI ID to AWS Systems Manager Parameter Store, and have the Platform team resolve that parameter in their templates using an SSM dynamic reference to always launch the latest image

• ❏ D. Ask the Security team to maintain a nested stack that includes both OS and application templates and trigger stack updates whenever application code changes

A fast-growing media sharing platform at Aurora Lens Ltd. runs a dynamic Node.js application on five Amazon EC2 web servers. It stores sessions in an Amazon DynamoDB table and saves uploaded photos in an Amazon S3 bucket. An AWS Lambda function processes each upload before the object is written to S3. To handle surges, the team manually added eight more EC2 instances, but each new server needed about 45 minutes to download libraries and complete configuration before serving traffic. What approach provides high resilience and availability while also shortening the provisioning time for future web servers?

• ❏ A. Migrate to Amazon ECS with the Fargate launch type, define a task for the Node.js service with all dependencies, enable DynamoDB auto scaling, front it with an Application Load Balancer, and map the domain in Route 53 to the load balancer

• ❏ B. Use EC2 Auto Scaling with a launch template that installs the application via user data on boot across multiple Availability Zones behind an Application Load Balancer, turn on DynamoDB Auto Scaling, and point the DNS name in Route 53 to the load balancer

• ❏ C. Deploy the app with AWS Elastic Beanstalk using a multi Availability Zone environment behind a load balancer, and launch instances from an AWS Systems Manager Automation built custom AMI that includes all required components; enable DynamoDB Auto Scaling and update Route 53 to target the Beanstalk load balancer

• ❏ D. Run a Spot Fleet with a target capacity of 24 instances behind an Application Load Balancer, route the domain through Route 53, and raise the DynamoDB read and write capacity units manually

Norwood Labs is moving a Go service from its data center to AWS and wants genuine blue/green releases so two identical stacks run at the same time while traffic can be shifted for A/B validation with minimal operational burden. The team prefers a managed approach rather than assembling custom orchestration from scratch. What should the DevOps engineer implement to best meet these goals?

• ❏ A. Create an AMI-based workflow on Amazon EC2 using a launch template, an Auto Scaling group, and an Application Load Balancer, then perform instance refreshes on each release

• ❏ B. Use AWS App Runner connected to an Amazon ECR repository and enable automatic deployments

• ❏ C. Deploy on AWS Elastic Beanstalk for the Go platform, upload the application bundle to Amazon S3, and use Elastic Beanstalk environment swap for blue/green deployments

• ❏ D. Store build outputs in AWS CodeArtifact and use AWS CodeDeploy to push to an EC2 fleet behind an Application Load Balancer

The operations team at Orion Media wants an alert through Amazon SNS only when an AWS Glue job named orders-transform-v3 fails on its final retry attempt. As the DevOps engineer, how should you design this so that only those retry-failure events generate notifications?

• ❏ A. Create an EventBridge rule for AWS Glue job state changes and set an SNS topic as the target using an event pattern intended to match retry failures

• ❏ B. Use the AWS Personal Health Dashboard with a scheduled Lambda poller that posts to SNS when a Glue retry fails

• ❏ C. Configure an EventBridge rule for AWS Glue job run events with a Lambda target that inspects the event details for a failed final attempt and then publishes to SNS

• ❏ D. Re-orchestrate the job in AWS Step Functions and have the workflow send an SNS message if the final retry fails

At BrightWave Logistics, a platform engineer must deploy an application using AWS CloudFormation, but their IAM permissions do not allow creating several resources defined in the template. What approach enables the engineer to launch the stack with the minimum necessary privileges?

• ❏ A. Create an AWS CloudFormation service role with the necessary permissions and set it on the stack; use it for deployments

• ❏ B. Create an AWS CloudFormation service role with full administrative permissions, attach it to the stack, and allow iam:PassRole only when a ResourceTag matches

• ❏ C. Create an AWS CloudFormation service role scoped to the needed actions, associate it with the stack, and grant the engineer iam:PassRole to let CloudFormation assume that role during deployments

• ❏ D. Create an AWS CloudFormation service role with required permissions and add an aws:SourceIp condition listing developer IPs; associate it to the stack and grant iam:PassRole

All DevOps questions come from certificationexams.pro and my Certified DevOps Engineer Udemy course.

A platform engineer at Vega Retail is launching a payments API running on an Amazon Aurora MySQL-Compatible Multi-AZ cluster in ap-southeast-2, with a cross-Region read replica in us-west-2 for disaster recovery. The team targets a recovery time under 12 minutes and wants automatic promotion of the replica and seamless endpoint updates so the application can reconnect without redeployment. Which approach enables this automated promotion and endpoint switch?

• ❏ A. Create an Amazon EventBridge rule that detects Aurora failure and directly modifies a CloudFormation template to promote the replica, then run an AWS Lambda function to apply the change set and repoint the application

• ❏ B. Store the Aurora writer endpoint in AWS Systems Manager Parameter Store; use an Amazon EventBridge rule for RDS failure events to invoke an AWS Lambda function that promotes the cross-Region replica and updates the Parameter Store value; have the application read the endpoint from Parameter Store on reconnect

• ❏ C. Keep the endpoint in AWS Secrets Manager, subscribe an Amazon SNS topic to RDS failure notifications from AWS CloudTrail, and run an AWS Lambda function to promote the replica and update the secret while the app fetches fallback values from Parameter Store

• ❏ D. Configure Amazon Route 53 health checks and DNS failover between the primary Aurora endpoint and the cross-Region reader endpoint to move traffic automatically during outages

PolarByte Games runs a plugin-enabled backend API on Amazon ECS with Fargate. The service was created with the platform version set to LATEST, which resolved to 1.3.0 at launch, and a new 1.4.0 release adds support for the Splunk log driver the team wants to use. In the AWS Management Console, how should they update the service so running tasks relaunch on the newer Fargate platform without changing the image or task definition content?

• ❏ A. Edit the task definition to include the new platform version ARN, then update the service

• ❏ B. Enable automatic Fargate platform upgrades for the cluster

• ❏ C. In the ECS service, keep Platform version set to LATEST and choose Force new deployment to restart tasks on the newer runtime

• ❏ D. Create a new ECS service using platform version 1.4.0 and shift traffic with CodeDeploy blue/green

A regional nonprofit deployed a web portal to collect county household health surveys. The submissions include PII and are saved as encrypted objects in an Amazon S3 bucket. Object references are stored in a DynamoDB table named SurveyIndex. S3 server access logs and AWS CloudTrail are enabled and retained for 180 days to record object access. The security team needs to confirm that access to sensitive records meets compliance requirements and receive alerts for potential unauthorized access or accidental data exposure. Which AWS service should they use?

• ❏ A. Amazon GuardDuty

• ❏ B. AWS Security Hub

• ❏ C. Amazon Macie

• ❏ D. Amazon Inspector

The platform team at a regional healthcare analytics provider operates roughly 220 Amazon EC2 instances across two AWS Regions, with a mix of Windows Server and several Linux distributions. They need a secure, centrally managed, and auditable patching approach to satisfy compliance while keeping operational effort to a minimum. Which approach should they use on AWS to achieve this with minimal overhead? (Choose 2)

• ❏ A. Enable CloudFormation to automatically patch operating systems for all stacks and rely on AWS Config for audit reporting

• ❏ B. Use the AWS-RunPatchBaseline SSM document to enforce approved patch baselines across the fleet

• ❏ C. Standardize on native OS package managers and approval workflows on each host, with AWS Config for compliance checks

• ❏ D. Install the AWS Systems Manager Agent on every instance, validate patches in staging, then schedule patching through Systems Manager Maintenance Windows with approvals

• ❏ E. Use the AWS-ApplyPatchBaseline SSM document to patch Windows and Linux instances from the same baseline

NorthPoint Media, a global streaming firm, uses a hub-and-spoke multi-account model on AWS where a shared production account hosts Amazon EC2 instances for several internal divisions. A single division might operate two or more member accounts that interact with resources in the production account. Over the past 90 days, engineers from one division accidentally terminated EC2 instances that belonged to another division. The platform team needs a multi-account governance approach so only the division that owns a resource can terminate its own EC2 instances and related assets. What should they implement?

• ❏ A. Use a centralized AWS Config aggregator with AWS Control Tower and Customizations for AWS Control Tower to restrict EC2 termination per division

• ❏ B. Enable EC2 termination protection on all instances and route termination requests through AWS Systems Manager Change Manager approvals

• ❏ C. Use AWS Organizations with OUs and a per business unit IAM role in the production account that allows TerminateInstances only on resources it owns, assumed via cross-account trust

• ❏ D. Create an SCP in the production account via AWS Service Catalog that permits business-unit-specific termination actions and attach it to the appropriate OUs

A regional credit union uses AWS CloudFormation to manage a three-tier application, with customer transactions stored in an Amazon RDS for MySQL DB instance configured for Multi-AZ. Leadership wants to move to the newest MySQL major version with the least possible disruption to users. What should the DevOps engineer do through CloudFormation to upgrade the database while keeping downtime to a minimum?

• ❏ A. Enable AutoMinorVersionUpgrade and create a matching RDS Read Replica before running Update Stack

• ❏ B. AWS Database Migration Service

• ❏ C. Set the EngineVersion in AWS::RDS::DBInstance to the target MySQL major version, provision a like-for-like Read Replica in a separate stack first, then perform an Update Stack to apply the change with a quick cutover

• ❏ D. Modify the DBEngineVersion property and run Update Stack, then add a read replica and update the stack again

A DevOps engineer at Nova Retail is investigating an AWS CodeDeploy rollout to a deployment group of Amazon EC2 instances. For deployment d-47ABCD12, every lifecycle event shows Skipped and no application revision was installed on the instances. What are the most likely causes of this behavior? (Choose 2)

• ❏ A. The IAM user who triggered the deployment does not have sufficient permissions in CodeDeploy

• ❏ B. The target EC2 instances are missing an IAM instance profile that grants the CodeDeploy agent required access

• ❏ C. The deployment group is configured to target instances by tags instead of an Auto Scaling group

• ❏ D. The EC2 instances cannot reach CodeDeploy public endpoints because they have no egress path through a NAT gateway or internet gateway

• ❏ E. The EC2 instances must be explicitly registered with a CodeDeploy endpoint before they can receive deployments

A media analytics startup named LumaMetrics often finds that a few Amazon EC2 Windows servers become unreachable or fail to boot, and restoring access requires many manual steps. The platform team must implement an automated remediation in their VPC that can repair instances that lose connectivity because of incorrect network settings, broken RDP, restrictive firewalls, or similar issues, with recovery targeted within 15 minutes. The approach should also use the aws.trustedadvisor event source to watch best-practice checks and surface findings. What should the team implement?

• ❏ A. Orchestrate AWS Config with Session Manager, CloudWatch, Lambda, and Run Command to detect issues and repair unreachable EC2 instances

• ❏ B. Use AWS Trusted Advisor to automatically resolve performance and security findings and recover EC2 instances

• ❏ C. Run EC2Rescue with AWS Systems Manager Automation using the AWSSupport-ExecuteEC2Rescue document and monitor best practice checks via the aws.trustedadvisor event source

• ❏ D. Configure EC2 Auto Recovery by creating CloudWatch alarms on instance status checks to reboot or recover failed instances

A digital publisher, Northwind Media, needs an automated control that shuts down any Amazon EC2 instance that receives a manual OS login within 12 hours of the login. All workloads are launched by EC2 Auto Scaling with launch templates, and the unified Amazon CloudWatch agent is configured on every instance to stream system logs to CloudWatch Logs. How should a DevOps engineer implement this automation?

• ❏ A. Create a CloudWatch alarm that triggers on AWS API call events in CloudTrail, send the alarm to an Amazon SQS queue, and run an AWS Lambda function from the queue to terminate instances that generated the login event

• ❏ B. Create a CloudWatch Logs subscription filter that sends matching log events to an AWS Lambda function, tag the instance that produced the login entry, and use an Amazon EventBridge scheduled rule to invoke a second Lambda function hourly to terminate tagged instances

• ❏ C. Create a CloudWatch Logs subscription filter that sends events to AWS Step Functions, use the state machine to tag the resources that produced the login entry, and add an EventBridge rule that runs daily to invoke a Lambda function to terminate instances with that tag

• ❏ D. Configure an AWS Config custom rule to detect SSH or RDP logins from instance system logs and invoke an SSM Automation runbook that terminates the instance

A regional insurance firm operates an Oracle Real Application Clusters database in its data center and plans to move it to AWS. The platform lead asked the DevOps team to automate operating system patching on the servers that will run the database and to implement scheduled backups with roughly 60 days of retention to meet disaster recovery objectives. What is the simplest approach to achieve these goals with minimal engineering effort?

• ❏ A. Migrate the database to Amazon Aurora, enable automated backups, and rely on Aurora maintenance windows for patching

• ❏ B. Rehost the Oracle RAC database on EBS-backed Amazon EC2, install the SSM agent, use AWS Systems Manager Patch Manager for OS patches, and configure Amazon Data Lifecycle Manager to schedule EBS snapshots

• ❏ C. Move the RAC database to Amazon EC2 and trigger CreateSnapshot with an AWS Lambda function on an Amazon EventBridge schedule, and use AWS CodeDeploy and AWS CodePipeline to manage patching

• ❏ D. Move the on-premises database to Amazon RDS for Oracle with Multi-AZ and let RDS handle backups and host patching

All DevOps questions come from certificationexams.pro and my Certified DevOps Engineer Udemy course.

Northwind Outdoors operates a hybrid environment where its on-premises data center connects to six AWS VPCs through AWS Transit Gateway. The platform runs about thirty-five microservices spread across those VPCs and the data center. Pulling logs from each service during an outage is slow and impedes recovery. The team needs a centralized way to gather OS and application logs from both on-prem servers and Amazon EC2 instances, and they want an easy, low-cost way to query the data for audits and troubleshooting with minimal setup effort. What should the team do?

• ❏ A. Install the CloudWatch agent only on EC2 instances, export logs from CloudWatch to a central S3 bucket using console batch export, and analyze with a custom Amazon EMR cluster

• ❏ B. Deploy the CloudWatch Logs agent on all servers and EC2 instances, aggregate logs on an on-premises NAS, and build a self-managed ELK stack for analytics

• ❏ C. Install the unified CloudWatch agent on all on-premises servers and EC2 instances to send logs to CloudWatch Logs, subscribe the log groups to Kinesis Data Firehose delivering to a central Amazon S3 bucket, invoke AWS Lambda from S3 events for anomaly checks, and query with Amazon Athena

• ❏ D. Use the CloudWatch agent across all nodes to send logs to CloudWatch Logs and stream them to Amazon OpenSearch Service for searches and dashboards

At Lumen FinTech, a platform team maintains a serverless backend made up of five independent AWS Lambda functions. A DevOps engineer built a delivery pipeline in AWS CodePipeline with AWS CodeBuild that builds, tests, packages, and deploys each function one after another. An Amazon EventBridge rule triggers the pipeline whenever changes are pushed to the source repository. During pre-release testing, the engineer finds the pipeline takes too long to finish. What should be changed to speed up the pipeline without altering functionality?

• ❏ A. Increase the CodeBuild projects to a larger compute type with additional vCPUs

• ❏ B. Use CodeBuild batch builds with a build graph to order builds by dependencies

• ❏ C. Configure the CodePipeline stage to run actions for each Lambda function in parallel by assigning the same runOrder

• ❏ D. Run CodeBuild inside a VPC and use dedicated hosts to increase throughput

BlueLeaf Insights provisions AWS resources with AWS CloudFormation across several accounts, and the compliance team worries that passwords and API tokens might show up in stack events or descriptions during deployments. The DevOps engineer must apply measures so templates can resolve secrets at deploy time without revealing their values in the console, CLI, or logs. Which approaches should be used to reduce the risk of exposing sensitive parameters during CloudFormation deployments? (Choose 2)

• ❏ A. Store credentials in AWS Secrets Manager and resolve them in the template using CloudFormation dynamic references

• ❏ B. Turn on default encryption for the Amazon S3 bucket that stores the CloudFormation template

• ❏ C. Configure NoEcho on sensitive CloudFormation parameters to hide their values in stack outputs and events

• ❏ D. Use AWS Systems Manager Parameter Store secure strings and reference them by tag keys in the template

• ❏ E. Enable AWS CloudTrail data event logging for S3 to audit template access

Lyra Logistics runs a customer dashboard on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer, and releases are rolled out with blue green deployments that replace instances immutably. During cutovers and scaling events, some users are forced to sign back in because their sessions do not persist. What should the team implement to preserve authenticated sessions across instance replacements with the lowest possible latency?

• ❏ A. Enable target group stickiness and store sessions on each instance’s attached storage

• ❏ B. Store session data in Amazon DynamoDB

• ❏ C. Configure the application to persist session state in an Amazon ElastiCache for Redis cluster

• ❏ D. Save authenticated session data in an Amazon S3 bucket

The platform team at a global sportswear marketplace is rolling out its primary web service to an EC2 Auto Scaling group using AWS CodeDeploy with an in-place, batched deployment. When the rollout finishes, the group has six instances, where four serve the new build and two still run the previous version, yet CodeDeploy marks the deployment as successful. What is the most likely cause of this situation?

• ❏ A. A CloudWatch alarm fired during the rollout

• ❏ B. Two instances lacked IAM permissions to retrieve the revision from Amazon S3

• ❏ C. An Auto Scaling scale-out event occurred during the deployment, so the new instances launched with the last successfully deployed revision

• ❏ D. The Auto Scaling group is using an outdated launch template or launch configuration version

A regional healthcare analytics firm runs its ERP workloads on Amazon EC2 within its AWS environment, with infrastructure provisioned by AWS CloudFormation across two Regions. Engineers currently update AMI IDs by hand in multiple templates before each release, which slows delivery and introduces drift. The team wants to keep using CloudFormation but automatically resolve the latest golden AMI for future stack updates and launches. What should they do?

• ❏ A. Integrate AWS CloudFormation with AWS Service Catalog to automatically source the newest AMI IDs for deployments

• ❏ B. Use AWS Systems Manager Parameter Store with CloudFormation parameters to resolve the latest AMI IDs and run stack updates when rolling out new images

• ❏ C. Store the latest AMI IDs in Systems Manager State Manager and connect it to CloudFormation, then call UpdateStack whenever EC2 instances need refreshing

• ❏ D. Create an Amazon EventBridge rule that invokes an AWS Lambda function to find the newest AMI and programmatically rewrite the template before each deployment

At Riverton BioTech, an Amazon EC2 instance writes confidential research data to an attached Amazon EBS volume that was created without encryption. Security now requires the records to be encrypted at rest while keeping the instance running. What actions should the engineer perform to meet this requirement? (Choose 2)

• ❏ A. Provision a new encrypted EBS volume, attach it to the instance, migrate the data, and retire the old unencrypted volume

• ❏ B. Enable EBS encryption by default in the account and rely on it to encrypt the existing unencrypted volume

• ❏ C. Unmount the current EBS volume, take a snapshot, encrypt that snapshot directly, and re-mount the same volume

• ❏ D. Install a self-signed TLS certificate on the instance and use secure sessions to write data to the EBS volume

• ❏ E. Copy an unencrypted snapshot of the volume, encrypt the copied snapshot, and create a new volume from it

A fintech startup named BlueRiver Pay has moved its core payments API to AWS and uses AWS CodePipeline to orchestrate builds and releases across SANDBOX, INTEGRATION, STAGE, and PRODUCTION environments. After about eight weeks, the team observed multiple production incidents caused by bad configurations and buggy commits that slipped through earlier stages. A DevOps engineer must add steps that surface problems before production so functional defects are caught during deployments. Which combination of steps should be implemented to detect functional issues during the release process? (Choose 2)

• ❏ A. Add a test action in the pipeline that uses Amazon GuardDuty to evaluate the build with a Runtime Behavior Analysis rules package before releasing to PRODUCTION

• ❏ B. In the pipeline, add an AWS CodeDeploy action to roll out the latest build to the STAGE environment, insert a manual approval step for QA validation, then add a CodeDeploy action to push the approved release to PRODUCTION

• ❏ C. Add a test action that uses Amazon Macie to assess the build with a Runtime Behavior Analysis rules package and ensure it meets corporate security standards before promoting to PRODUCTION

• ❏ D. Add a test action that runs unit and functional test suites in AWS CodeBuild and block promotion to PRODUCTION unless all tests pass

• ❏ E. Add a test action that uses Amazon Inspector to run a Runtime Behavior Analysis assessment to certify the application meets strict security benchmarks before deployment to PRODUCTION

BlueWave Labs runs all development for several independent teams in one AWS account in a single Region. The DevOps engineer needs an easy way to alert the operations manager when new resource provisioning is getting close to account service quotas. Which approach requires the least custom development effort?

• ❏ A. Build a Lambda function to enumerate account resources and compare usage against published service quotas, trigger it on a schedule with EventBridge, and publish alerts to an SNS topic

• ❏ B. Create an AWS Config custom rule that evaluates service quota consumption and posts to an SNS topic, with a Lambda subscriber that notifies the operations manager

• ❏ C. Schedule a Lambda to refresh AWS Trusted Advisor service quota checks with EventBridge and add another EventBridge rule that matches Trusted Advisor limit events and publishes to an SNS topic subscribed by the operations manager

• ❏ D. Create a Lambda function to refresh AWS Health checks on a timer and configure an EventBridge rule that matches Trusted Advisor events and sends notifications to an SNS topic

Rivertown Analytics, a boutique data engineering company, runs a dozen Python web services built with Flask and Django on AWS. Several developers are contractors located in other countries. The team wants to automatically drive remediation workflows for AWS resource health issues by integrating the AWS Health Dashboard and the AWS Health API. They also need to automatically detect any company-owned IAM access key that shows up on a public GitHub repository, delete the key immediately, and notify the DevOps team. What approach should the DevOps engineer implement to meet these goals?

• ❏ A. Create an AWS Config rule to detect the AWS_RISK_CREDENTIALS_EXPOSED event across accounts using a data aggregator, and invoke an AWS Step Functions workflow with three Lambda tasks to revoke the key, compile recent CloudTrail activity, and publish an SNS alert

• ❏ B. Use Amazon GuardDuty with Amazon Macie to find exposed IAM access keys on the Internet, then trigger AWS Step Functions to delete the key, review CloudTrail usage, and send an Amazon SNS notification

• ❏ C. Create an Amazon EventBridge rule with source aws.health and event code AWS_RISK_CREDENTIALS_EXPOSED to start an AWS Step Functions state machine that runs three Lambda functions to remove the exposed access key, gather recent CloudTrail calls for that key, and send an SNS message to DevOps

• ❏ D. Set up an AWS Personal Health Dashboard rule for AWS_RISK_CREDENTIALS_EXPOSED and target Step Functions from EventBridge to orchestrate the key deletion, activity summary, and SNS alert

A fintech startup runs a high-revenue customer portal in its own data center built with Node.js and React. The team is moving the application to AWS Elastic Beanstalk and must sustain 99.95% availability. During each release the current EC2 instances must continue serving traffic while a new set of instances is created for the incoming version. After the new instances pass health checks they should take traffic and the previous instances should be retired, without making any DNS changes such as modifying the environment CNAME. If the deployment fails the newly launched instances must be terminated and the existing fleet should continue handling requests. Which Elastic Beanstalk deployment approach best satisfies these requirements?

• ❏ A. Configure Elastic Beanstalk to use rolling deployments with an additional batch

• ❏ B. Configure Elastic Beanstalk to use immutable environment updates

• ❏ C. Use a blue/green deployment and swap the environment CNAMEs

• ❏ D. Configure Elastic Beanstalk to use rolling deployments

A DevOps engineer at NovaBooks is launching a three-tier workload on AWS with an Application Load Balancer in front of an Amazon ECS Fargate web service. The web service calls a separate ECS backend service and stores data in an Amazon RDS MySQL database. The team wants the load balancer to send requests only to web tasks that can successfully reach both the backend and the database. How should this validation be implemented?

• ❏ A. Configure Amazon Route 53 health checks for the web service and use Application Auto Scaling to replace failing ECS tasks and RDS instances

• ❏ B. Add the ECS web tasks and the RDS DB instance as targets in the ALB target group and use default TCP health checks

• ❏ C. Implement a readiness endpoint in the web service that verifies connectivity to the backend ECS service and the RDS database, and set the target group health check to that path

• ❏ D. Create CloudWatch alarms on RDS active connections and ALB target response codes and instruct the ALB to mark targets unhealthy based on the alarm state

A travel-tech firm plans to move its marketing website to AWS across three accounts in a landing zone. The existing platform runs Windows IIS with Microsoft SQL Server on premises. They need elastic scaling and must capture ad click attributes from the site, delivering events to an Amazon S3 bucket for billing and into Amazon Redshift for analytics within a few minutes. Which architecture should they implement to meet these objectives while keeping the web tier stateless?

• ❏ A. Run the site on stateless EC2 in an Auto Scaling group and move SQL Server to Amazon RDS; publish click data with Amazon Kinesis Data Streams directly to Amazon S3 for billing and send another stream to Amazon Redshift

• ❏ B. Run the site on stateless EC2 in an Auto Scaling group and move SQL Server to Amazon RDS; use Amazon Athena to push click logs to Amazon S3 and also load them into Amazon Redshift

• ❏ C. Run the site on stateless EC2 in an Auto Scaling group and move SQL Server to Amazon RDS; use Amazon Kinesis Data Firehose to deliver click events to Amazon S3 for billing and a second Firehose delivery stream to load Amazon Redshift

• ❏ D. Run the site on stateless EC2 in an Auto Scaling group and move SQL Server to Amazon RDS; send click events to Amazon MSK and rely on an AWS Glue crawler and catalog to populate Amazon Redshift

Aurora Vision, a media analytics firm, has enabled the AWS Config managed rule cloudformation-stack-drift-detection-check to watch CloudFormation stacks across three Regions. The team wants to understand how to detect drift for CloudFormation custom resources, and they also see cases where the CloudFormation console shows a stack as IN_SYNC while the rule marks it NON_COMPLIANT with the message “While AWS CloudFormation failed to detect drift, defaulting to NON_COMPLIANT. Re-evaluate the rule and try again.” Which combination of actions should the DevOps engineer take to resolve both issues? (Choose 2)

• ❏ A. Enable AWS CloudTrail to capture configuration changes for custom resources

• ❏ B. CloudFormation drift detection does not support custom resources

• ❏ C. The IAM role specified in cloudformationRoleArn is missing permissions and triggers this exact error

• ❏ D. AWS Config relies on the DetectStackDrift API; if calls are throttled or unavailable the rule is set to NON_COMPLIANT

• ❏ E. CloudFormation only reports drift for explicitly defined properties; define all properties on the custom resource to have it evaluated

A multinational retail analytics firm deploys identical CloudFormation stacks to dev, QA, UAT, and production. The stack launches Amazon EC2 instances and an Amazon RDS database. During a 10-day UAT cycle, an update that changed the RDS instance class triggered a replacement and the test data was lost. The company also requires that when the stack is removed, snapshots of any EBS volumes are preserved for audit. What should you configure to satisfy these requirements? (Choose 2)

• ❏ A. Configure DeletionPolicy: Snapshot on AWS::EC2::Volume resources to capture EBS snapshots on stack deletion

• ❏ B. Set DeletionPolicy: Retain on the AWS::RDS::DBInstance so replacements and deletions do not remove the database

• ❏ C. Turn on termination protection for the Amazon EC2 instances and the Amazon RDS DB instance

• ❏ D. Declare the DBInstanceClass property as immutable so the instance type cannot be changed during updates

• ❏ E. Apply a CloudFormation stack policy that blocks updates to the DB instance and restricts SetStackPolicy to prevent overrides

The correct choice is Use AWS CloudFormation StackSets with service-managed permissions from the management account to deploy a CloudTrail trail and required IAM roles to target OUs, enabling automatic deployments to new accounts and automatic stack instance removal when accounts are closed or leave.

Use AWS CloudFormation StackSets with service-managed permissions from the management account to deploy a CloudTrail trail and required IAM roles to target OUs, enabling automatic deployments to new accounts and automatic stack instance removal when accounts are closed or leave integrates directly with AWS Organizations so stacks are automatically deployed to accounts that join targeted organizational units and stack instances are automatically removed when accounts leave. You can model the CloudTrail trail and the required IAM roles as CloudFormation resources so deployments are consistent and repeatable. Using StackSets with service-managed permissions reduces custom cross account orchestration because AWS manages the service role and permissions needed to deploy into member accounts.

AWS Control Tower provides a prescriptive landing zone and guardrails but it brings its own account factory and baselines and it can be heavier to adopt for an environment that already uses Organizations. It is not the simplest choice for applying a custom set of IAM roles and automated cleanup across existing OUs.

Create an EventBridge rule in the management account that detects new account creation and invokes a Lambda function to configure CloudTrail and create the IAM roles can accomplish automation but it relies on custom code and complex cross account permissions. That approach increases operational overhead and does not provide the native automatic removal of deployed resources when an account leaves the organization.

Enable an organization trail for all member accounts and create a single IAM role to be shared across the organization centralizes CloudTrail logging but it does not provision IAM roles into each account automatically. Sharing a single role across accounts is not a replacement for deploying per-account IAM roles and it does not solve automated cleanup when accounts are removed.

For multi account, OU targeted, automatic deployment and cleanup with minimal operations remember to consider CloudFormation StackSets with service-managed permissions integrated with AWS Organizations.

Host the site on Amazon S3 and put Amazon CloudFront in front, then attach a CloudFront response headers policy to inject the required security headers is the correct choice because a CloudFront response headers policy injects standard security headers into viewer responses centrally and without custom code.

Using a CloudFront response headers policy lets you add X-Content-Type-Options, X-Frame-Options, X-XSS-Protection and other headers at the distribution level. This approach is maintainable because you manage the headers in one place and apply them across behaviors and distributions, and it avoids the operational overhead of running edge functions.

Host the static site on Amazon S3 website hosting and try to add the security headers using an S3 bucket policy is not viable because bucket policies control access and not HTTP response headers, and you cannot rely on a bucket policy to inject viewer response headers for the whole site.

Serve the S3 website through Amazon CloudFront and configure Origin Custom Headers to include the OWASP headers is incorrect because origin custom headers are added to requests that CloudFront sends to the origin and they do not alter the headers returned to viewers. Viewer response headers must be set at the distribution or by the origin itself.

Host on Amazon S3 behind CloudFront and use a Lambda@Edge origin-response function to set the security headers can work technically but it adds complexity, operational burden and potential cost. Reserve CloudFront response headers policy for standard headers and use Lambda@Edge only when you need dynamic or custom logic that policies cannot express.

When you need to add standard security headers to static content behind CloudFront prefer a CloudFront response headers policy because it is code free and easy to manage. Use Lambda@Edge only for custom behavior that policies cannot handle.

Place the EC2 fleet in a Multi-AZ Auto Scaling group behind an Application Load Balancer, use Amazon Aurora with multi-master writers for higher throughput and high availability, and enable Amazon Inspector for ongoing vulnerability scans is correct because it meets the requirements for minimal downtime, fault tolerance across the full stack, high write throughput during traffic surges, and continuous vulnerability assessment.

Place the EC2 fleet in a Multi-AZ Auto Scaling group behind an Application Load Balancer provides automatic scaling and zone level redundancy for the web tier so the site can remain available during instance failures and traffic spikes. Amazon Aurora with multi-master writers offers higher write throughput and writer availability by allowing multiple writable instances so the database layer can tolerate failures and handle bursty drops. Amazon Inspector runs continuous vulnerability scanning of supported instances and images so security teams get ongoing assessments of the workload.

Deploy a Multi-AZ Auto Scaling group with an Application Load Balancer, back the data tier with Amazon Aurora configured for multi-master to improve throughput, and use Amazon Macie for automatic security assessments is incorrect because Macie focuses on discovering and classifying sensitive data in Amazon S3 and it does not provide continuous host or image vulnerability scanning.

Run EC2 instances in a Multi-AZ Auto Scaling group behind an Application Load Balancer, choose RDS for PostgreSQL in a multi-master setup for HA to boost performance, and use Amazon Inspector for continuous assessments is incorrect because RDS for PostgreSQL does not provide a built in multi-master write architecture so it cannot meet the multi-writer availability and high write throughput goal.

Use a Multi-AZ Auto Scaling group of EC2 instances with an Application Load Balancer, deploy Amazon Aurora with multi-master writers for scale, and enable Amazon GuardDuty for automatic vulnerability scanning is incorrect because GuardDuty performs threat detection from network and account activity and it is not a host or image vulnerability scanner.

On exams remember that Amazon Inspector is the vulnerability scanner, GuardDuty is threat detection, and Macie finds sensitive data. Also favor Amazon Aurora multi-master when you need higher write throughput and writer availability for a managed relational database.

Configure subscription filters on all log groups to stream to Amazon Data Firehose and set the delivery stream to write to the S3 bucket in the audit account, with an EventBridge rule invoking an AWS Lambda function that calls PutSubscriptionFilter when CreateLogGroup events occur is correct because it provides continuous, near real time streaming into a central S3 location and can be automated to onboard new log groups across accounts with minimal ongoing effort.

Configure subscription filters on all log groups to stream to Amazon Data Firehose and set the delivery stream to write to the S3 bucket in the audit account, with an EventBridge rule invoking an AWS Lambda function that calls PutSubscriptionFilter when CreateLogGroup events occur uses CloudWatch Logs subscription filters to forward log events to a delivery stream which can deliver to a cross account S3 bucket by using an appropriate IAM role in the audit account. This approach avoids periodic batch exports and gives continuous delivery. Automation is achieved by creating an EventBridge rule for CreateLogGroup events and a Lambda function that calls PutSubscriptionFilter so new log groups are configured automatically.

Schedule recurring CloudWatch Logs export tasks in each account to deliver log data to the central S3 bucket, triggered periodically by Amazon EventBridge is incorrect because export tasks are batch oriented and require per account and often per log group scheduling. This method does not provide continuous streaming and does not automatically attach exports to log groups created after the tasks are scheduled.

Use AWS DataSync to copy log files from CloudWatch Logs to the S3 bucket in the audit account and run tasks daily for all log groups is incorrect because AWS DataSync does not support CloudWatch Logs as a source. DataSync is intended for file and object storage transfers and cannot read CloudWatch Logs directly.

Attach a CloudWatch Logs subscription that sends data directly to an S3 bucket in each account and use a Lambda function to attach the subscription to new log groups is incorrect because CloudWatch Logs cannot subscribe directly to S3. Subscription targets must be services such as Amazon Kinesis Data Streams, AWS Lambda, or Amazon Kinesis Data Firehose which then deliver to S3 if desired.

For continuous delivery of CloudWatch Logs to a central S3 bucket remember to automate onboarding of new log groups with EventBridge CreateLogGroup events and a Lambda that calls PutSubscriptionFilter. Think subscription filters to Data Firehose for streaming.

The correct choice is Store the RDS database credentials in AWS Secrets Manager and attach an EC2 instance profile that can read that secret and call DynamoDB APIs. This design uses a secrets store for the database password and it uses an instance role to obtain temporary AWS credentials to call DynamoDB APIs.

Using Store the RDS database credentials in AWS Secrets Manager and attach an EC2 instance profile that can read that secret and call DynamoDB APIs is secure because Secrets Manager provides encrypted storage and built in rotation for RDS credentials, and the EC2 instance profile removes the need to distribute long lived keys by granting temporary credentials via IAM. The instance role can be granted permission to read the specific secret and also to call DynamoDB, so the application gets database credentials and service access without hardcoding secrets in the instance image or configuration.

Put both the RDS password and supposed DynamoDB credentials in AWS Secrets Manager and grant the EC2 instance role permission to read the secrets is incorrect because DynamoDB does not use database style credentials and access should be controlled with IAM. Storing imagined DynamoDB credentials in Secrets Manager is unnecessary and does not follow AWS best practices.

Keep IAM user access keys and the RDS password in Secrets Manager and let the EC2 instance role retrieve them is incorrect because relying on long lived IAM user keys is insecure and unnecessary. Instance profiles deliver short lived credentials so you should not distribute or store IAM user access keys for EC2 workloads.

Use AWS Systems Manager Parameter Store SecureString for both the RDS credentials and DynamoDB, and allow the instance role to read those parameters is not the ideal choice because Parameter Store does not provide native RDS credential rotation and managing DynamoDB access via stored secrets is inferior to using IAM. Secrets Manager is purpose built for database credentials and rotation, and IAM roles are the correct mechanism for DynamoDB access.

Use AWS Secrets Manager for database passwords and use an EC2 instance role to call AWS APIs. Remember that DynamoDB access should be governed by IAM rather than by stored credentials.

Use a CloudFormation stack that creates a CodePipeline to build hardened AMIs and write the current AMI ID to AWS Systems Manager Parameter Store, and have the Platform team resolve that parameter in their templates using an SSM dynamic reference to always launch the latest image is the correct choice because it provides a clear contract between teams and allows stacks to pick up the approved AMI at deploy time without changing templates.

The SSM Parameter Store pattern decouples the Security and Platform teams and centralizes the authoritative AMI ID in a managed service. The Security team can automate image builds and write the current AMI ID into the parameter with their pipeline. The Platform team can reference that parameter with an SSM dynamic reference in CloudFormation so new stacks automatically resolve the latest approved image at launch. This approach supports cross-account reads via IAM and avoids requiring template changes for every AMI refresh.

Have the Security team publish AMI IDs to an encrypted S3 object from a CloudFormation-created CodePipeline and have the Platform team read the object location via a cross-stack export to obtain the latest AMI ID at deploy time is less ideal because it adds indirection with S3 artifacts and cross-stack exports. Cross-stack exports are brittle across accounts and require additional orchestration and permissions which increases maintenance overhead.

Build AMIs with EC2 Image Builder and tag the latest image, then have the Platform team configure CloudFormation to look up the AMI by tag during stack creation is impractical for native CloudFormation because CloudFormation does not natively resolve AMIs by arbitrary tags. Implementing tag lookups requires custom resources or scripts which add complexity and reduce reliability compared with dynamic parameter references.

Ask the Security team to maintain a nested stack that includes both OS and application templates and trigger stack updates whenever application code changes couples responsibilities and creates a deployment bottleneck. That pattern violates separation of duties and slows iteration because the Security team would need to coordinate and run application updates instead of focusing on OS hardening and image publishing.

Prefer using SSM Parameter Store with dynamic references for AMI ID late binding so templates do not need updates when images rotate. Keep the image publisher and deployer separate and use IAM for cross-account read access.

Deploy the app with AWS Elastic Beanstalk using a multi Availability Zone environment behind a load balancer, and launch instances from an AWS Systems Manager Automation built custom AMI that includes all required components; enable DynamoDB Auto Scaling and update Route 53 to target the Beanstalk load balancer is the correct choice because it combines a managed platform with a prebaked image to deliver fast, reliable scale out across Availability Zones.

Elastic Beanstalk handles Auto Scaling, load balancing, health checks, and rolling deployments so the platform reduces operational overhead and improves availability. Using a custom AMI built and maintained with Systems Manager Automation or an image pipeline avoids lengthy package installs at boot and shortens instance warm up time, so additional servers can serve traffic quickly during spikes. Enabling DynamoDB Auto Scaling keeps the session store responsive as traffic changes and mapping Route 53 to the environment load balancer gives a simple, resilient DNS target.

Migrate to Amazon ECS with the Fargate launch type, define a task for the Node.js service with all dependencies, enable DynamoDB auto scaling, front it with an Application Load Balancer, and map the domain in Route 53 to the load balancer is less suitable because it requires containerizing and refactoring the application and pipelines, and that work may delay the immediate operational benefit of faster instance provisioning.

Use EC2 Auto Scaling with a launch template that installs the application via user data on boot across multiple Availability Zones behind an Application Load Balancer, turn on DynamoDB Auto Scaling, and point the DNS name in Route 53 to the load balancer is not ideal because boot-time user data still runs heavy setup at launch, so instance warm up remains long and scaling responsiveness suffers compared with a prebaked AMI approach.

Run a Spot Fleet with a target capacity of 24 instances behind an Application Load Balancer, route the domain through Route 53, and raise the DynamoDB read and write capacity units manually is risky because Spot instances can be interrupted and manual capacity changes reduce elasticity, which makes the solution less resilient and operationally brittle for a production media platform.

Use a prebaked AMI for fast instance warm up and pair it with multi Availability Zone Auto Scaling and a load balancer to improve resilience and reduce scale out delays.

Deploy on AWS Elastic Beanstalk for the Go platform, upload the application bundle to Amazon S3, and use Elastic Beanstalk environment swap for blue/green deployments is correct because it provides a managed way to run two identical environments and perform a CNAME swap to shift traffic for A/B validation with minimal operational burden.

Elastic Beanstalk natively supports Go and includes environment cloning and an environment CNAME swap feature so teams can create parallel stacks, test or validate with live traffic, and cut over or roll back without building custom orchestration. This reduces undifferentiated heavy lifting and meets the requirement for managed, side by side blue green releases.

Create an AMI-based workflow on Amazon EC2 using a launch template, an Auto Scaling group, and an Application Load Balancer, then perform instance refreshes on each release is not the best fit because instance refresh performs in place replacements and does not inherently provide two concurrently active environments for clean traffic switching without adding orchestration and DNS management.

Use AWS App Runner connected to an Amazon ECR repository and enable automatic deployments simplifies container build and deploy workflows but it does not offer first class environment level blue green with side by side stacks and a built in environment swap mechanism required for controlled A/B experiments.

Store build outputs in AWS CodeArtifact and use AWS CodeDeploy to push to an EC2 fleet behind an Application Load Balancer is misleading because CodeArtifact is a package repository and not intended as a general artifact deployment store. CodeDeploy can handle deployments but this combination does not provide the managed environment cloning and CNAME swap that Elastic Beanstalk offers out of the box.

When the exam describes two parallel environments and easy traffic shifting choose a service that supports environment cloning and a CNAME swap like Elastic Beanstalk environment swap rather than relying on in place updates.

Configure an EventBridge rule for AWS Glue job run events with a Lambda target that inspects the event details for a failed final attempt and then publishes to SNS is correct because EventBridge delivers Glue job run events reliably and a Lambda function can perform the conditional checks needed to confirm that the failure occurred on the final retry before publishing to SNS.

EventBridge will route the AWS Glue JOB_RUN_STATE_CHANGE events to the Lambda target and the function can inspect fields such as jobRunState and any attempt or error details. EventBridge event patterns cannot perform numeric comparisons or complex conditional logic so placing that logic in Lambda prevents false positives and avoids rearchitecting the Glue job. The Lambda can call SNS Publish only when the event shows a final retry failure and it can enrich the notification with context for operators.

Create an EventBridge rule for AWS Glue job state changes and set an SNS topic as the target using an event pattern intended to match retry failures is not sufficient because EventBridge patterns match fixed values and they cannot express logic to detect a final retry or compare attempt counts which will likely produce unwanted alerts.

Use the AWS Personal Health Dashboard with a scheduled Lambda poller that posts to SNS when a Glue retry fails is incorrect because the Personal Health Dashboard reports account and service health events and it does not provide per-job retry outcomes for Glue jobs.

Re-orchestrate the job in AWS Step Functions and have the workflow send an SNS message if the final retry fails is possible but it introduces extra complexity and requires changing the existing orchestration when the requirement can be met by using EventBridge and a small Lambda to implement the final-retry check.

Use EventBridge for routing and a small Lambda to apply conditional checks on fields like jobRunState and attempt counts before publishing to SNS.

Create an AWS CloudFormation service role scoped to the needed actions, associate it with the stack, and grant the engineer iam:PassRole to let CloudFormation assume that role during deployments is correct because CloudFormation can assume the service role to perform resource creation and management on behalf of the user and the role policy can enforce least privilege so the engineer does not need direct permissions to every resource type.

This approach works because CloudFormation uses the service role when executing stack operations and the operator only needs the ability to pass that specific role. Granting Create an AWS CloudFormation service role scoped to the needed actions, associate it with the stack, and grant the engineer iam:PassRole to let CloudFormation assume that role during deployments and making the role narrowly scoped limits blast radius and aligns with the principle of least privilege.

Create an AWS CloudFormation service role with the necessary permissions and set it on the stack; use it for deployments is insufficient because a user launching the stack still needs iam:PassRole permission to allow CloudFormation to assume that role during the deployment.

Create an AWS CloudFormation service role with full administrative permissions, attach it to the stack, and allow iam:PassRole only when a ResourceTag matches is not appropriate because giving full administrative rights violates least privilege and restricting iam:PassRole by a ResourceTag is not a reliable mechanism for controlling which roles can be passed.

Create an AWS CloudFormation service role with required permissions and add an aws:SourceIp condition listing developer IPs; associate it to the stack and grant iam:PassRole is ineffective because CloudFormation makes downstream calls from AWS controlled endpoints and SourceIp conditions on the role will not reliably apply to those service actions.

When a user cannot create resources directly grant them iam:PassRole to a narrowly scoped CloudFormation service role so CloudFormation executes stack operations with least privilege.

Store the Aurora writer endpoint in AWS Systems Manager Parameter Store; use an Amazon EventBridge rule for RDS failure events to invoke an AWS Lambda function that promotes the cross-Region replica and updates the Parameter Store value; have the application read the endpoint from Parameter Store on reconnect is the correct choice because it automates promotion and updates a central endpoint that clients can re-resolve without redeploying.

This approach works because EventBridge can capture RDS and Aurora state change events and trigger a workflow, AWS Lambda can call the RDS APIs to promote the cross-Region replica and then update Parameter Store with the new writer endpoint, and the application can read the updated value on reconnect to restore connectivity. This design meets rapid recovery goals and keeps endpoint management dynamic so the application does not require redeployment.

Create an Amazon EventBridge rule that detects Aurora failure and directly modifies a CloudFormation template to promote the replica, then run an AWS Lambda function to apply the change set and repoint the application is incorrect because EventBridge does not edit CloudFormation templates as an automated recovery mechanism and relying on CloudFormation change sets is slower and not designed for rapid failover operations.

Keep the endpoint in AWS Secrets Manager, subscribe an Amazon SNS topic to RDS failure notifications from AWS CloudTrail, and run an AWS Lambda function to promote the replica and update the secret while the app fetches fallback values from Parameter Store is incorrect because CloudTrail is for auditing and not a direct real time failure notification source, and splitting endpoint storage between Secrets Manager and Parameter Store complicates the workflow without improving automated promotion.

Configure Amazon Route 53 health checks and DNS failover between the primary Aurora endpoint and the cross-Region reader endpoint to move traffic automatically during outages is incorrect because DNS based failover cannot perform the database promotion that changes a reader into a writer and DNS propagation and TTLs make DNS failover slower and less deterministic for meeting tight recovery time objectives.

Look for solutions that combine EventBridge RDS events with AWS Lambda automation and a dynamic endpoint store like Parameter Store so clients can re-resolve the writer address without redeploying.

The correct choice is In the ECS service, keep Platform version set to LATEST and choose Force new deployment to restart tasks on the newer runtime.

When a service uses the Platform version set to LATEST the Fargate runtime that new tasks receive follows the current platform release. Performing a Force new deployment causes the service scheduler to stop and replace tasks so that replacement tasks are launched against the current LATEST platform which in this case will pick up the 1.4.0 runtime and enable the Splunk log driver without changing the image or the task definition.

Edit the task definition to include the new platform version ARN, then update the service is incorrect because platform version is not an attribute of the task definition and you cannot embed a Fargate platform ARN into a task definition to control runtime selection.

Enable automatic Fargate platform upgrades for the cluster is incorrect since Amazon ECS does not offer a cluster-level toggle that automatically upgrades running Fargate tasks to newer platform versions.

Create a new ECS service using platform version 1.4.0 and shift traffic with CodeDeploy blue/green is incorrect because that approach adds unnecessary operational overhead for this scenario since a forced deployment will cause tasks to relaunch on the updated LATEST platform without creating a separate service or doing a blue green migration.

When Fargate is set to LATEST use the service action Force new deployment to pick up a newer platform release without editing task definitions.

Amazon Macie is the correct choice because it is designed to discover and classify sensitive data such as PII stored in Amazon S3 and to generate findings and alerts when risky access patterns or exposures are detected.

Amazon Macie uses machine learning and pattern matching to identify sensitive content in S3 objects and it can leverage S3 server access logs and AWS CloudTrail events to surface anomalous or unauthorized access that may affect compliance. This makes it well suited for the requirement to confirm that access to sensitive survey records meets compliance needs and to provide rapid notifications of potential data exposure.

Amazon GuardDuty focuses on threat detection across accounts and networks and can flag suspicious S3 access activity, but it does not inspect object content or classify PII to validate compliance for sensitive records.

AWS Security Hub aggregates and correlates findings from services such as Macie and GuardDuty, but by itself it does not perform content inspection of S3 objects or identify PII exposures.

Amazon Inspector performs vulnerability assessments for compute resources and images and is not intended to classify or monitor sensitive data stored in S3.

When a question mentions S3 objects containing sensitive data and the need to validate access or alert on exposure think Amazon Macie because it is built to find and classify PII.

The correct choices are Use the AWS-RunPatchBaseline SSM document to enforce approved patch baselines across the fleet and Install the AWS Systems Manager Agent on every instance, validate patches in staging, then schedule patching through Systems Manager Maintenance Windows with approvals.

Using Use the AWS-RunPatchBaseline SSM document to enforce approved patch baselines across the fleet gives a centralized Patch Manager workflow that supports both Windows and common Linux distributions and provides reporting and compliance checks. Pairing that with Install the AWS Systems Manager Agent on every instance, validate patches in staging, then schedule patching through Systems Manager Maintenance Windows with approvals enables staged rollouts, approval gates, and audit trails while keeping operational effort low.

Enable CloudFormation to automatically patch operating systems for all stacks and rely on AWS Config for audit reporting is incorrect because CloudFormation manages infrastructure as code and does not perform operating system patching and AWS Config can record configuration state but it does not orchestrate patch application.

Standardize on native OS package managers and approval workflows on each host, with AWS Config for compliance checks is not ideal because this approach requires custom automation and per host workflows that increase ongoing operational overhead compared with a centralized Systems Manager solution.

Use the AWS-ApplyPatchBaseline SSM document to patch Windows and Linux instances from the same baseline is incorrect because it does not provide the same cross platform, centralized patch baseline execution as Use the AWS-RunPatchBaseline SSM document to enforce approved patch baselines across the fleet and so it is not the right choice for a mixed Windows and Linux fleet.

Install the SSM Agent on every instance and use AWS-RunPatchBaseline with Maintenance Windows to stage patches, require approvals, and preserve auditable logs.

The correct choice is Use AWS Organizations with OUs and a per business unit IAM role in the production account that allows TerminateInstances only on resources it owns, assumed via cross-account trust. This approach scopes termination rights so that only the division that owns an EC2 instance can terminate it.

Implement this by grouping accounts under AWS Organizations and placing divisions into appropriate OUs. In the shared production account create one IAM role per division with a trust policy that allows only that division’s member accounts to assume the role. Attach an IAM policy to each role that permits the ec2 termination action only on the instances the division owns by using resource level restrictions and tag based conditions so ownership is enforced at the API level.

Use a centralized AWS Config aggregator with AWS Control Tower and Customizations for AWS Control Tower to restrict EC2 termination per division is incorrect because AWS Config and Control Tower provide visibility and guardrails but they do not grant or enforce per resource termination permissions at the IAM level.

Enable EC2 termination protection on all instances and route termination requests through AWS Systems Manager Change Manager approvals is incorrect because termination protection and Change Manager provide process controls and manual blockers but they do not implement fine grained owner based authorization across accounts and they do not scale well for cross account automated access.

Create an SCP in the production account via AWS Service Catalog that permits business-unit-specific termination actions and attach it to the appropriate OUs is incorrect because service control policies do not grant permissions and cannot target individual EC2 instances, and AWS Service Catalog is not used to define cross account IAM authorization boundaries.

Group accounts with Organizations and enforce ownership with resource level IAM policies and tags when you design cross account controls.

Set the EngineVersion in AWS::RDS::DBInstance to the target MySQL major version, provision a like-for-like Read Replica in a separate stack first, then perform an Update Stack to apply the change with a quick cutover is the correct choice because it enables a staged, low-downtime migration path for a Multi-AZ RDS for MySQL instance.

Creating a like-for-like read replica ahead of time lets you bring up the new major MySQL version in parallel while the current primary remains online. After the replica syncs and you validate the upgraded instance you perform a quick cutover and update the CloudFormation stack to point to the upgraded database. This approach provides a fallback option and minimizes user disruption compared with doing an in-place major upgrade on a Multi-AZ deployment.

Enable AutoMinorVersionUpgrade and create a matching RDS Read Replica before running Update Stack is incorrect because AutoMinorVersionUpgrade only applies minor patches and will not perform major version upgrades.

AWS Database Migration Service is not the best answer here because DMS can migrate with low downtime but it is not an in-place CloudFormation upgrade and it introduces additional migration complexity that the question does not require.

Modify the DBEngineVersion property and run Update Stack, then add a read replica and update the stack again is incorrect because DBEngineVersion is not a valid CloudFormation property name for RDS and performing an in-place major upgrade before provisioning a replica increases downtime and risk.

Use a pre-provisioned read replica or blue green style cutover for major RDS engine upgrades to keep downtime minimal and remember that AutoMinorVersionUpgrade only handles minor patches.

The target EC2 instances are missing an IAM instance profile that grants the CodeDeploy agent required access and The EC2 instances cannot reach CodeDeploy public endpoints because they have no egress path through a NAT gateway or internet gateway are correct because both conditions will prevent the CodeDeploy agent from installing a revision and reporting lifecycle progress which results in Skipped events.

The target EC2 instances are missing an IAM instance profile that grants the CodeDeploy agent required access is correct because the CodeDeploy agent uses the instance role to download revisions for example from Amazon S3 and to call CodeDeploy APIs to update deployment status. Without a proper instance profile the agent cannot fetch the application revision or communicate progress to the service.

The EC2 instances cannot reach CodeDeploy public endpoints because they have no egress path through a NAT gateway or internet gateway is correct because the agent needs outbound network connectivity to contact CodeDeploy endpoints. If there is no egress to CodeDeploy endpoints or no configured VPC endpoints the hooks cannot run and lifecycle events will be skipped.

The IAM user who triggered the deployment does not have sufficient permissions in CodeDeploy is incorrect because the initiating user permissions do not control the agent runtime actions on instances. The agent uses the instance profile and the CodeDeploy service role to perform deployment operations.

The deployment group is configured to target instances by tags instead of an Auto Scaling group is incorrect because targeting by tags and by Auto Scaling group are both supported methods and neither inherently causes lifecycle events to be skipped.

The EC2 instances must be explicitly registered with a CodeDeploy endpoint before they can receive deployments is incorrect because no manual registration is required. Installing the CodeDeploy agent and providing a valid instance profile and network access is sufficient for instances to receive deployments.

When you see Skipped lifecycle events check the EC2 instance role first and then confirm outbound network access to CodeDeploy endpoints or configured VPC endpoints.

Run EC2Rescue with AWS Systems Manager Automation using the AWSSupport-ExecuteEC2Rescue document and monitor best practice checks via the aws.trustedadvisor event source is the correct choice because it provides a purpose built automation runbook that can diagnose and repair Windows instances that are unreachable due to RDP failures, restrictive firewalls, or incorrect network settings and it can be invoked automatically so recovery can meet the 15 minute target.

Run EC2Rescue with AWS Systems Manager Automation using the AWSSupport-ExecuteEC2Rescue document and monitor best practice checks via the aws.trustedadvisor event source uses Systems Manager Automation to run the AWSSupport-ExecuteEC2Rescue playbook which orchestrates EC2Rescue tools to reset RDP, adjust network configuration, and apply fixes at the OS level without manual console access. You can create an EventBridge rule on the aws.trustedadvisor event source to surface best practice findings and then trigger or notify the Automation workflow so remediation and check monitoring are integrated.

Orchestrate AWS Config with Session Manager, CloudWatch, Lambda, and Run Command to detect issues and repair unreachable EC2 instances is not ideal because it becomes complex to maintain and it depends on agent connectivity and session availability which may be impaired when the guest OS networking or RDP is broken.

Use AWS Trusted Advisor to automatically resolve performance and security findings and recover EC2 instances is incorrect because Trusted Advisor only produces checks and recommendations and it does not perform OS level remediation for RDP, firewall, or network configuration problems.

Configure EC2 Auto Recovery by creating CloudWatch alarms on instance status checks to reboot or recover failed instances is unsuitable because EC2 Auto Recovery targets host hardware or hypervisor issues detected by system status checks and it will not repair OS level problems such as corrupted RDP settings or restrictive guest firewalls.

Prefer Systems Manager Automation with the AWSSupport-ExecuteEC2Rescue runbook for unreachable Windows instances and use EventBridge with aws.trustedadvisor to surface findings and trigger remediation.

Create a CloudWatch Logs subscription filter that sends matching log events to an AWS Lambda function, tag the instance that produced the login entry, and use an Amazon EventBridge scheduled rule to invoke a second Lambda function hourly to terminate tagged instances is correct because it enables near real time detection and it guarantees termination well within 12 hours by persisting state with instance tags and scheduling periodic enforcement.

This CloudWatch Logs subscription filter that sends matching log events to an AWS Lambda function, tag the instance that produced the login entry, and use an Amazon EventBridge scheduled rule to invoke a second Lambda function hourly to terminate tagged instances approach uses the unified CloudWatch agent to stream instance system logs to CloudWatch Logs and it uses a subscription filter to trigger a Lambda that identifies and tags the instance that had a manual OS login. Tags persist the detection result on the instance and they let a scheduled remediation job safely and idempotently find and terminate affected instances within the required time window.

Create a CloudWatch alarm that triggers on AWS API call events in CloudTrail, send the alarm to an Amazon SQS queue, and run an AWS Lambda function from the queue to terminate instances that generated the login event is wrong because OS level logins do not generate AWS API calls and they do not appear in CloudTrail. CloudTrail records API activity and it will not contain instance syslog entries.

Create a CloudWatch Logs subscription filter that sends events to AWS Step Functions, use the state machine to tag the resources that produced the login entry, and add an EventBridge rule that runs daily to invoke a Lambda function to terminate instances with that tag is incorrect because CloudWatch Logs subscription filters can only deliver to Lambda, Kinesis Data Streams, or Kinesis Data Firehose, and a daily enforcement schedule risks missing the 12 hour requirement.

Configure an AWS Config custom rule to detect SSH or RDP logins from instance system logs and invoke an SSM Automation runbook that terminates the instance is not viable because AWS Config evaluates resource configuration and compliance and it does not ingest or analyze ephemeral OS syslog events.

When the signal comes from instance syslogs use CloudWatch Logs subscription to Lambda for detection and use EventBridge scheduled rules for reliable, timebound remediation.

All DevOps questions come from certificationexams.pro and my Certified DevOps Engineer Udemy course.

Rehost the Oracle RAC database on EBS-backed Amazon EC2, install the SSM agent, use AWS Systems Manager Patch Manager for OS patches, and configure Amazon Data Lifecycle Manager to schedule EBS snapshots is correct because Oracle RAC requires EC2 hosting and this combination uses native AWS services to automate operating system patching and scheduled backups with retention.

The chosen approach places the RAC nodes on EBS-backed EC2 instances which supports the clustered storage and networking that RAC needs and it leverages Systems Manager Patch Manager together with the SSM agent to apply OS updates at scale. Amazon Data Lifecycle Manager provides native snapshot scheduling and retention so you can meet the roughly 60 day retention objective without building custom orchestration.

Migrate the database to Amazon Aurora, enable automated backups, and rely on Aurora maintenance windows for patching is incorrect because Amazon Aurora does not support Oracle RAC and it cannot host the clustered Oracle workload.

Move the on-premises database to Amazon RDS for Oracle with Multi-AZ and let RDS handle backups and host patching is incorrect because RDS for Oracle does not support RAC and therefore is not a viable migration path for a RAC environment.

Move the RAC database to Amazon EC2 and trigger CreateSnapshot with an AWS Lambda function on an Amazon EventBridge schedule, and use AWS CodeDeploy and AWS CodePipeline to manage patching is incorrect because AWS CodeDeploy and CodePipeline are continuous integration and delivery services rather than OS patch automation tools and orchestrating snapshots with custom Lambda logic requires more engineering than using Data Lifecycle Manager.

When you see Oracle RAC choose EC2 and use Systems Manager Patch Manager for OS patches and Amazon Data Lifecycle Manager for scheduled EBS snapshots to minimize engineering effort.

The best option is Install the unified CloudWatch agent on all on-premises servers and EC2 instances to send logs to CloudWatch Logs, subscribe the log groups to Kinesis Data Firehose delivering to a central Amazon S3 bucket, invoke AWS Lambda from S3 events for anomaly checks, and query with Amazon Athena. This solution covers both on prem and AWS workloads and provides centralized, near real time aggregation with durable, low cost storage and simple ad hoc querying.

The unified CloudWatch agent can collect both operating system and application logs from EC2 and from servers running outside AWS and send them to CloudWatch Logs. Subscribing those log groups to Kinesis Data Firehose lets you reliably deliver and buffer logs into a central S3 bucket without building ingestion servers. Keeping logs in S3 is cost effective and lets Athena run SQL queries directly for audits and troubleshooting. Using S3 events to invoke Lambda supports lightweight anomaly checks and automation without adding persistent infrastructure.

Install the CloudWatch agent only on EC2 instances, export logs from CloudWatch to a central S3 bucket using console batch export, and analyze with a custom Amazon EMR cluster is incomplete because it omits on prem servers and relies on manual or batch exports that do not scale. It also adds heavy operational overhead and cost with a custom EMR cluster.

Deploy the CloudWatch Logs agent on all servers and EC2 instances, aggregate logs on an on-premises NAS, and build a self-managed ELK stack for analytics forces you to run and maintain storage and ELK components. That increases complexity, cost, and time to value compared to managed serverless services that centralize logs in S3.

Use the CloudWatch agent across all nodes to send logs to CloudWatch Logs and stream them to Amazon OpenSearch Service for searches and dashboards can work for interactive search and dashboards but operating OpenSearch at large scale requires capacity planning and higher ongoing cost. For audit focused, ad hoc SQL queries a Firehose to S3 plus Athena approach is usually more cost effective and simpler to manage.

When a question highlights hybrid collection and low cost prefer the unified CloudWatch agent to CloudWatch Logs with Firehose to S3 and use Athena for ad hoc queries.

Configure the CodePipeline stage to run actions for each Lambda function in parallel by assigning the same runOrder is correct because assigning the same runOrder lets CodePipeline execute independent actions concurrently which reduces the end to end pipeline duration without changing how each function is built tested and deployed.

The Configure the CodePipeline stage to run actions for each Lambda function in parallel by assigning the same runOrder option leverages CodePipeline behavior where actions with the same runOrder in a stage run at the same time. Running build and deploy actions for each function in parallel removes the sequential bottleneck that was causing slow total pipeline time and it preserves the existing build test and packaging logic for each Lambda.

Increase the CodeBuild projects to a larger compute type with additional vCPUs is incorrect because larger compute may shorten individual build steps but it does not remove the serialization between actions so overall pipeline time would remain constrained by sequential execution.

Use CodeBuild batch builds with a build graph to order builds by dependencies is incorrect because a build graph manages dependency ordering inside CodeBuild but it does not make separate CodePipeline actions run in parallel across the stage and independent actions would still be serialized by the pipeline configuration.

Run CodeBuild inside a VPC and use dedicated hosts to increase throughput is incorrect because moving builds into a VPC or using dedicated hosts does not inherently parallelize pipeline actions and it can add networking overhead which may even increase latency.

Set the same runOrder for independent actions in a CodePipeline stage so they run concurrently and reduce total pipeline duration.

Store credentials in AWS Secrets Manager and resolve them in the template using CloudFormation dynamic references and Configure NoEcho on sensitive CloudFormation parameters to hide their values in stack outputs and events are correct because they prevent secret values from being recorded or displayed during CloudFormation deployments.

Store credentials in AWS Secrets Manager and resolve them in the template using CloudFormation dynamic references keeps secrets out of templates and stack metadata by resolving values at deploy time so the plaintext is not stored in stack parameters or shown by Describe calls or stack events. Using dynamic references causes CloudFormation to substitute secrets during provisioning without persisting the secret value in the stack.

Configure NoEcho on sensitive CloudFormation parameters to hide their values in stack outputs and events masks parameter values so the console and API responses show asterisks instead of the secret. NoEcho prevents accidental disclosure in stack events and Describe responses but you should still avoid logging plaintext or passing secrets to other services in clear text.

Turn on default encryption for the Amazon S3 bucket that stores the CloudFormation template is incorrect because encryption at rest protects the template file in the bucket but does not stop secrets from appearing in CloudFormation stack events or Describe APIs during deployment.

Use AWS Systems Manager Parameter Store secure strings and reference them by tag keys in the template is incorrect because CloudFormation does not support resolving parameters by tag keys. Parameter Store secure strings can be used via dynamic references by name or version but tags are not a supported resolution mechanism.

Enable AWS CloudTrail data event logging for S3 to audit template access is incorrect because CloudTrail adds auditing and visibility but it does not prevent sensitive values from surfacing in CloudFormation events or outputs during deployments.

Use dynamic references to fetch secrets at deploy time and set NoEcho on sensitive parameters so values do not appear in stack events or Describe responses.

The correct option is Configure the application to persist session state in an Amazon ElastiCache for Redis cluster. This approach externalizes session state so sessions survive instance replacements and scaling events while keeping latency very low.

Amazon ElastiCache for Redis is an in memory, centralized session store that delivers microsecond to low millisecond latency and high throughput. By persisting sessions in Redis the application avoids relying on instance local storage and does not force users to reauthenticate when blue green cutovers or immutable instance replacements occur. Redis also supports replication and clustering to maintain availability during failover and deployment operations.

Enable target group stickiness and store sessions on each instance’s attached storage is not reliable during immutable replacements because stickiness ties a user to a specific instance and that instance may be terminated or become unhealthy. Local attached storage is ephemeral and does not survive instance replacement.

Store session data in Amazon DynamoDB is a viable shared store and provides durability and scalability but it is not as low latency as an in memory cache. DynamoDB adds higher read and write latency compared with Redis so it does not best meet the requirement for the lowest possible latency.

Save authenticated session data in an Amazon S3 bucket introduces significantly higher per request latency and is not designed for frequent, low latency session reads and writes. S3 is suitable for durable object storage but it is not appropriate for high performance session management.

Use an external in memory cache like ElastiCache for Redis to persist session state for web apps behind load balancers. Externalize sessions to avoid relying on instance stickiness or local storage.

The most likely cause is An Auto Scaling scale-out event occurred during the deployment, so the new instances launched with the last successfully deployed revision. In an in-place CodeDeploy rollout the Auto Scaling group can add instances while the deployment is running and those newly launched instances will not receive the in-progress revision but will instead launch with the last successful revision which explains why the group ends up with four instances on the new build and two on the previous one while CodeDeploy shows success.

An Auto Scaling scale-out event occurred during the deployment, so the new instances launched with the last successfully deployed revision is correct because in-place deployments operate on instances that exist when the deployment starts and newly scaled out instances are not retroactively included in that deployment.

A CloudWatch alarm fired during the rollout is unlikely because an alarm firing does not cause some instances to remain on an older revision while the deployment reports success.

Two instances lacked IAM permissions to retrieve the revision from Amazon S3 would typically cause those instances to fail their lifecycle events and make the deployment fail rather than succeed, so this does not match the observed successful deployment with mixed versions.

The Auto Scaling group is using an outdated launch template or launch configuration version could affect how new instances are launched but CodeDeploy still targets instances in the deployment group and would attempt to update them, so this does not explain a successful deployment that leaves a subset of instances on the previous version.

To avoid this outcome pause scale out processes during in-place deployments or use a blue and green deployment model and then redeploy the latest revision to normalize versions across the fleet.

Pause Auto Scaling scale outs during in-place CodeDeploys or use blue/green deployments so new instances do not come up with an older revision.

Use AWS Systems Manager Parameter Store with CloudFormation parameters to resolve the latest AMI IDs and run stack updates when rolling out new images is the correct option because CloudFormation can resolve SSM Parameter Store values during stack create or update and you only need to update the parameter and run a stack update to deploy a new AMI.

Store golden AMI IDs in Systems Manager Parameter Store and reference them from your CloudFormation templates using dynamic references. When a new image is published update the parameter and then perform a stack update so CloudFormation resolves the current AMI value for new or updated instances. This approach avoids manual edits across templates and reduces configuration drift.

Integrate AWS CloudFormation with AWS Service Catalog to automatically source the newest AMI IDs for deployments is incorrect because Service Catalog is focused on governing approved products and portfolios and it does not automatically supply the latest AMI values to CloudFormation stacks.

Store the latest AMI IDs in Systems Manager State Manager and connect it to CloudFormation, then call UpdateStack whenever EC2 instances need refreshing is incorrect because State Manager is used to enforce desired state and compliance on instances and it is not intended as a parameter store for CloudFormation templates.

Create an Amazon EventBridge rule that invokes an AWS Lambda function to find the newest AMI and programmatically rewrite the template before each deployment is not recommended because programmatically rewriting templates is brittle and unnecessary when CloudFormation supports dynamic SSM parameter references and a simple stack update will pick up the new AMI.

Remember to use SSM Parameter Store dynamic references with CloudFormation and then run a stack update after you update the parameter to roll new AMIs without editing templates manually

Provision a new encrypted EBS volume, attach it to the instance, migrate the data, and retire the old unencrypted volume and Copy an unencrypted snapshot of the volume, encrypt the copied snapshot, and create a new volume from it are correct because both approaches produce an encrypted replacement without attempting in place encryption of the existing volume.

You cannot enable encryption on an existing Amazon EBS volume in place. Creating a new encrypted volume and copying the data to it lets the instance remain running while data is migrated and the old unencrypted volume is retired. The snapshot copy approach lets you copy the current unencrypted snapshot, mark the copy as encrypted, and then restore an encrypted volume from that copy to replace the original.

Enable EBS encryption by default in the account and rely on it to encrypt the existing unencrypted volume is incorrect because default encryption only affects newly created volumes and snapshots and does not retroactively encrypt volumes that already exist.

Unmount the current EBS volume, take a snapshot, encrypt that snapshot directly, and re-mount the same volume is incorrect because you cannot directly change an existing snapshot or volume from unencrypted to encrypted. The supported workflow is to copy the snapshot and encrypt the copy before creating a new encrypted volume.

Install a self-signed TLS certificate on the instance and use secure sessions to write data to the EBS volume is incorrect because TLS protects data in transit and does not provide encryption at rest for the EBS volume.

Remember that you cannot encrypt an existing EBS volume in place. Look for answers that create a new encrypted volume or an encrypted snapshot copy when the exam asks to protect data at rest.

The correct options are In the pipeline, add an AWS CodeDeploy action to roll out the latest build to the STAGE environment, insert a manual approval step for QA validation, then add a CodeDeploy action to push the approved release to PRODUCTION and Add a test action that runs unit and functional test suites in AWS CodeBuild and block promotion to PRODUCTION unless all tests pass.

The CodeBuild test action provides automated unit and functional verification so code defects fail the pipeline before they reach production. The CodeDeploy staged rollout with manual approval gives a preproduction deployment where QA can validate behavior and where a human gate prevents accidental promotion of a bad release. Together these steps catch functional issues automatically and allow controlled human validation before production.

Add a test action in the pipeline that uses Amazon GuardDuty to evaluate the build with a Runtime Behavior Analysis rules package before releasing to PRODUCTION is incorrect because GuardDuty is a threat detection service for AWS accounts and workloads and it does not run unit or functional tests or provide a runtime behavior test package for CI CD pipelines.

Add a test action that uses Amazon Macie to assess the build with a Runtime Behavior Analysis rules package and ensure it meets corporate security standards before promoting to PRODUCTION is incorrect because Macie focuses on discovering and protecting sensitive data and it does not validate application functionality or execution behavior in a pipeline.

Add a test action that uses Amazon Inspector to run a Runtime Behavior Analysis assessment to certify the application meets strict security benchmarks before deployment to PRODUCTION is incorrect because Inspector performs vulnerability and exposure assessments and does not replace unit or functional test suites for catching functional defects during deployment.

Combine automated tests that block promotion on failure with a preproduction deployment and a manual approval gate to catch functional defects before production.

Schedule a Lambda to refresh AWS Trusted Advisor service quota checks with EventBridge and add another EventBridge rule that matches Trusted Advisor limit events and publishes to an SNS topic subscribed by the operations manager is correct because Trusted Advisor already provides service quota checks and you can refresh those checks and route resulting events with EventBridge into an SNS topic for simple notifications.

Trusted Advisor offers built in service limit checks and the Support API lets you refresh checks on a schedule so you only need a lightweight Lambda to trigger the refresh and an EventBridge rule to match Trusted Advisor limit events and publish to SNS for the operations manager.

Build a Lambda function to enumerate account resources and compare usage against published service quotas, trigger it on a schedule with EventBridge, and publish alerts to an SNS topic is incorrect because that approach requires substantial custom inventory and limit mapping logic and therefore more development effort than using Trusted Advisor.

Create an AWS Config custom rule that evaluates service quota consumption and posts to an SNS topic, with a Lambda subscriber that notifies the operations manager is incorrect because AWS Config does not natively evaluate every service quota and you would still need custom evaluation logic so this is more complex than using Trusted Advisor checks.

Create a Lambda function to refresh AWS Health checks on a timer and configure an EventBridge rule that matches Trusted Advisor events and sends notifications to an SNS topic is incorrect because AWS Health does not report service quota consumption and combining Health refreshes with Trusted Advisor events is inconsistent and ineffective for quota monitoring.

For the least development effort use Trusted Advisor checks refreshed on a schedule and route events with EventBridge into SNS for notifications.

Create an Amazon EventBridge rule with source aws.health and event code AWS_RISK_CREDENTIALS_EXPOSED to start an AWS Step Functions state machine that runs three Lambda functions to remove the exposed access key, gather recent CloudTrail calls for that key, and send an SNS message to DevOps is correct because AWS Health emits the AWS_RISK_CREDENTIALS_EXPOSED event on the aws.health source and EventBridge can match that event to invoke a Step Functions workflow for immediate remediation and notification.

The correct design uses EventBridge to receive native AWS Health events and then uses Step Functions to orchestrate a sequence of Lambda tasks. Those tasks remove the exposed key, collect recent CloudTrail activity for investigation, and publish an Amazon SNS message to the DevOps team. This pattern supports direct, automated responses to health and risk events and keeps the remediation logic auditable and retryable within Step Functions.

Create an AWS Config rule to detect the AWS_RISK_CREDENTIALS_EXPOSED event across accounts using a data aggregator, and invoke an AWS Step Functions workflow with three Lambda tasks to revoke the key, compile recent CloudTrail activity, and publish an SNS alert is incorrect because AWS Config evaluates resource configuration and compliance and does not surface AWS Health events or detect exposed credentials on public repositories.

Use Amazon GuardDuty with Amazon Macie to find exposed IAM access keys on the Internet, then trigger AWS Step Functions to delete the key, review CloudTrail usage, and send an Amazon SNS notification is incorrect because GuardDuty and Macie do not scan public GitHub for leaked AWS keys in the way AWS Health reports those exposures. GuardDuty can detect malicious activity inside your AWS environment and Macie can help with sensitive data discovery in S3, but the AWS_RISK_CREDENTIALS_EXPOSED alert originates from AWS Health.

Set up an AWS Personal Health Dashboard rule for AWS_RISK_CREDENTIALS_EXPOSED and target Step Functions from EventBridge to orchestrate the key deletion, activity summary, and SNS alert is incorrect because the Personal Health Dashboard does not provide a separate rule engine. Actionable AWS Health events must be routed through EventBridge using the aws.health event source for automated workflows.

Watch for the AWS_RISK_CREDENTIALS_EXPOSED event from aws.health and route it with EventBridge to a Step Functions state machine that runs Lambdas to revoke the key, collect CloudTrail evidence, and send an SNS alert.

All DevOps questions come from certificationexams.pro and my Certified DevOps Engineer Udemy course.

The correct option is Configure Elastic Beanstalk to use immutable environment updates. This deployment type creates a separate, temporary Auto Scaling group for the new version behind the existing load balancer and only routes traffic to the new instances after they pass health checks.

Immutable environment updates satisfy the requirements to keep the current EC2 instances serving traffic during a release and to avoid any DNS or CNAME changes. The new fleet is validated before it takes traffic and the environment can discard the new instances on failure while the original fleet continues to handle requests.

Configure Elastic Beanstalk to use rolling deployments is unsuitable because it replaces instances in place in batches which can reduce overall capacity and expose users to mixed-version instances during the deployment and rollback requires another rolling action.

Configure Elastic Beanstalk to use rolling deployments with an additional batch preserves capacity better than pure rolling updates but it still touches the existing fleet during deployment which makes failure isolation and rollback slower and less clean than immutable updates.

Use a blue/green deployment and swap the environment CNAMEs normally gives zero downtime but it violates the constraint to avoid DNS or CNAME changes because a CNAME swap is required to cut traffic over to the new environment.

Tip pick immutable updates when you need a fresh validated fleet, no DNS changes, and fast failure isolation.

The correct option is Implement a readiness endpoint in the web service that verifies connectivity to the backend ECS service and the RDS database, and set the target group health check to that path. This causes the ALB to route traffic only to web tasks that report they can reach both the backend service and the database.

An application level readiness endpoint runs inside each web task and can perform checks against the backend ECS service and the RDS database. Pointing the ALB target group health check to that path makes the load balancer rely on the task reporting actual dependency reachability before sending traffic. This approach validates end to end connectivity and avoids false positives that come from lower level checks.

Configure Amazon Route 53 health checks for the web service and use Application Auto Scaling to replace failing ECS tasks and RDS instances is incorrect because Route 53 checks do not verify intra‑tier connectivity and Application Auto Scaling does not directly terminate or replace RDS instances.

Add the ECS web tasks and the RDS DB instance as targets in the ALB target group and use default TCP health checks is incorrect because you cannot register an RDS DB instance as an ALB target and TCP health checks do not confirm the application can reach its backend or database.

Create CloudWatch alarms on RDS active connections and ALB target response codes and instruct the ALB to mark targets unhealthy based on the alarm state is incorrect because ALBs do not change target health based on CloudWatch alarm states and those metrics are indirect signals that do not prove dependency reachability.

Use an application level readiness endpoint and make the ALB target group health check call that path so targets are healthy only when downstream dependencies are reachable.

The correct choice is Run the site on stateless EC2 in an Auto Scaling group and move SQL Server to Amazon RDS; use Amazon Kinesis Data Firehose to deliver click events to Amazon S3 for billing and a second Firehose delivery stream to load Amazon Redshift. This option keeps the web tier stateless and provides a managed path to deliver events to S3 for billing and to stage data for Redshift with minimal custom code.

Amazon Kinesis Data Firehose handles buffering, batching, compression, encryption, and retry logic and it can deliver directly to Amazon S3 and stage data for Amazon Redshift so you can load with COPY from an S3 staging area. Using Firehose reduces operational effort compared to building and maintaining consumers and it meets the requirement for near real time delivery into Redshift and S3 while supporting elastic web tier scaling.

Run the site on stateless EC2 in an Auto Scaling group and move SQL Server to Amazon RDS; publish click data with Amazon Kinesis Data Streams directly to Amazon S3 for billing and send another stream to Amazon Redshift is incorrect because Amazon Kinesis Data Streams does not natively write to S3 or Redshift. You would need consumer applications or additional services to persist and load the data which adds complexity and operational overhead.

Run the site on stateless EC2 in an Auto Scaling group and move SQL Server to Amazon RDS; use Amazon Athena to push click logs to Amazon S3 and also load them into Amazon Redshift is incorrect because Amazon Athena is a query service that reads data in S3 rather than a streaming ingestion mechanism. Athena cannot act as a pipeline to push logs into S3 or to load Redshift for near real time analytics.

Run the site on stateless EC2 in an Auto Scaling group and move SQL Server to Amazon RDS; send click events to Amazon MSK and rely on an AWS Glue crawler and catalog to populate Amazon Redshift is incorrect because Amazon MSK and AWS Glue would require running consumers and ETL jobs to move and transform data for Redshift. A Glue crawler only discovers and catalogs data and does not perform continuous loading which increases latency and operational burden.

When you need managed, low operational overhead streaming delivery to S3 and Redshift prefer Amazon Kinesis Data Firehose so you can avoid building and operating custom consumers.

The correct combination is CloudFormation drift detection does not support custom resources and AWS Config relies on the DetectStackDrift API and if calls are throttled or unavailable the rule is set to NON_COMPLIANT.

CloudFormation drift detection excludes custom resources so the managed rule cannot evaluate them. If your stacks include custom resources those resources will not be reported for drift and the managed rule cannot determine compliance for them.

AWS Config uses the DetectStackDrift API to obtain drift results for a stack. If DetectStackDrift calls are throttled or the API is unavailable the managed rule will default to NON_COMPLIANT and show the message you saw even when the CloudFormation console reports the stack as IN_SYNC. In that situation rerun the detection, stagger evaluations across regions and stacks, or request higher API quotas to avoid transient failures.

Enable AWS CloudTrail to capture configuration changes for custom resources is not a fix because CloudTrail records API activity but it does not perform drift detection nor does it change how the Config managed rule evaluates stack drift.

The IAM role specified in cloudformationRoleArn is missing permissions and triggers this exact error is unlikely because real permission issues produce explicit permission errors rather than the default NON_COMPLIANT message that indicates DetectStackDrift could not complete.

CloudFormation only reports drift for explicitly defined properties; define all properties on the custom resource to have it evaluated is partially true for supported resource types but it does not enable drift detection for custom resources which remain unsupported by drift detection.

When you see a default NON_COMPLIANT message remember that DetectStackDrift is used. Retry drift detection and consider staggering evaluations or increasing API quotas before changing stack definitions.

Configure DeletionPolicy: Snapshot on AWS::EC2::Volume resources to capture EBS snapshots on stack deletion and Set DeletionPolicy: Retain on the AWS::RDS::DBInstance so replacements and deletions do not remove the database are correct for the stated requirements.

Set DeletionPolicy: Retain on the AWS::RDS::DBInstance so replacements and deletions do not remove the database ensures that CloudFormation will not delete the RDS resource when the stack is deleted or when an update forces replacement. Keeping the resource or its identifier prevents accidental loss of the test data during operations that replace the underlying instance class.

Configure DeletionPolicy: Snapshot on AWS::EC2::Volume resources to capture EBS snapshots on stack deletion meets the audit requirement by instructing CloudFormation to create snapshots of EBS volumes when those volume resources are deleted. This produces preserved snapshots for review even after the stack is removed.

Turn on termination protection for the Amazon EC2 instances and the Amazon RDS DB instance is not sufficient because termination protection does not provide automatic snapshots and it does not address resource replacement behavior during updates.

Declare the DBInstanceClass property as immutable so the instance type cannot be changed during updates is not viable because CloudFormation does not support declaring arbitrary properties as immutable in that way and preventing legitimate updates is not the desired outcome.

Apply a CloudFormation stack policy that blocks updates to the DB instance and restricts SetStackPolicy to prevent overrides would interfere with necessary stack updates and still would not create EBS snapshots on deletion, so it does not satisfy the audit requirement.

Use DeletionPolicy to control resource lifecycles. Set Retain for long lived data stores and set Snapshot for EBS volumes that must be preserved on deletion.