AWS DevOps Engineer Certification Practice Exams

Orion BioTech uses AWS CodePipeline for application deployments, and an AWS CodeBuild stage runs database schema migrations. A recent compliance review found that CodeBuild retrieves the migration scripts from an Amazon S3 bucket using an unauthenticated public URL. The security team wants the pipeline hardened without disrupting automation. What is the most secure way to remediate this?

• ❏ A. Deny public access with an IAM policy, then provide an IAM user access key and secret in CodeBuild environment variables to download the scripts with the AWS CLI

• ❏ B. Remove public access using an S3 bucket policy and grant the CodeBuild project’s service role least-privilege S3 permissions, then pull the scripts with the AWS CLI

• ❏ C. Keep the bucket private and have CodePipeline generate short-lived S3 presigned URLs for each run so CodeBuild can download the scripts without any IAM permissions

• ❏ D. Encrypt the S3 bucket with SSE-KMS and enable CloudTrail logging while continuing to fetch the scripts anonymously

Kestrel Media, a digital publisher, stores photos, PDFs, and build artifacts in many Amazon S3 buckets across multiple accounts, and a new policy requires server access logging to be enabled on every bucket. The governance team now generates a nightly report listing resources that fail baseline controls, but the security team has been turning on logging bucket by bucket, which is slow and leaves gaps for many hours. How can a DevOps engineer implement an automated approach that enforces this requirement and shortens the window of noncompliance? (Choose 2)

• ❏ A. Create a Lambda function and configure it as the remediation action for the s3-bucket-logging-enabled rule to turn on logging

• ❏ B. Configure AWS Config auto-remediation for the rule s3-bucket-logging-enabled and select the managed action AWS-ConfigureS3BucketLogging

• ❏ C. Use AWS Security Hub to automatically enable server access logging on all S3 buckets

• ❏ D. Require the resourceId parameter when defining the remediation because auto-remediation cannot run without it

• ❏ E. Set the AutomationAssumeRole parameter to an IAM role trusted by Systems Manager and ensure the creator has iam:PassRole for that role

Solstice Analytics, a fintech startup, runs several web services on Amazon EC2 Auto Scaling groups across two AWS Regions to ensure resilience. They manage their environments with AWS CloudFormation for both infrastructure and deployments. Roughly every two weeks a new hardened AMI of their application is published, and engineers currently update AMI IDs manually in multiple templates, which is error prone and slows releases. What is the most suitable and cost-effective way to automate choosing the latest AMI during stack operations?

• ❏ A. Maintain AMI mappings in the template and use Amazon EventBridge to trigger AWS Lambda hourly to find new AMIs and rewrite the mapping

• ❏ B. Use CloudFormation conditions with cfn-init to detect a newer AMI and inject the ID into the launch template at instance boot

• ❏ C. Use a Lambda-backed CloudFormation custom resource to resolve the latest AMI ID and pass it into the launch template

• ❏ D. Run a small EC2 instance with a cron job every hour that checks for new AMIs and edits the template to update the launch template AMI

After a new deployment, customers of Meridian Retail’s web portal are receiving HTTP 502 errors. The application runs on Amazon EC2 instances in an Auto Scaling group distributed across three Availability Zones. Instances are being replaced within a couple of minutes because health checks mark them as unhealthy, preventing the engineer from logging in to inspect the issue. What should the engineer do to keep a failing instance available long enough to troubleshoot before it is terminated?

• ❏ A. Suspend the AZRebalance process in the Auto Scaling group to stop instance terminations

• ❏ B. Add an EC2 Auto Scaling lifecycle hook that moves instances entering Terminating into Terminating:Wait to allow troubleshooting access

• ❏ C. Enable instance scale-in protection on the Auto Scaling group to keep unhealthy instances from being replaced

• ❏ D. Create a snapshot of the root EBS volume, build an AMI, and launch a separate EC2 instance for analysis

You work for a video streaming startup that runs a stateless web tier in an Amazon EC2 Auto Scaling group behind an Application Load Balancer. The application uses Amazon RDS Multi-AZ for its database. The application health endpoint reports the target as unhealthy whenever it cannot connect to the database. Because the Auto Scaling group relies on ALB target group health checks, instances fail health checks and are terminated about two minutes after they start. You need to remove one newly launched instance from traffic and keep it available for an indefinite troubleshooting session without it being replaced by the group, what should you do?

• ❏ A. Suspend the Launch process

• ❏ B. Enable termination protection for the EC2 instance

• ❏ C. Place the instance into Standby immediately after it becomes InService

• ❏ D. Create a termination lifecycle hook and troubleshoot during the Terminating:Wait phase

Marina Analytics has provisioned a new AWS Elastic Beanstalk environment as a staging area for performance and QA checks of application updates. Developers push changes frequently, and the team expects to roll out new builds 3 to 5 times per day. The priority is to make each build available in staging as fast as possible while keeping costs low and accepting brief downtime in this nonproduction tier. Which deployment approach should they choose?

• ❏ A. Rolling deployment policy for new versions

• ❏ B. Blue/green deployment strategy with environment swap

• ❏ C. All at once deployment policy for new versions

• ❏ D. Immutable deployment policy on fresh instances

NovaStream Studios runs a video platform on a fleet of Amazon EC2 instances behind an Application Load Balancer, with media stored in Amazon S3. The security team uses AWS WAF on the ALB and must deliver a detailed access report every 180 days that includes each web request and the rules that were matched. They want you to set up logging now so future traffic is captured with full request context. What should you do?

• ❏ A. Enable AWS WAF logging to Amazon CloudWatch Logs and require the log group name to begin with aws-waf-logs-

• ❏ B. Enable AWS WAF logging and deliver logs directly to an Amazon S3 bucket whose name starts with aws-waf-logs-, optionally using SSE-S3 or a customer managed KMS key

• ❏ C. Configure AWS WAF to publish logs to Amazon Kinesis Data Firehose that reads from a Kinesis Data Streams stream, and name the Firehose delivery stream with the aws-waf-logs- prefix

• ❏ D. Send AWS WAF logs to an S3 bucket encrypted with an AWS managed KMS key

Aurora FinServ recently moved its public API from an EC2 Auto Scaling group behind an Application Load Balancer to Amazon API Gateway with AWS Lambda. In the old setup, releases were canaried by sending about 10% of requests to the new build for 30 minutes while monitoring CloudWatch errors, then shifting to full traffic. With Lambda, updating the target version causes an immediate switchover on the alias. How can the team implement a gradual rollout for Lambda versions without standing up duplicate API Gateway stages?

• ❏ A. Use Amazon Route 53 weighted routing with two API Gateway endpoints

• ❏ B. Configure a Lambda alias with weighted routing to split traffic between function versions

• ❏ C. Use CodeDeploy to perform a rolling update of the $LATEST Lambda function

• ❏ D. Enable an API Gateway canary release across two stages to route a small share to the new version

A platform engineer at Trailblaze Retail is designing a serverless API that uses Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. The company wants the workload to run across at least three AWS Regions so customers in each area get consistently low-latency responses. What should the engineer implement to meet these requirements?

• ❏ A. Deploy a single Region API Gateway edge-optimized endpoint and integrate with a regional Lambda function; store data in a DynamoDB global table

• ❏ B. Create API Gateway APIs in two Regions and use Amazon Route 53 failover routing with health checks; integrate each API with a Lambda function in the same Region and read and write to a DynamoDB global table

• ❏ C. Create API Gateway APIs in each target Region and use Amazon Route 53 latency-based routing with health checks; integrate each API with a same-Region Lambda function and access a DynamoDB global table

• ❏ D. Create API Gateway APIs in each Region and add Route 53 health checks for each record; integrate each API with a local Lambda function and update a DynamoDB table that exists only in that Region

Aster Learning runs a multi-account AWS Organizations environment with six member accounts and operates a data intake service on Amazon EC2 instances spread across three Auto Scaling groups in private subnets without internet egress. Interface VPC endpoints for AWS Systems Manager are already provisioned, and the fleet uses a hardened custom AMI. Operations teams need a centralized and automated way to log in for troubleshooting, and the security team must be alerted whenever someone establishes a shell session on any instance. Which approach best meets these needs while keeping the instances isolated from the internet?

• ❏ A. Stand up a NAT gateway and a hardened bastion host, allow SSH from the bastion to the Auto Scaling groups, install SSM Agent, use Session Manager for logins, stream to CloudWatch Logs, export to S3, and trigger S3 notifications to SNS

• ❏ B. Use AWS Systems Manager Automation to rebuild the AMI with the newest SSM Agent and apply a service control policy through AWS Config so instances can reach Systems Manager, then send Session Manager logs to S3 and notify the security team with Amazon SNS

• ❏ C. Rebuild the custom AMI with EC2 Image Builder to include the current SSM Agent, attach the AmazonSSMManagedInstanceCore instance profile to the Auto Scaling groups, use Systems Manager Session Manager for centralized access, write session logs to Amazon S3, and trigger an SNS alert from S3 event notifications

• ❏ D. Use EC2 Instance Connect for centralized access by distributing short-lived SSH keys, store the session output in S3, and notify the security team with Amazon SNS

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

BlueRidge Analytics uses AWS CodePipeline to orchestrate multiple test suites, where two tests run as Docker containers in CodeBuild and a third runs as a Lambda function executing Node.js. The tests make numerous HTTP calls and metrics show they are network bound rather than CPU bound. The pipeline now takes about 90 minutes because these test actions run one after the other, which discourages adding more tests. The pipeline is defined and updated through CloudFormation. What change should you recommend to reduce the total pipeline time?

• ❏ A. Increase the CodeBuild compute type and allocate more memory to the Lambda function

• ❏ B. Give the test actions in the same stage the same runOrder value so they execute in parallel

• ❏ C. Set a higher Lambda reserved concurrency and raise the account’s concurrent CodeBuild builds limit

• ❏ D. Enable AWS CloudFormation StackSets to run the pipeline actions in parallel

Wavecrest Labs runs a multi-account AWS environment and needs to roll out several CloudFormation-based applications to dozens of member accounts across two Regions. Multiple platform administrators in separate administrator accounts must be able to create and maintain these deployments while keeping ongoing setup to a minimum. What should the team do to meet these goals? (Choose 2)

• ❏ A. Create an AWS Organizations organization with all features turned on and enroll every account

• ❏ B. Manually create stacks per account using cross-account IAM roles

• ❏ C. Enable trusted access for AWS Organizations and roll out CloudFormation StackSets from the management account

• ❏ D. Set up an organization with only consolidated billing and invite all accounts

• ❏ E. Enable trusted access and deploy StackSets using self-managed permissions

A regional logistics startup operates its public web tier on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer across three Availability Zones. At times, new instances fail during the launch phase, and the on-call team wants instant alerts each time a launch attempt fails. What configuration should be implemented to meet this requirement?

• ❏ A. Add an Auto Scaling health check that triggers an AWS Lambda function when instance health is impaired

• ❏ B. Create an Amazon EventBridge rule that filters CloudTrail RunInstances error events and publishes to an Amazon SNS topic

• ❏ C. Configure Amazon EC2 Auto Scaling to send notifications to an Amazon SNS topic for the EC2_INSTANCE_LAUNCH_ERROR event

• ❏ D. Create an Amazon CloudWatch alarm to notify an SNS topic when an Amazon EC2 instance status check fails

An international streaming platform operates roughly 80 AWS accounts under AWS Organizations. Each account writes application logs to Amazon CloudWatch Logs, and the company wants to centralize and archive all logs in a single security-owned account with minimal ongoing storage provisioning. What approach should a DevOps engineer implement to securely funnel logs from every account into the central archive?

• ❏ A. Create a cross-account CloudWatch Logs destination in the logging account and route it to Amazon Kinesis Data Streams, then attach a Kinesis Data Firehose delivery stream targeting Amazon S3

• ❏ B. Configure a CloudWatch Logs destination in the central account and subscribe a Kinesis Data Firehose delivery stream that writes directly to an Amazon S3 bucket

• ❏ C. Create a cross-account CloudWatch Logs destination in the central account and subscribe an AWS Lambda function that forwards log batches to Amazon OpenSearch Service

• ❏ D. Set up a CloudWatch Logs destination in the central account and subscribe a Kinesis Data Firehose delivery stream to load the data into Amazon Redshift

BrightPixel Media runs Jenkins in its on-premises data center to manage CI/CD pipelines and is migrating to AWS to gain elasticity and reduce operational effort. The team needs the Jenkins environment to be highly available and fault tolerant, while build execution should scale on demand in a cost-effective way. Which approach should be implemented on AWS to meet these goals?

• ❏ A. Run Jenkins as a multi-master cluster in a single AZ, managed by an Auto Scaling group, and configure builds to run on EC2-based Jenkins agents

• ❏ B. Run Jenkins as a multi-master installation across multiple AZs and use the AWS CodeBuild plugin for Jenkins so builds execute in CodeBuild

• ❏ C. Run Jenkins as a multi-master installation across multiple AZs and attach an Auto Scaling group of EC2 instances as Jenkins agents for build execution

• ❏ D. Run Jenkins as a multi-master cluster in one AZ with an Auto Scaling group and use the AWS CodeBuild plugin to offload builds

A regional streaming company has a Java Spring service running on AWS Elastic Beanstalk that connects to an Amazon RDS for PostgreSQL database via environment variables and applies schema updates with a migration tool like Flyway. During a rolling update to 5 instances, the deployment fails because each instance attempts to run the migration at the same time against the database. What change should you make so that the migration runs only once per deployment and avoids concurrent execution?

• ❏ A. Add an .ebextensions/db-migration.config with a commands block that runs the migration and set leader_only: true

• ❏ B. Use AWS Systems Manager Run Command to invoke the migration script across the Auto Scaling group before the update

• ❏ C. Add an .ebextensions/db-migration.config with a container_commands block for the migration and set leader_only: true

• ❏ D. Add an .ebextensions/db-migration.config with a container_commands block and set lock_mode: true

PolarVector Systems, a multinational logistics firm, runs an internal planning platform on AWS. The web tier uses an Auto Scaling group of Amazon EC2 instances across three Availability Zones behind an Application Load Balancer, the database layer is Amazon RDS for MySQL with Multi-AZ, and static assets live in Amazon S3. All infrastructure is managed with AWS CloudFormation. Three weeks ago, a regional outage drill showed slow recovery and notable data loss. What should the DevOps engineer implement to achieve a multi-region disaster recovery strategy with the lowest recovery time and minimal data loss?

• ❏ A. Deploy the stack to a second region with CloudFormation and create an RDS Multi-AZ standby there with S3 cross-region replication, rely on automatic failover, and increase Auto Scaling capacity

• ❏ B. Deploy the stack in another region with CloudFormation, schedule cross-region snapshot copies every 12 hours using Lambda and EventBridge, replicate S3 objects to S3 Glacier Flexible Retrieval, and restore the database during an outage

• ❏ C. Pre-provision the stack in a different region with CloudFormation, create a cross-region RDS Read Replica, enable S3 cross-region replication to a destination bucket, and promote the replica during failover while pre-scaling the Auto Scaling group

• ❏ D. Deploy the stack in a second region with CloudFormation, enable S3 cross-region replication, and configure an Application Load Balancer to shift traffic to the other region during an outage while keeping RDS in Multi-AZ

Helios Retail is preparing to launch a Python Flask service and wants a hardened base AMI that already includes the needed Python runtime and the latest OS patches. The image must be created in a repeatable workflow and be programmatically discoverable from every AWS region in the company account to support scalable deployments. What approach should you recommend? (Choose 2)

• ❏ A. Run an AWS Step Functions workflow that only copies the AMI ID value in Systems Manager Parameter Store to other regions using the same parameter name

• ❏ B. Author an AWS Systems Manager Automation runbook to consistently build the AMI

• ❏ C. Amazon Inspector

• ❏ D. AWS Backup cross-Region copy for EC2 to distribute the AMI and IDs

• ❏ E. Create a Lambda function that copies the AMI into each target region and writes the region-specific AMI ID to Systems Manager Parameter Store with a common key name

A digital publishing startup, BrightWave Media, runs its main web tier in an Auto Scaling group with 12 Amazon EC2 instances spread across two Availability Zones. Off-hours average CPU sits near 12 percent, while weekday business hours regularly drive it to about 55 percent and this pattern is predictable. The team wants to raise instance utilization, lower costs, and preserve application availability. What should they implement?

• ❏ A. Convert the Auto Scaling group to Spot Instances only with a capacity-optimized allocation strategy and remove existing scaling policies

• ❏ B. Create a target tracking policy to hold average CPU at 70% and add a scheduled action that invokes a Lambda function to terminate 8 instances after peak hours

• ❏ C. Configure a target tracking scaling policy to maintain 70% CPU and add scheduled actions that set the group minimum to 5 during busy hours and to 2 during off-hours

• ❏ D. Use a CloudFormation UpdatePolicy to govern peak and off-peak behavior and have the Auto Scaling group trigger stack updates via SNS notifications

A platform engineer at Northwind Retail modified an AWS CloudFormation template for a microservice stack during a 30 minute maintenance window. The stack update failed, CloudFormation attempted to restore the prior state, but the rollback also failed and the stack is now in UPDATE_ROLLBACK_FAILED. Which factors are most likely behind this outcome? (Choose 2)

• ❏ A. An interface VPC endpoint for CloudFormation in the VPC was unavailable

• ❏ B. Resources were changed outside of CloudFormation and the template was not updated

• ❏ C. The update was deployed without first creating and executing a change set

• ❏ D. AWS Config was not enabled in the account or Region

• ❏ E. The IAM user or role that ran the update lacked some required permissions

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

Aurora Goods operates its flagship storefront using two Auto Scaling groups behind two separate Application Load Balancers, and a Route 53 alias points to the ALB that currently fronts the newest release. Releases alternate between the two stacks by deploying to the idle stack and then switching the DNS alias, but some customers do not respect DNS updates and continue sending traffic to the previously active ALB, hitting an inactive stack. The company wants to reduce complexity, keep costs low, and eliminate this client behavior. What should you recommend?

• ❏ A. AWS Global Accelerator in front of both ALBs to shift traffic using endpoint weights

• ❏ B. Lower the Route 53 alias record TTL to 45 seconds before each release, switch DNS, then restore the original TTL

• ❏ C. Use a single ALB with two target groups mapped to the two ASGs, deploy to the idle ASG, then flip the ALB listener rule to the new target group while keeping Route 53 pointed at the one ALB

• ❏ D. Run an NGINX sidecar on every instance to proxy requests from the inactive ALB to the active ALB

Helios Labs runs an Amazon ECS service with Service Auto Scaling on a fleet of 18 Amazon EC2 instances. Each time the team ships a release, they push a new container image to a private Docker registry and then stop and relaunch all ECS tasks to pick up the update. Occasionally, the newly started tasks still come up with the previous image instead of the new one. As the DevOps engineer, what should you do to ensure the replacement tasks consistently use the current image?

• ❏ A. Migrate the image repository to Amazon ECR

• ❏ B. Restart the Amazon ECS agent on the EC2 container instances

• ❏ C. Pin the image by repository-url/image@digest in the task definition and manually update the SHA-256 for each release

• ❏ D. Use the latest tag in the task definition

Helios Digital runs many AWS accounts under AWS Organizations and wants to automatically surface suspicious behavior across all members, including repeated SSH brute-force attempts and EC2 instances distributing malware. The security team must centralize all detections in a dedicated security account for auditing, with events persisted to an Amazon S3 bucket. What should a DevOps Engineer implement to achieve this?

• ❏ A. Enable Amazon Macie in all accounts with the security account as the Macie administrator, and use Amazon EventBridge to send findings to Amazon Kinesis Data Firehose that delivers to the S3 bucket

• ❏ B. Enable Amazon GuardDuty only in the security account as the delegated administrator, and forward findings via Amazon EventBridge to Amazon Kinesis Data Streams with an AWS Lambda consumer that writes to S3

• ❏ C. Enable Amazon GuardDuty across all organization accounts with the security account as the delegated administrator, and route GuardDuty findings from Amazon EventBridge to Amazon Kinesis Data Firehose that writes to the S3 bucket

• ❏ D. Use AWS Security Hub as the delegated administrator in the security account to aggregate findings from member accounts and export them via Amazon EventBridge to Amazon Kinesis Data Firehose for S3 storage

A nonprofit media archive runs a monolithic workload on a single Amazon EC2 instance with attached Amazon EBS volumes. The operations team wants the instance to recover automatically within a few minutes and avoid significant data loss if the underlying host experiences a power outage or loses network connectivity. Which approach best meets this need?

• ❏ A. Create an Amazon EC2 Auto Scaling group with minimum, maximum, and desired capacity set to 1

• ❏ B. Configure an Amazon CloudWatch alarm on the StatusCheckFailed_System metric to trigger the EC2 recover action

• ❏ C. Create an Amazon CloudWatch alarm on the StatusCheckFailed_Instance metric to initiate the EC2 reboot action

• ❏ D. Use AWS Backup to take EBS snapshots every 15 minutes

A regional architecture studio runs an AWS Storage Gateway appliance at a satellite office. The appliance is configured as a file gateway in front of an Amazon S3 bucket that stores design files consumed by staff over SMB. At 01:30 local time each night, an automated job uploads hundreds of new objects directly to the bucket. The following morning, employees using the share cannot see the new files even though they are present in S3. What should a DevOps engineer do to ensure the new files become visible to users?

• ❏ A. Enable S3 same-Region replication so bucket changes propagate to the file gateway share

• ❏ B. Use AWS DataSync to copy new S3 objects to the on-premises NFS or SMB share

• ❏ C. Create an Amazon EventBridge schedule that invokes an AWS Lambda function to call RefreshCache for the file share

• ❏ D. Switch the appliance to cached Volume Gateway and wire S3 event notifications to update the gateway when objects arrive

BlueOrbit Games requires that any Amazon Machine Image shared between accounts be encrypted with a customer managed AWS KMS key. The source account holds an older custom AMI that is currently unencrypted, and a separate target account will launch an Auto Scaling group using that AMI. The source account already has a customer managed KMS key. How should you enable the target account to launch from the shared AMI while meeting the company’s policy? (Choose 2)

• ❏ A. In the source account, copy the AMI and encrypt it with the default AWS managed key, then share the new AMI with the target account

• ❏ B. In the source account, create an encrypted copy of the AMI using the customer managed KMS key, update that key policy to let the target account create grants, and share the encrypted AMI

• ❏ C. Only update the AMI launch permissions to include the target account and proceed without changing any KMS policies or grants

• ❏ D. In the target account, create a KMS grant that allows the EC2 Auto Scaling service-linked role to use the source account key for EBS encryption

• ❏ E. Create a new CMK in the target account and rely on AWS Resource Access Manager to share the AMI and re-encrypt it automatically

NovaCart, an online marketplace, uses a fully automated CI/CD pipeline to roll out database engine and schema upgrades in production. A recent run started without manual input and advanced normally, but after 35 minutes the pipeline froze and the deployment failed. The postmortem showed a scheduled AWS regional maintenance event caused the interruption. What should the DevOps engineer implement to avoid this recurring while minimizing delay and cost?

• ❏ A. Configure CodePipeline to auto-retry the entire workflow whenever a stage fails

• ❏ B. Schedule database maintenance windows to avoid announced AWS Region maintenance

• ❏ C. Add a Lambda gate in CodePipeline that calls the AWS Health API for the target Region and stops the run early when an active event could affect the deployment

• ❏ D. Perform blue green database upgrades by creating a standby database and switching traffic after the upgrade completes

Polaris Insights, a retail analytics startup, wants to roll out a Node.js service on AWS while continuing to run part of the workload in its data center. They plan a hybrid deployment where the application runs on on-premises Linux servers and a fleet of On-Demand Amazon EC2 instances that scale for busy periods. The processes must fetch database credentials without embedding them in code or artifacts, with encryption at rest and during transport. What is the most secure way to automate this deployment end to end?

• ❏ A. Put the database secrets in the CodeDeploy appspec.yml file, restrict access with a narrowly scoped IAM policy, and roll out to EC2 and on-premises servers with AWS CodeDeploy

• ❏ B. Store credentials as a SecureString in AWS Systems Manager Parameter Store and attach an IAM policy directly to on-premises machines and the EC2 instance profiles to allow decryption, then deploy with AWS CodeDeploy

• ❏ C. Keep credentials in AWS Systems Manager Parameter Store as a SecureString encrypted with KMS, grant access via an IAM role attached to the CodeDeploy-managed instance profiles and use register-on-premises-instance so on-prem servers assume the role, then deploy packages with AWS CodeDeploy

• ❏ D. Use AWS Secrets Manager and grant the CodeDeploy service role permission to read the secret so it can push the value to targets during deployment

An e-commerce analytics firm, Orion Metrics, manages an EC2 Auto Scaling group with AWS CloudFormation. The group currently runs 12 production instances and now has an updated launch template that references a new AMI and instance type. How should a DevOps engineer update the stack so the group adopts the new launch template version without downtime while maintaining at least 6 instances in service at all times?

• ❏ A. AWS CodeDeploy

• ❏ B. Configure an UpdatePolicy with AutoScalingRollingUpdate and set MinInstancesInService

• ❏ C. Set UpdateReplacePolicy and specify MinSuccessfulInstancesPercent and MaxBatchSize

• ❏ D. Enable AutoScalingReplacingUpdate and tune WaitOnResourceSignals and PauseTime

You are the DevOps engineer at Aurora Games and must build a nightly EBS backup process that runs at 00:30 UTC. The workflow should create a snapshot of a chosen EBS volume, copy it to a second AWS Region, and if that Region is unavailable because of an incident, attempt a copy to a third Region instead. The solution must email the final outcome and preserve a detailed audit trail of each run. Which approach provides an efficient and fail-safe implementation?

• ❏ A. An Amazon EventBridge schedule that invokes a single AWS Lambda function for all steps and uses AWS Config for auditing

• ❏ B. An Amazon EC2 instance running a cron job and Python script to snapshot and copy across Regions, with step status stored in Amazon DynamoDB

• ❏ C. AWS Step Functions orchestrating AWS Lambda tasks, triggered by Amazon EventBridge with notifications via Amazon SNS

• ❏ D. Amazon Managed Workflows for Apache Airflow

A media-streaming startup, LumaStream, needs to enrich AWS Network Firewall flow logs with additional metadata and then store the results in an existing Amazon S3 bucket named nf-logs-lake. Right now the firewall delivers logs straight to S3, and analysts query them with Amazon Athena. The team wants the transformation to occur before the data is written to S3, with near real-time delivery in under 90 seconds and minimal operational overhead. What approach should they implement?

• ❏ A. Configure Amazon S3 Event Notifications to launch an AWS Glue job that processes new log objects and writes the enriched output back to the same bucket

• ❏ B. Create an S3 object-created trigger that invokes an AWS Lambda function to reformat the logs and save transformed copies to the existing bucket while preventing recursive writes

• ❏ C. Create an Amazon Kinesis Data Firehose delivery stream with a Lambda transformation, set the destination to the current S3 bucket, and update Network Firewall to publish logs to the stream

• ❏ D. Ingest records into Amazon Kinesis Data Streams and attach a Lambda consumer to enrich them before writing to the S3 bucket

At Northwind Labs, you run a mission-critical portal on AWS Elastic Beanstalk using the Rolling policy. The environment spans two Availability Zones and includes an attached Amazon RDS instance that the application relies on. A recent major release failed during deployment, and restoring service required manually redeploying the prior build, causing over 30 minutes of disruption. For upcoming releases, you need a deployment approach that keeps the current fleet serving traffic until the new version is verified healthy and that can auto-rollback quickly without re-deploying the old build or changing the database attachment. Which approach should you choose?

• ❏ A. Implement blue/green deployment in Elastic Beanstalk while keeping the RDS instance tightly coupled to the environment

• ❏ B. Use Rolling with additional batch as the deployment policy for future deployments

• ❏ C. Configure Immutable as the deployment policy in the Elastic Beanstalk environment for upcoming releases

• ❏ D. Set All at once as the deployment policy for the Elastic Beanstalk environment

Nebula Systems Group, a global engineering consultancy, runs five regional facilities that upload compliance and finance documents to a central portal in AWS. The portal stores files in an Amazon S3 bucket named ops-helix-ledger, and an internal analytics team retrieves reports through a CloudFront distribution that uses this bucket as its origin. A DevOps lead observes that staff are downloading files using both CloudFront URLs and direct S3 object links. Security requires a redesign so that users cannot bypass CloudFront and direct access to S3 object URLs is blocked. What should the engineer implement to satisfy this requirement?

• ❏ A. Require CloudFront Signed URLs and create a key pair, then grant the public key permission to read objects in the S3 bucket

• ❏ B. Enable field-level encryption on the CloudFront distribution and remove users’ permissions to fetch objects via S3 URLs

• ❏ C. Create an Origin Access Control and attach it to the S3 origin in CloudFront, then update the ops-helix-ledger bucket policy to allow only requests from that distribution

• ❏ D. Enable Amazon S3 Block Public Access on the bucket to force downloads through CloudFront

Novatek Logistics runs mission-critical services on Amazon EC2 instances within a dedicated Amazon VPC. The business expects round-the-clock availability with no unexpected downtime other than approved maintenance windows. The platform team needs an automated alert whenever any instance changes state, such as moving to stopped, terminated, or pending. What is the most effective approach to meet this requirement?

• ❏ A. Configure an Amazon CloudWatch alarm on the StatusCheckFailed_System metric and choose the EC2 recover action

• ❏ B. Subscribe to AWS Health event notifications for EC2 and deliver messages through an Amazon SNS topic

• ❏ C. Create an Amazon EventBridge rule for EC2 Instance State-change Notification events and target an Amazon SNS topic

• ❏ D. Configure an Amazon CloudWatch alarm on the StatusCheckFailed_Instance metric and select the EC2 reboot action

A telemedicine SaaS provider runs most workloads on Amazon EC2 and must ensure that production instances originate only from an approved set of AMI IDs curated by the Security Governance team. The engineering CI/CD system regularly spins up short-lived EC2 instances in a staging VPC using experimental AMIs for validation. The Lead DevOps Engineer needs a solution that enforces this guardrail without slowing down or blocking developer pipelines. What approach should be taken to meet the goal with minimal disruption? (Choose 2)

• ❏ A. Run periodic Amazon Inspector scans with a custom assessment to detect instances not based on approved AMIs, then terminate and email the teams

• ❏ B. Use Amazon EventBridge to trigger an AWS Lambda function every hour to enumerate running EC2 instances in the staging and production VPCs, compare their AMI IDs against the approved list, publish to Amazon SNS, and automatically terminate noncompliant instances

• ❏ C. Apply an AWS Organizations SCP that denies ec2:RunInstances unless the AMI is in the approved list

• ❏ D. Enable AWS Config with the approved-amis-by-id managed rule and attach an AWS Systems Manager Automation remediation to stop or terminate noncompliant instances and notify via Amazon SNS

• ❏ E. Attach IAM policies that only allow ec2:RunInstances with the preapproved AMI list

The correct choice is Remove public access using an S3 bucket policy and grant the CodeBuild project’s service role least-privilege S3 permissions, then pull the scripts with the AWS CLI. This option eliminates anonymous reads and lets CodeBuild use its service role to retrieve migration scripts securely.

That approach blocks public access at the bucket level and grants only the minimal S3 permissions the CodeBuild service role needs. CodeBuild will assume its role and obtain temporary credentials automatically so there are no long lived keys in the pipeline. This is auditable with CloudTrail and aligns with least privilege while preserving automation.

Deny public access with an IAM policy, then provide an IAM user access key and secret in CodeBuild environment variables to download the scripts with the AWS CLI is weaker because S3 bucket policies and Block Public Access are the controls that stop anonymous reads and embedding long lived credentials in build environment variables increases exposure and management overhead.

Keep the bucket private and have CodePipeline generate short-lived S3 presigned URLs for each run so CodeBuild can download the scripts without any IAM permissions can work in some workflows but presigned URLs are bearer tokens that can leak in logs or outputs and they add operational complexity compared with role based access that is auditable and automatically rotated.

Encrypt the S3 bucket with SSE-KMS and enable CloudTrail logging while continuing to fetch the scripts anonymously is insufficient because encryption and logging do not prevent unauthenticated reads. The bucket must be made nonpublic and access must be granted via least privilege IAM roles to stop anonymous access.

Use least-privilege IAM roles for CodeBuild and disable public S3 access with bucket policies or S3 Block Public Access to secure CI/CD artifacts without embedding static credentials.

The correct choices are Configure AWS Config auto-remediation for the rule s3-bucket-logging-enabled and select the managed action AWS-ConfigureS3BucketLogging and Set the AutomationAssumeRole parameter to an IAM role trusted by Systems Manager and ensure the creator has iam:PassRole for that role.

Configure AWS Config auto-remediation for the rule s3-bucket-logging-enabled and select the managed action AWS-ConfigureS3BucketLogging is correct because the AWS managed remediation uses a Systems Manager Automation runbook that enables server access logging on noncompliant buckets as soon as AWS Config flags them and this removes the need for custom scripts while reducing the window of noncompliance.

Set the AutomationAssumeRole parameter to an IAM role trusted by Systems Manager and ensure the creator has iam:PassRole for that role is correct because the Automation runbook must assume an IAM role that has permissions to modify S3 settings and the user who configures the remediation needs iam:PassRole to allow Systems Manager to use that role during remediation.

Create a Lambda function and configure it as the remediation action for the s3-bucket-logging-enabled rule to turn on logging is not the best choice because a managed remediation already exists and writing and maintaining custom Lambda code adds operational overhead and potential for errors.

Use AWS Security Hub to automatically enable server access logging on all S3 buckets is incorrect because Security Hub aggregates and prioritizes findings and it does not directly apply S3 configuration changes without separate automation integrations.

Require the resourceId parameter when defining the remediation because auto-remediation cannot run without it is incorrect because AWS Config remediations can receive dynamic resource identifiers from the evaluation and you do not always need to hardcode a resourceId.

Use managed Systems Manager Automation runbooks with AWS Config when available and verify the AutomationAssumeRole trust relationship and that the creator has iam:PassRole to avoid remediation failures.

The correct and most suitable choice is Use a Lambda-backed CloudFormation custom resource to resolve the latest AMI ID and pass it into the launch template. This option ensures CloudFormation obtains the AMI at stack create or update and avoids manual edits and continuous polling.

Using the Lambda-backed custom resource integrates the lookup into the deployment lifecycle so the AMI resolution runs only when the stack changes. This keeps costs low because the Lambda executes on demand and it keeps CloudFormation as the single source of truth for the launch template input.

Maintain AMI mappings in the template and use Amazon EventBridge to trigger AWS Lambda hourly to find new AMIs and rewrite the mapping is incorrect because scheduled scans add ongoing cost and complexity and they usually run with no changes. The approach also increases the chance of accidental template edits and out of band changes.

Use CloudFormation conditions with cfn-init to detect a newer AMI and inject the ID into the launch template at instance boot is incorrect because cfn-init runs on an instance after it boots and cannot change which AMI was used to create that instance. That makes it unsuitable for selecting the AMI at deployment time.

Run a small EC2 instance with a cron job every hour that checks for new AMIs and edits the template to update the launch template AMI is incorrect because a continuously running instance is more expensive and operationally heavier than a serverless, on demand lookup. The cron approach also introduces another maintenance burden and a slower feedback loop for deployments.

When you need values resolved at deployment time prefer Lambda-backed custom resources or store AMI IDs in SSM Parameter Store and reference them from CloudFormation so you avoid constant polling and long lived infrastructure.

Add an EC2 Auto Scaling lifecycle hook that moves instances entering Terminating into Terminating:Wait to allow troubleshooting access is correct because it explicitly pauses the termination process so you can access the instance for diagnosis.

Add an EC2 Auto Scaling lifecycle hook that moves instances entering Terminating into Terminating:Wait to allow troubleshooting access works by moving the instance into a wait state when termination is initiated and Terminating:Wait provides a bounded window to connect, collect logs, and run live troubleshooting. You can extend that window by sending heartbeats and you can configure the timeout to meet your investigation needs.

Suspend the AZRebalance process in the Auto Scaling group to stop instance terminations is wrong because AZRebalance only helps redistribute instances across Availability Zones and it does not prevent terminations caused by failed health checks.

Enable instance scale-in protection on the Auto Scaling group to keep unhealthy instances from being replaced is incorrect because scale in protection prevents only scale in events and it does not stop the Auto Scaling group from replacing instances that fail health checks.

Create a snapshot of the root EBS volume, build an AMI, and launch a separate EC2 instance for analysis is not suitable for live debugging because snapshots and AMIs do not capture in memory state or transient issues and creating and launching a new instance may take longer than the time available before termination.

Use lifecycle hooks with Terminating:Wait to pause termination long enough to connect and collect diagnostics and send heartbeats to extend the window if needed.

The correct option is Place the instance into Standby immediately after it becomes InService. This action keeps the instance in the Auto Scaling group while removing it from the load balancer target groups and from normal scaling activities so it will not serve traffic and it can remain available for an indefinite troubleshooting session.

Using Place the instance into Standby immediately after it becomes InService lets you preserve the instance for debugging while preventing it from receiving traffic and from being automatically replaced by the group. You can investigate the database connectivity or application issues without the instance being terminated and you can return it to service when ready.

Suspend the Launch process is ineffective because suspending launches only stops new instance launches and it does not prevent the Auto Scaling group from terminating an unhealthy instance that fails ALB health checks.

Enable termination protection for the EC2 instance does not solve the problem because Auto Scaling can still terminate instances based on health checks and group policies even when EC2 termination protection is enabled.

Create a termination lifecycle hook and troubleshoot during the Terminating:Wait phase is not suitable for an indefinite investigation because lifecycle hooks apply during termination events and are time limited so they cannot hold a running instance out of service for an open ended troubleshooting session.

When you need to take an instance out of traffic but keep it available for investigation think Standby rather than lifecycle hooks or termination protection.

All at once deployment policy for new versions is the correct choice because Marina Analytics needs the fastest and most cost effective way to get builds into a staging environment where brief downtime is acceptable.

The All at once deployment policy for new versions replaces all instances at the same time which gives the quickest turnaround and avoids provisioning duplicate capacity. This behavior keeps costs lower and fits a workflow that deploys three to five times per day.

Rolling deployment policy for new versions is not ideal because it updates instances in batches which slows the overall release and reduces capacity during each batch.

Blue/green deployment strategy with environment swap is not ideal for this scenario because it requires a parallel environment which increases infrastructure cost and adds provisioning time for each build.

Immutable deployment policy on fresh instances is also not a good fit because it launches new instances for each deployment which increases time and cost even though it simplifies safe rollbacks.

Remember that all at once is best for nonproduction when rapid, low cost deployments matter and brief downtime is acceptable while production environments generally require strategies that preserve availability.

Enable AWS WAF logging and deliver logs directly to an Amazon S3 bucket whose name starts with aws-waf-logs-, optionally using SSE-S3 or a customer managed KMS key is correct because it lets WAF record full HTTP request details and the rules that matched so the security team can produce the required 180 day access reports.

This approach delivers per request logs that include timestamps, actions, and matched rules and stores those records in an S3 bucket that must begin with the prefix aws-waf-logs-. You can use server side encryption with SSE-S3 or choose SSE-KMS with a customer managed KMS key when you need additional key control.

Enable AWS WAF logging to Amazon CloudWatch Logs and require the log group name to begin with aws-waf-logs- is incorrect because CloudWatch Logs is a valid destination but there is no requirement to name log groups with that prefix.

Configure AWS WAF to publish logs to Amazon Kinesis Data Firehose that reads from a Kinesis Data Streams stream, and name the Firehose delivery stream with the aws-waf-logs- prefix is wrong because WAF writes directly to Kinesis Data Firehose without a Kinesis Data Streams source and there is no required naming prefix for the Firehose delivery stream.

Send AWS WAF logs to an S3 bucket encrypted with an AWS managed KMS key is not appropriate for this scenario because WAF logging to S3 supports SSE-S3 or SSE-KMS with a customer managed key rather than an AWS managed KMS key.

When you enable full request logging for AWS WAF choose an S3 destination that begins with aws-waf-logs- and plan to use SSE-S3 or a customer managed KMS key if you need stronger key control.

The correct option is Configure a Lambda alias with weighted routing to split traffic between function versions. This method allows you to route a defined percentage of API Gateway traffic to a new Lambda version using a single alias and a single API Gateway stage so you can canary a release without standing up duplicate stages.

An alias supports a routing configuration that sends a specified share of invocations to a secondary version which lets you observe CloudWatch metrics and errors for each version. You can incrementally increase the alias weight to move traffic to the new version and you can quickly roll back by updating the alias mapping. Keeping traffic control at the Lambda layer avoids extra API Gateway deployments and simplifies monitoring and rollback.

Use Amazon Route 53 weighted routing with two API Gateway endpoints is not ideal because it requires parallel API Gateway deployments and it splits traffic at DNS which does not give the same fine grained control or immediate weight adjustments as Lambda aliases. This approach increases deployment and operational complexity.

Use CodeDeploy to perform a rolling update of the $LATEST Lambda function is incorrect because Lambda does not perform rolling updates on $LATEST and CodeDeploy implements traffic shifting by manipulating aliases rather than by rolling $LATEST. If you use CodeDeploy you still rely on aliases for traffic shifting rather than expecting it to update $LATEST in place.

Enable an API Gateway canary release across two stages to route a small share to the new version adds duplicated stages and moves the canary to the API tier which is heavier and unnecessary when you can shift traffic at the Lambda alias level behind a single stage. Using API Gateway staged canaries is valid for API layer testing but it is more complex for this use case.

For Lambda canaries favor using alias weighted routing or CodeDeploy alias shifts when the question targets function level delivery rather than API layer routing.

Create API Gateway APIs in each target Region and use Amazon Route 53 latency-based routing with health checks; integrate each API with a same-Region Lambda function and access a DynamoDB global table is correct because it provides active active Regional endpoints that route customers to the nearest API for consistently low latency while maintaining a single replicated datastore across Regions.

Amazon Route 53 latency based routing directs traffic to the Region with the lowest network latency and health checks keep endpoints available. Keeping API Gateway and Lambda in the same Region reduces cross Region network hops and improves response times. DynamoDB global tables replicate data across Regions so the application has a consistent, highly available dataset without manual synchronization.

Deploy a single Region API Gateway edge-optimized endpoint and integrate with a regional Lambda function; store data in a DynamoDB global table is incorrect because edge optimized endpoints terminate through CloudFront and still route to a single Region for execution, so they do not provide an active active multi Region API deployment for consistently low latency.

Create API Gateway APIs in two Regions and use Amazon Route 53 failover routing with health checks; integrate each API with a Lambda function in the same Region and read and write to a DynamoDB global table is incorrect because failover routing is active passive and does not deliver low latency to all geographies during normal operation. Also deploying in only two Regions does not meet the requirement to run across at least three Regions.

Create API Gateway APIs in each Region and add Route 53 health checks for each record; integrate each API with a local Lambda function and update a DynamoDB table that exists only in that Region is incorrect because per Region DynamoDB tables create data silos and do not provide cross Region replication or consistency. Health checks alone do not steer users to the lowest latency endpoint.

Think active active for multi Region serverless APIs and pair Regional API Gateway and Lambda with Route 53 latency based routing and DynamoDB global tables to achieve low latency and consistent data.

Rebuild the custom AMI with EC2 Image Builder to include the current SSM Agent, attach the AmazonSSMManagedInstanceCore instance profile to the Auto Scaling groups, use Systems Manager Session Manager for centralized access, write session logs to Amazon S3, and trigger an SNS alert from S3 event notifications is the correct option because it provides centralized, agent based access without requiring internet egress and it supports durable audit logging and alerting.

Baking the SSM Agent into the AMI and attaching the managed instance role ensures every instance registers automatically with Systems Manager Session Manager when it launches. Session Manager can use VPC interface endpoints so instances in private subnets do not need NAT or a bastion host. Writing session transcripts to Amazon S3 gives a durable audit trail and S3 event notifications to Amazon SNS deliver timely alerts to the security team. EC2 Image Builder automates consistent AMI builds so the fleet remains hardened and up to date.

Stand up a NAT gateway and a hardened bastion host, allow SSH from the bastion to the Auto Scaling groups, install SSM Agent, use Session Manager for logins, stream to CloudWatch Logs, export to S3, and trigger S3 notifications to SNS is not appropriate because it introduces internet egress or a bastion that increases attack surface and it adds operational overhead that contradicts the strict isolation requirement.

Use AWS Systems Manager Automation to rebuild the AMI with the newest SSM Agent and apply a service control policy through AWS Config so instances can reach Systems Manager, then send Session Manager logs to S3 and notify the security team with Amazon SNS is flawed because service control policies do not grant permissions and AWS Config cannot attach SCPs. That combination will not by itself ensure instances can register to Systems Manager.

Use EC2 Instance Connect for centralized access by distributing short-lived SSH keys, store the session output in S3, and notify the security team with Amazon SNS is not suitable because it depends on SSH network connectivity and it does not provide the same built in, centrally captured session transcripts and private endpoint access that Systems Manager Session Manager provides without additional infrastructure.

Use Systems Manager Session Manager with VPC interface endpoints and the AmazonSSMManagedInstanceCore role to keep instances private and capture auditable session logs in S3 that can trigger SNS alerts

Give the test actions in the same stage the same runOrder value so they execute in parallel is correct. CodePipeline will start actions that share the same runOrder concurrently so the two CodeBuild container tests and the Lambda Node.js test can run at the same time when you set the action runOrder property in the CloudFormation template.

Because the tests are network bound increasing CPU or memory does not reduce HTTP latency and therefore does not shorten overall wall clock time. Using the same runOrder value enables parallel execution within the stage and directly reduces total pipeline duration without changing the test implementations or the pipeline structure beyond the CloudFormation action definitions.

Increase the CodeBuild compute type and allocate more memory to the Lambda function is incorrect because the bottleneck is HTTP I/O rather than compute or memory so larger instance types or more memory will not speed up network bound tests.

Set a higher Lambda reserved concurrency and raise the account’s concurrent CodeBuild builds limit is incorrect because CodePipeline still serializes actions when they have different runOrder values. Increasing service concurrency does not change the pipeline action ordering that causes the serial execution.

Enable AWS CloudFormation StackSets to run the pipeline actions in parallel is incorrect because StackSets are for deploying CloudFormation stacks across accounts and Regions and they do not control CodePipeline action execution order or enable parallelism inside a single pipeline.

For I/O bound steps favor parallelism over bigger compute and remember that CodePipeline runs actions with identical runOrder values concurrently.

Create an AWS Organizations organization with all features turned on and enroll every account and Enable trusted access for AWS Organizations and roll out CloudFormation StackSets from the management account are correct. These two steps together enable a low overhead, scalable deployment model for CloudFormation applications across many member accounts and multiple Regions.

This approach uses service managed CloudFormation StackSets integrated with AWS Organizations so the management account can orchestrate deployments and the service can provision the required roles and permissions across member accounts automatically. Enabling trusted access lets StackSets operate across the organization and reduces ongoing setup and coordination while still allowing multiple platform administrators to create and maintain deployments from the management account.

Manually create stacks per account using cross-account IAM roles is wrong because it forces per account manual work and creates operational overhead that does not scale across dozens of accounts and multiple Regions.

Set up an organization with only consolidated billing and invite all accounts is wrong because the consolidated billing only mode does not enable the Organizations features that service managed StackSets require. Without all features turned on trusted service integration and automatic role provisioning are not available.

Enable trusted access and deploy StackSets using self-managed permissions is wrong because self managed permissions still require creating and maintaining cross account roles and permissions manually in each account. That increases setup and maintenance effort compared to service managed StackSets integrated with Organizations.

For multi account and multi Region CloudFormation deployments favor Organizations with all features and service managed StackSets so roles and permissions are provisioned automatically and operational overhead is minimized.

Configure Amazon EC2 Auto Scaling to send notifications to an Amazon SNS topic for the EC2_INSTANCE_LAUNCH_ERROR event is correct because it delivers a native Auto Scaling lifecycle notification when a launch fails so the team can receive immediate alerts.

Enabling Configure Amazon EC2 Auto Scaling to send notifications to an Amazon SNS topic for the EC2_INSTANCE_LAUNCH_ERROR event causes the Auto Scaling group to publish the authoritative launch failure event and it can be routed to an SNS topic that notifies the on call team instantly.

Add an Auto Scaling health check that triggers an AWS Lambda function when instance health is impaired is not appropriate because Auto Scaling health checks apply after an instance is launched and registered with the group and they do not alert for failures that happen during the launch phase.

Create an Amazon EventBridge rule that filters CloudTrail RunInstances error events and publishes to an Amazon SNS topic is indirect and may miss some Auto Scaling launch failures because CloudTrail captures API calls and not every ASG launch error maps to a RunInstances API error and the ASG event is the authoritative signal.

Create an Amazon CloudWatch alarm to notify an SNS topic when an Amazon EC2 instance status check fails monitors instances that are already running and it does not cover failures that occur while an instance is still launching.

Use native Auto Scaling notifications for lifecycle events and route them to SNS for immediate paging or chat alerts.

Configure a CloudWatch Logs destination in the central account and subscribe a Kinesis Data Firehose delivery stream that writes directly to an Amazon S3 bucket is correct because it lets a single security-owned account receive cross-account CloudWatch Logs streams while using managed services for durable, low-ops storage.

Using a central CloudWatch Logs destination with a subscription filter sends logs from each member account into the security account without giving broad access to member accounts. Kinesis Data Firehose acts as a serverless delivery mechanism and writes directly to Amazon S3 so there is no shard capacity planning to manage and minimal ongoing provisioning for storage. You can enforce encryption and bucket policies in the central account and use S3 lifecycle policies or Glacier for long term archival to reduce cost.

Create a cross-account CloudWatch Logs destination in the logging account and route it to Amazon Kinesis Data Streams, then attach a Kinesis Data Firehose delivery stream targeting Amazon S3 is incorrect because adding Kinesis Data Streams introduces shard capacity planning and scaling responsibilities which conflicts with the requirement for minimal provisioning.

Create a cross-account CloudWatch Logs destination in the central account and subscribe an AWS Lambda function that forwards log batches to Amazon OpenSearch Service is incorrect because using Lambda plus OpenSearch increases operational overhead and cost. OpenSearch typically requires cluster or domain management and is not optimal as a low-ops archival store.

Set up a CloudWatch Logs destination in the central account and subscribe a Kinesis Data Firehose delivery stream to load the data into Amazon Redshift is incorrect because Redshift is a provisioned data warehouse that requires capacity planning and is not designed for simple, long term archival of raw logs.

When you see cross-account CloudWatch Logs centralization with minimal provisioning think subscription filters to a cross-account destination plus Kinesis Data Firehose delivering to Amazon S3 for a serverless, low-ops archive.

Run Jenkins as a multi-master installation across multiple AZs and use the AWS CodeBuild plugin for Jenkins so builds execute in CodeBuild is the correct choice because it provides a highly available control plane by distributing Jenkins masters across Availability Zones and it delegates build execution to a managed, elastic service.

Placing controllers in multiple AZs protects the Jenkins control plane from an AZ failure and using CodeBuild removes the need to provision and maintain agent hosts. CodeBuild scales automatically for bursty workloads and uses pay per build pricing which reduces cost for intermittent builds while lowering operational overhead.

Run Jenkins as a multi-master cluster in a single AZ, managed by an Auto Scaling group, and configure builds to run on EC2-based Jenkins agents is not fault tolerant because concentrating masters in one AZ creates a single point of failure and it does not meet the multi AZ availability requirement.

Run Jenkins as a multi-master installation across multiple AZs and attach an Auto Scaling group of EC2 instances as Jenkins agents for build execution achieves high availability for the controllers but requires managing an EC2 agent fleet that may be idle between builds which increases operational work and cost compared with a managed build service.

Run Jenkins as a multi-master cluster in one AZ with an Auto Scaling group and use the AWS CodeBuild plugin to offload builds improves build elasticity but still fails the multi AZ availability requirement for the Jenkins masters and so does not meet the HA goal.

Place controllers across multiple AZs and offload build execution to a managed service like CodeBuild to achieve availability and reduce operational cost.

The correct option is Add an .ebextensions/db-migration.config with a container_commands block for the migration and set leader_only: true. This ensures only the Elastic Beanstalk designated leader instance runs the migration once during the deployment lifecycle.

The container_commands section runs after the application source bundle is extracted and before the application is deployed, and the leader_only flag causes Elastic Beanstalk to elect a single leader instance to execute the task. This combination is designed for one time, per deployment actions such as running Flyway schema migrations and it avoids concurrent execution against the RDS database.

Add an .ebextensions/db-migration.config with a commands block that runs the migration and set leader_only: true is wrong because the commands section executes on every instance during provisioning and it does not support leader election. Using that section would cause each instance to attempt the migration concurrently.

Use AWS Systems Manager Run Command to invoke the migration script across the Auto Scaling group before the update is not appropriate because it runs outside the Elastic Beanstalk deployment flow and it does not integrate with EB leader coordination. That approach can still produce parallel runs or race conditions and it does not guarantee a single execution tied to the deployment.

Add an .ebextensions/db-migration.config with a container_commands block and set lock_mode: true is invalid because lock_mode is not a supported attribute in Elastic Beanstalk configuration files and it would not be recognized by the platform.

Use container_commands with leader_only set to true for tasks that must run once per deployment on a single instance.

Pre-provision the stack in a different region with CloudFormation, create a cross-region RDS Read Replica, enable S3 cross-region replication to a destination bucket, and promote the replica during failover while pre-scaling the Auto Scaling group is the correct choice because it provides the lowest recovery time objective and minimal data loss by keeping a warmed copy of the application and near real time asynchronous replication of the database and assets.

Pre-provision the stack in a different region with CloudFormation, create a cross-region RDS Read Replica, enable S3 cross-region replication to a destination bucket, and promote the replica during failover while pre-scaling the Auto Scaling group works well because the cross region RDS read replica replicates updates continuously so the recovery point objective is low and promoting the replica gives a quick recovery path. Keeping the secondary CloudFormation stack already deployed and pre scaling the Auto Scaling group keeps the recovery time objective low and S3 cross region replication ensures static assets are available without lengthy restores.

Deploy the stack to a second region with CloudFormation and create an RDS Multi-AZ standby there with S3 cross-region replication, rely on automatic failover, and increase Auto Scaling capacity is wrong because RDS Multi AZ is designed for high availability inside a single region and cannot place an automatic standby in another region so it does not provide regional failover.

Deploy the stack in another region with CloudFormation, schedule cross-region snapshot copies every 12 hours using Lambda and EventBridge, replicate S3 objects to S3 Glacier Flexible Retrieval, and restore the database during an outage is wrong because scheduled snapshot copies and Glacier storage introduce hours of replication lag and long restore times so the approach does not meet low RPO and RTO goals.

Deploy the stack in a second region with CloudFormation, enable S3 cross-region replication, and configure an Application Load Balancer to shift traffic to the other region during an outage while keeping RDS in Multi-AZ is incorrect because an Application Load Balancer cannot route across regions and Multi AZ does not protect against a full region outage so you need Route 53 failover or Global Accelerator for region level traffic control.

For multi region DR aim to pre provision resources and use cross region read replicas for low RPO and Route 53 failover or Global Accelerator to shift traffic between regions.

Author an AWS Systems Manager Automation runbook to consistently build the AMI and Create a Lambda function that copies the AMI into each target region and writes the region-specific AMI ID to Systems Manager Parameter Store with a common key name are correct because one gives a repeatable, auditable image build and the other makes the region-scoped AMI available and discoverable for deployments.

Author an AWS Systems Manager Automation runbook to consistently build the AMI provides a repeatable workflow to patch, harden, and bake the Python Flask base image while recording build metadata and producing a consistent artifact for testing and compliance.

Create a Lambda function that copies the AMI into each target region and writes the region-specific AMI ID to Systems Manager Parameter Store with a common key name ensures each region has the actual AMI and a consistent lookup path so automation and CI CD pipelines can programmatically obtain the correct regional AMI ID.

Run an AWS Step Functions workflow that only copies the AMI ID value in Systems Manager Parameter Store to other regions using the same parameter name is incorrect because it only replicates the identifier string and does not copy the AMI image itself so launches in other regions will fail.

Amazon Inspector is incorrect because it performs vulnerability assessment and scanning and it does not build, bake, or distribute AMIs.

AWS Backup cross-Region copy for EC2 to distribute the AMI and IDs is incorrect because AWS Backup focuses on backups such as EBS snapshots and does not provide the managed AMI bake and registration workflow needed for programmatic regional discovery.

Use SSM Automation to bake and harden images and then use a small regional Lambda to copy AMIs and write per region IDs to Parameter Store for consistent programmatic lookup.

Configure a target tracking scaling policy to maintain 70% CPU and add scheduled actions that set the group minimum to 5 during busy hours and to 2 during off-hours is correct because it combines a utilization setpoint with scheduled minimums to raise instance utilization while preserving capacity for known peak windows.

The reason this works is that target tracking automatically adjusts Auto Scaling group capacity to keep average CPU near the 70 percent setpoint so instances run at higher utilization during predictable load changes. The scheduled actions let you set the Auto Scaling group minimum for busy hours and a lower minimum for off-hours so you control cost without relying on manual termination or risky instance types.

Convert the Auto Scaling group to Spot Instances only with a capacity-optimized allocation strategy and remove existing scaling policies is risky because Spot interruptions can reduce availability and removing scaling controls stops you from meeting predictable utilization targets or ensuring a minimum capacity.

Create a target tracking policy to hold average CPU at 70% and add a scheduled action that invokes a Lambda function to terminate 8 instances after peak hours is flawed because terminating instances without changing the Auto Scaling group’s desired or minimum size causes the group to replace them and the proper approach is to use scheduled actions that set the group size directly.

Use a CloudFormation UpdatePolicy to govern peak and off-peak behavior and have the Auto Scaling group trigger stack updates via SNS notifications is incorrect because an UpdatePolicy controls rolling updates during stack changes and not timed scaling behavior and scheduled scaling is the native feature for handling predictable daily traffic.

For predictable daily patterns use target tracking to keep utilization near a setpoint and use scheduled actions to set minimum capacity for peak and off-peak windows.

The correct options are Resources were changed outside of CloudFormation and the template was not updated and The IAM user or role that ran the update lacked some required permissions. These two causes together explain why the stack update rolled back and then left the stack in UPDATE_ROLLBACK_FAILED.

Resources were changed outside of CloudFormation and the template was not updated is correct because manual or out of band changes create configuration drift and can make the prior resource state unreachable. When CloudFormation tries to restore the previous state it can fail if a resource has been modified outside the stack or if required properties no longer match what CloudFormation expects.

The IAM user or role that ran the update lacked some required permissions is correct because CloudFormation needs permission to modify create and delete all dependent resources during an update or rollback. If the execution principal lacks one or more necessary IAM actions the service cannot complete the rollback and the stack can end up in a failure state.

An interface VPC endpoint for CloudFormation in the VPC was unavailable is not a likely cause because CloudFormation operates via regional service APIs and does not depend on an interface endpoint inside the VPC to manage most resources.

The update was deployed without first creating and executing a change set is incorrect because change sets are optional. Not using a change set does not by itself cause a rollback to fail.

AWS Config was not enabled in the account or Region is unrelated because AWS Config only records resource configuration and is not required for CloudFormation to perform updates or rollbacks.

When you see UPDATE_ROLLBACK_FAILED check for out of band changes and confirm the executing role has all needed IAM permissions to modify and delete dependent resources.

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

Use a single ALB with two target groups mapped to the two ASGs, deploy to the idle ASG, then flip the ALB listener rule to the new target group while keeping Route 53 pointed at the one ALB is the correct choice because it removes DNS from the traffic shift and keeps a single ALB as the stable ingress point for clients.

This approach simplifies the architecture and lowers cost because only one ALB is required. It eliminates problems caused by clients that ignore DNS changes because traffic switching happens inside the load balancer and not via Route 53. You can perform an immediate cutover by updating the ALB listener rule or perform a gradual handoff using weighted target groups for safer blue green deployments.

Lower the Route 53 alias record TTL to 45 seconds before each release, switch DNS, then restore the original TTL is wrong because it still depends on client behavior and cached DNS. Some clients or intermediaries ignore TTLs or pin addresses and they will continue to send traffic to the old ALB despite the TTL change.

Run an NGINX sidecar on every instance to proxy requests from the inactive ALB to the active ALB is wrong because it increases operational complexity and adds latency and additional failure modes. Proxying does not address the root cause of stale client DNS and it creates maintenance and scaling overhead.

AWS Global Accelerator in front of both ALBs to shift traffic using endpoint weights is not the best fit because it would mitigate DNS caching by providing static anycast IPs but it adds cost and architectural complexity. The requirement favored a low cost and simpler solution so Global Accelerator is less appropriate for this scenario.

Avoid DNS-based cutovers when clients may not honor TTLs and prefer switching at the load balancer with listener rule changes or weighted target groups for reliable blue green deployments.

Restart the Amazon ECS agent on the EC2 container instances is the correct option because the intermittent use of an old image points to agent or host side image caching rather than to the task definition or registry.

The Amazon ECS agent is responsible for pulling container images when tasks start and it can reuse a locally cached image if the agent is unhealthy or stuck. Restarting the agent with Restart the Amazon ECS agent on the EC2 container instances restores normal agent behavior and forces fresh image pulls so new tasks consistently use the current image.

Migrate the image repository to Amazon ECR is not sufficient because changing the registry does not fix an unhealthy agent that may still reuse a cached image on the host. Moving to ECR can be a best practice but it does not address the intermittent agent issue.

Pin the image by repository-url/image@digest in the task definition and manually update the SHA-256 for each release makes deployments immutable and deterministic but it adds manual overhead and it does not resolve an underlying agent health problem that prevents image pulls.

Use the latest tag in the task definition is incorrect because mutable tags do not guarantee a fresh pull when the agent reuses a cached image. Relying on the latest tag also reduces deployment determinism and can hide pull issues.

When tasks sometimes start with an old image check the ECS agent health first and restart it if needed and consider using immutable image digests for deterministic deployments.

The correct option is Enable Amazon GuardDuty across all organization accounts with the security account as the delegated administrator, and route GuardDuty findings from Amazon EventBridge to Amazon Kinesis Data Firehose that writes to the S3 bucket. This configuration centralizes detection and funnels findings into the security account for auditing and long term storage.

Amazon GuardDuty provides continuous threat detection for behaviors such as repeated SSH brute force attempts and EC2 instances distributing malware and it supports delegated administration across AWS Organizations. EventBridge can receive GuardDuty findings and Amazon Kinesis Data Firehose can deliver those findings directly to S3 without custom compute which meets the requirement to persist events in a centralized security account.

Enable Amazon Macie in all accounts with the security account as the Macie administrator, and use Amazon EventBridge to send findings to Amazon Kinesis Data Firehose that delivers to the S3 bucket is incorrect because Amazon Macie focuses on discovering and classifying sensitive data in S3 and it does not detect SSH brute force or malware activity on EC2.

Enable Amazon GuardDuty only in the security account as the delegated administrator, and forward findings via Amazon EventBridge to Amazon Kinesis Data Streams with an AWS Lambda consumer that writes to S3 is incorrect because delegated administration does not eliminate the need for GuardDuty findings from member accounts and using Kinesis Data Streams with Lambda introduces extra operational overhead when Firehose can deliver directly to S3.

Use AWS Security Hub as the delegated administrator in the security account to aggregate findings from member accounts and export them via Amazon EventBridge to Amazon Kinesis Data Firehose for S3 storage is incorrect because Security Hub aggregates and normalizes findings from detection services such as GuardDuty and it does not itself perform the low level threat detection like SSH brute force on EC2.

When centralizing multi account threat logs use GuardDuty delegated administrator and forward findings via EventBridge to Kinesis Data Firehose for direct delivery to S3.

The correct choice is Configure an Amazon CloudWatch alarm on the StatusCheckFailed_System metric to trigger the EC2 recover action. This approach detects host level failures and initiates the EC2 recover action so the instance is moved to healthy hardware with minimal disruption.

The reason Configure an Amazon CloudWatch alarm on the StatusCheckFailed_System metric to trigger the EC2 recover action is correct is that the EC2 recover action targets system level problems such as host power loss or network failure and preserves the instance identity and attached EBS volumes. The preserved attributes allow the instance to come back on new hardware quickly and avoid significant data loss while only in memory state is lost.

Create an Amazon EC2 Auto Scaling group with minimum, maximum, and desired capacity set to 1 is not ideal because an Auto Scaling group will replace the instance rather than recover it in place and additional configuration is needed to reattach storage and preserve the original instance identity which increases downtime.

Create an Amazon CloudWatch alarm on the StatusCheckFailed_Instance metric to initiate the EC2 reboot action is incorrect because the instance status check covers guest operating system issues and a reboot does not fix host level failures such as underlying hardware power loss or network connectivity problems.

Use AWS Backup to take EBS snapshots every 15 minutes is helpful for reducing data loss but it does not provide automated instance recovery or a low recovery time objective since restoring from snapshots is a slower and more manual process.

Remember that StatusCheckFailed_System indicates host level problems and maps to the EC2 recover action while StatusCheckFailed_Instance indicates OS level problems and maps to reboot. For fast recovery from host failures choose the system check plus recover.

Create an Amazon EventBridge schedule that invokes an AWS Lambda function to call RefreshCache for the file share is correct because it triggers the Storage Gateway to re-enumerate the S3 bucket and update the cached directory listings so users can see objects uploaded directly to S3.

File Gateway caches directory and file metadata for SMB and NFS shares and it does not automatically pick up objects that are written directly to the backing S3 bucket. Calling the RefreshCache API forces the gateway to rescan the bucket and refresh its cached metadata so new files become visible in the share.

Scheduling an EventBridge rule to invoke a Lambda function after the nightly ingest is a reliable implementation. The Lambda function can call the RefreshCache API for the affected file share shortly after the upload job completes so employees see the new files the next morning.

Enable S3 same-Region replication so bucket changes propagate to the file gateway share is incorrect because S3 replication copies objects between S3 buckets and it does not interact with Storage Gateway or refresh a file share cache.

Use AWS DataSync to copy new S3 objects to the on-premises NFS or SMB share is incorrect because DataSync is a data movement service and it does not update the Storage Gateway file share metadata, and using it would add unnecessary transfers and complexity.

Switch the appliance to cached Volume Gateway and wire S3 event notifications to update the gateway when objects arrive is incorrect because Volume Gateway provides block storage rather than SMB or NFS file shares and S3 event notifications do not directly force a Storage Gateway cache refresh.

After direct S3 writes schedule a short delay and have an EventBridge rule invoke an AWS Lambda function to call RefreshCache for the file share so directory listings update for users.

The correct options are In the source account, create an encrypted copy of the AMI using the customer managed KMS key, update that key policy to let the target account create grants, and share the encrypted AMI and In the target account, create a KMS grant that allows the EC2 Auto Scaling service-linked role to use the source account key for EBS encryption.

The first correct action ensures the AMI and its backing snapshots are encrypted with a customer managed KMS key and that the key policy explicitly permits the recipient account to create grants. Using a customer managed key lets you control cross-account access and permits the creation of grants that enable the other account to access the encrypted snapshots when the AMI is shared.

The second correct action gives the Auto Scaling service in the target account permission to use the source account key at launch time. The service-linked role used by EC2 Auto Scaling must be authorized through a grant so that instances launched from the shared, encrypted AMI can attach and decrypt the EBS volumes.

In the source account, copy the AMI and encrypt it with the default AWS managed key, then share the new AMI with the target account is wrong because images encrypted with AWS managed keys cannot be shared across accounts and you cannot grant cross-account access to those managed keys.

Only update the AMI launch permissions to include the target account and proceed without changing any KMS policies or grants is insufficient because launch permissions do not provide access to the KMS key that protects the snapshots and the target account will still be unable to launch instances from the encrypted AMI.

Create a new CMK in the target account and rely on AWS Resource Access Manager to share the AMI and re-encrypt it automatically is incorrect because AWS Resource Access Manager does not share or automatically re-encrypt AMIs and you still need to perform explicit copy or grant steps with the appropriate key permissions to enable cross-account launches.

Update the source key policy to allow the other account to create grants and then create a grant to the service-linked role that will perform launches. Remember that AWS managed CMKs cannot be used for cross-account AMI sharing.

The correct choice is Add a Lambda gate in CodePipeline that calls the AWS Health API for the target Region and stops the run early when an active event could affect the deployment. This option makes the pipeline health aware and lets the deployment fail fast before long running database work consumes time and cost.

the Lambda gate queries AWS Health for scheduled or active regional events and halts the pipeline early when a risk is detected. This prevents mid-run stalls and repeated retries while preserving full automation and keeping additional operational overhead low.

Configure CodePipeline to auto-retry the entire workflow whenever a stage fails does not remove the underlying cause and it can loop through failures during a regional maintenance event which increases runtime and cost.

Schedule database maintenance windows to avoid announced AWS Region maintenance requires manual coordination and it still leaves the pipeline vulnerable to unannounced or rapidly evolving incidents so it is not a robust automated solution.

Perform blue green database upgrades by creating a standby database and switching traffic after the upgrade completes can improve release safety for schema changes but it increases cost and complexity and it will not prevent failures when the entire Region experiences an outage.

Implement a proactive health gate such as a Lambda or EventBridge check of AWS Health so pipelines can fail fast and avoid wasted runtime and cost.

The most secure choice is Keep credentials in AWS Systems Manager Parameter Store as a SecureString encrypted with KMS, grant access via an IAM role attached to the CodeDeploy-managed instance profiles and use register-on-premises-instance so on-prem servers assume the role, then deploy packages with AWS CodeDeploy.

This approach centralizes secrets in Parameter Store and uses KMS for encryption at rest while TLS protects secrets in transit. It relies on instance roles so EC2 instances and registered on-premises servers can retrieve secrets at runtime without embedding credentials in artifacts. Registering on-premises servers lets them assume the necessary role or obtain temporary credentials and CodeDeploy handles the package rollout while instances fetch secrets when the application runs.

Put the database secrets in the CodeDeploy appspec.yml file, restrict access with a narrowly scoped IAM policy, and roll out to EC2 and on-premises servers with AWS CodeDeploy is insecure because storing secrets in deployment artifacts or repository history exposes them and violates the requirement to avoid embedding credentials in code or artifacts.

Store credentials as a SecureString in AWS Systems Manager Parameter Store and attach an IAM policy directly to on-premises machines and the EC2 instance profiles to allow decryption, then deploy with AWS CodeDeploy is incorrect because IAM policies are attached to roles and on-premises machines cannot have IAM roles directly. On-prem servers must be registered so they can assume a role or use temporary credentials.

Use AWS Secrets Manager and grant the CodeDeploy service role permission to read the secret so it can push the value to targets during deployment is flawed because granting the service role access to read and push secrets increases exposure and does not provide the application with a per-instance identity to securely retrieve secrets at runtime. Instances need their own role or registered identity to follow least privilege.

Use runtime retrieval of secrets and attach an IAM role to managed instances for hybrid deployments so applications fetch secrets at runtime and you avoid embedding credentials in artifacts.

Configure an UpdatePolicy with AutoScalingRollingUpdate and set MinInstancesInService is correct because it instructs CloudFormation to perform a rolling update of the Auto Scaling group so the group adopts the updated launch template version while keeping at least the required number of instances in service.

Using AutoScalingRollingUpdate lets CloudFormation replace instances in controlled batches while new instances launch with the new AMI and instance type. You can set MinInstancesInService to ensure at least six instances remain healthy during the update and you can adjust batch size and pause behavior to avoid downtime.

AWS CodeDeploy is incorrect because CodeDeploy coordinates application code deployments and deployment groups and it does not manage CloudFormation stack updates that change the AMI or instance type for an Auto Scaling group.

Set UpdateReplacePolicy and specify MinSuccessfulInstancesPercent and MaxBatchSize is incorrect because UpdateReplacePolicy governs retention behavior when resources are replaced and it does not provide rolling update batch controls or success thresholds for replacing instances in an Auto Scaling group.

Enable AutoScalingReplacingUpdate and tune WaitOnResourceSignals and PauseTime is incorrect because AutoScalingReplacingUpdate replaces the entire Auto Scaling group as a unit and does not perform a rolling update using the wait and pause properties that apply to rolling updates.

When updating an Auto Scaling group use AutoScalingRollingUpdate and set MinInstancesInService so capacity is preserved during the rollout and verify MaxBatchSize and health checks before starting the update.

The best solution is AWS Step Functions orchestrating AWS Lambda tasks, triggered by Amazon EventBridge with notifications via Amazon SNS. This approach gives a managed, stateful workflow that can run nightly at 00:30 UTC and provide the required failover logic and notification.

Step Functions preserves a detailed execution history that serves as the audit trail and it provides built in Retry and Choice states so the workflow can attempt a copy to a second Region and then branch to a third Region if the second is unavailable. You can implement snapshot and cross Region copy operations with Lambda tasks or with Step Functions AWS SDK integrations and you can publish the final outcome to SNS to deliver email notifications.

An Amazon EventBridge schedule that invokes a single AWS Lambda function for all steps and uses AWS Config for auditing is weak because a single Lambda can exceed the 15 minute timeout when snapshots or cross Region copies take longer and AWS Config does not record step by step workflow execution history for auditing.

An Amazon EC2 instance running a cron job and Python script to snapshot and copy across Regions, with step status stored in Amazon DynamoDB increases operational overhead and creates a single point of failure and it lacks the built in state management and managed retries that make failover logic robust.

Amazon Managed Workflows for Apache Airflow can orchestrate complex jobs but it is heavier to operate and not as serverless or purpose built for simple, auditable retry and branching workflows as Step Functions.

Use Step Functions for durable state, built in retries, and execution history and pair it with EventBridge for scheduling and SNS for email notifications.

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

Create an Amazon Kinesis Data Firehose delivery stream with a Lambda transformation, set the destination to the current S3 bucket, and update Network Firewall to publish logs to the stream is the correct choice because it enables inline enrichment and delivers transformed records to the existing S3 bucket before objects are written to the data lake.

Kinesis Data Firehose supports invoking a Lambda function to transform records inline and then buffers and reliably delivers the results to S3 while handling scaling and retries. This design meets the requirement for near real time delivery under 90 seconds and keeps operational overhead low by using managed buffering and delivery, and by using a native Network Firewall destination.

Configure Amazon S3 Event Notifications to launch an AWS Glue job that processes new log objects and writes the enriched output back to the same bucket is incorrect because it transforms data after logs are already stored in S3 and Glue is oriented toward batch ETL rather than sub minute streaming transforms.

Create an S3 object-created trigger that invokes an AWS Lambda function to reformat the logs and save transformed copies to the existing bucket while preventing recursive writes is incorrect because it also processes post ingest and creates risks of recursive writes and additional operational complexity that the team is trying to avoid.

Ingest records into Amazon Kinesis Data Streams and attach a Lambda consumer to enrich them before writing to the S3 bucket is incorrect because Network Firewall does not publish natively to Kinesis Data Streams so this approach would require extra components and more maintenance.

When you must enrich logs before they land in S3 and keep operations minimal choose Kinesis Data Firehose with a Lambda transform because it is a native Network Firewall destination and provides built in buffering and retries.

The correct option is Configure Immutable as the deployment policy in the Elastic Beanstalk environment for upcoming releases. Immutable updates provision a temporary Auto Scaling group with the new version while the existing fleet continues to serve traffic and the cutover only happens after the new instances pass health checks.

Immutable updates create parallel instances behind the same load balancer so the current fleet remains serving traffic until the new instances are verified healthy. This approach enables fast automatic rollback by terminating the new Auto Scaling group if problems appear without redeploying the previous build or changing the environment attached RDS. That behavior matches the requirement to avoid manual redeploy and to keep the database attachment intact during rollback.

Use Rolling with additional batch as the deployment policy for future deployments is incorrect because it performs in place updates and can leave a mixed fleet during deployment. That situation can prolong recovery since reverting often requires additional rolling steps or a redeploy.

Set All at once as the deployment policy for the Elastic Beanstalk environment is incorrect because it replaces all instances at once which causes service interruption and offers no safer automatic rollback mechanism for a mission critical portal.

Implement blue/green deployment in Elastic Beanstalk while keeping the RDS instance tightly coupled to the environment is incorrect because blue green cutovers require the database to be decoupled from an environment. An Elastic Beanstalk attached RDS is environment bound which complicates cutover and risks data loss or accidental termination when switching environments.

For zero downtime and quick automatic rollback use Immutable deployments in Elastic Beanstalk and decouple your database before attempting blue green switches.

Create an Origin Access Control and attach it to the S3 origin in CloudFront, then update the ops-helix-ledger bucket policy to allow only requests from that distribution is correct. Implementing an origin access control ensures CloudFront signs origin requests and the bucket policy can be locked so that only the distribution can retrieve objects, which prevents users from bypassing CloudFront by using direct S3 URLs.

Create an Origin Access Control and attach it to the S3 origin in CloudFront, then update the ops-helix-ledger bucket policy to allow only requests from that distribution works because the Origin Access Control signs requests to S3 with SigV4 and you then configure the bucket policy to require that signature or the CloudFront principal. That combination keeps objects private in the bucket while allowing CloudFront to fetch and serve them. Also note that legacy Origin Access Identity is being replaced by OAC so newer exams and implementations will favor OAC over the older mechanism.

Require CloudFront Signed URLs and create a key pair, then grant the public key permission to read objects in the S3 bucket is incorrect because signed URLs control who can use CloudFront but do not, by themselves, stop direct S3 object URLs unless you also add a bucket policy that denies or restricts direct S3 access, which this option does not specify.

Enable field-level encryption on the CloudFront distribution and remove users’ permissions to fetch objects via S3 URLs is incorrect because field-level encryption protects specific data fields in transit and does not enforce origin access controls or prevent direct access to S3 object URLs.

Enable Amazon S3 Block Public Access on the bucket to force downloads through CloudFront is incorrect because Block Public Access blocks public ACLs and policies but does not create a CloudFront origin identity or prevent authenticated principals from accessing S3 directly. You still need a bucket policy that explicitly allows only the CloudFront distribution.

Use Origin Access Control plus a tight bucket policy that trusts only the CloudFront distribution. Remember that Signed URLs control client access to CloudFront but do not by themselves block direct S3 object URLs.

Create an Amazon EventBridge rule for EC2 Instance State-change Notification events and target an Amazon SNS topic is correct because it delivers native, near real time events for EC2 lifecycle transitions and it can route those events to SNS so the platform team receives automated alerts when instances move to pending, running, stopping, stopped, shutting down, or terminated.

EventBridge emits explicit instance state change events that you can match with a rule and then fan out via an SNS topic to email, SMS, Lambda, or other subscribers. This approach directly satisfies the requirement for automated notifications on any state change and does not rely on probing health metrics or on service level incident feeds.

Configure an Amazon CloudWatch alarm on the StatusCheckFailed_System metric and choose the EC2 recover action is focused on recovering from host level faults and will not notify for normal lifecycle transitions such as stop or terminate. It is not designed to alert on every instance state change.

Subscribe to AWS Health event notifications for EC2 and deliver messages through an Amazon SNS topic is unsuitable because AWS Health reports service or account impacting incidents and scheduled events and does not provide routine per instance state change notifications.

Configure an Amazon CloudWatch alarm on the StatusCheckFailed_Instance metric and select the EC2 reboot action targets instance level health failures where a reboot may help and does not cover all lifecycle state changes so it will miss many stop or terminate events.

When you need alerts for EC2 lifecycle changes think EventBridge rules matched to EC2 Instance State change events and route them to SNS for immediate notifications. CloudWatch status checks are for health failures and AWS Health is for service incidents.

The correct choices are Use Amazon EventBridge to trigger an AWS Lambda function every hour to enumerate running EC2 instances in the staging and production VPCs, compare their AMI IDs against the approved list, publish to Amazon SNS, and automatically terminate noncompliant instances and Enable AWS Config with the approved-amis-by-id managed rule and attach an AWS Systems Manager Automation remediation to stop or terminate noncompliant instances and notify via Amazon SNS. These two approaches provide detective controls with automated remediation and avoid blocking developer pipelines.

The EventBridge + Lambda approach gives scheduled detection and flexible remediation. A lightweight rule can run hourly or at any cadence that balances risk and developer velocity and the Lambda can target only production or staging VPCs so staging experimentation is still observed. The function can compare AMI IDs against the central allowlist, publish findings to SNS for alerting, and optionally terminate offending instances without preventing developers from launching instances during validation.

The AWS Config approved-amis-by-id managed rule provides continuous, service-native compliance checking and it integrates with Systems Manager Automation for built in remediation workflows. This delivers near real time detection and documented remediations while keeping launches permissive so pipelines do not fail on every experimental run. Config gives audit history and reporting which supports governance requirements.

Run periodic Amazon Inspector scans with a custom assessment to detect instances not based on approved AMIs, then terminate and email the teams is incorrect because Inspector focuses on vulnerabilities and runtime findings and is not designed to enforce AMI allowlists.

Apply an AWS Organizations SCP that denies ec2:RunInstances unless the AMI is in the approved list is incorrect because an SCP is a preventative hard block that would stop developer and CI/CD launches and it would disrupt the pipelines the question asks to avoid impacting.

Attach IAM policies that only allow ec2:RunInstances with the preapproved AMI list is incorrect because IAM restrictions at launch are also preventative and would prevent short lived staging instances from starting with experimental AMIs which conflicts with the requirement to avoid slowing developer pipelines.

When the question asks for the least disruptive enforcement prefer detective controls with automated remediation such as Config managed rules or scheduled EventBridge Lambda checks rather than IAM or SCP preventative blocks.