AWS DevOps Engineer Certification Practice Exams

The most direct and economical solution is to use CodePipeline’s native Manual approval action as the gate before production. Pairing this with SNS notifications alerts approvers, and the pipeline resumes only after explicit approval, ensuring releases cannot bypass the check even if all tests pass.

Use CodeBuild to execute the tests, insert a Manual approval action in CodePipeline immediately before the production CodeDeploy stage with SNS notifications to approvers, then proceed to the production deploy after approval is correct because the Manual approval action is built-in, incurs no additional service to manage, and integrates cleanly with SNS for notifications.

Run the unit and integration tests with AWS Step Functions, then add a test action after the last deploy, add a manual approval with SNS notifications, and finally add a deploy action to promote to production is unnecessary and more complex than needed, since CodeBuild already handles tests and the gating requirement is met by the Manual approval action.

Use CodeBuild for tests and create a custom CodePipeline action with a bespoke job worker to perform the approval, notify through SNS, and promote on success adds development and maintenance overhead for custom workers when a managed Manual approval action already exists.

Perform the tests in a self-managed Jenkins or GitLab on EC2, add a test action, add a manual approval in the pipeline with SNS notifications, and then deploy to production increases cost and operational toil by running and maintaining third-party tooling instead of using managed AWS services.

When a question asks for the simplest and most cost-effective human gate in a CodePipeline, choose the built-in Manual approval action with SNS notifications and avoid custom actions or self-managed CI/CD stacks.

Pilot light in another Region with cross-Region RDS read replica, minimal app stack, Route 53 failover, and promote replica on disaster is the best fit because it provides minutes-level RPO via continuous asynchronous replication to a cross-Region RDS read replica while keeping most compute resources powered off to minimize ongoing cost. During an event, the replica can be promoted and the minimal app stack scaled up to meet an hours-level RTO, and Route 53 failover can redirect traffic quickly.

The option Warm standby in another Region with scaled-down but running stack and scale out on failover can achieve the RTO but keeps an always-on environment that is costlier than necessary given the cost constraint and the hours-level RTO target.

The option Backup and restore with AWS Backup cross-Region copies and rebuild on failover commonly cannot meet a 15-minute RPO and may exceed a 3-hour RTO because snapshot copy and full environment re-provisioning take longer.

The option Single-Region Multi-AZ only for EC2 and RDS does not protect against Regional failures and therefore cannot meet cross-Region disaster recovery requirements.

Map RTO and RPO to DR patterns. For minutes-level RPO with hours-level RTO and low cost, think pilot light with cross-Region database replication and DNS failover. For near-zero RPO/RTO, think multi-site active/active at higher cost. For lowest cost but long RTO/RPO, think backup and restore. Confirm that solutions address Region-level failures, not just AZ.

The combination of Deploy an AWS Config custom rule with AWS CloudFormation StackSets to check instance AMI IDs against an approved list and aggregate results in an AWS Config aggregator in the management account and Use AWS Systems Manager Automation to produce the AMI in a central account and share it with organizational accounts, then revoke sharing on the previous AMI and share the new one when updated meets both enforcement and auditing needs.

Centralizing the AMI and using share and unshare enforces that new instances cannot be launched from an older AMI, because once the previous AMI is unshared it is no longer available for new launches across accounts. The AWS Config rule rolled out with StackSets and aggregated in the management account provides a single-pane view to audit AMI usage and detect noncompliant instances organization-wide.

Use AWS Systems Manager Automation distributed with AWS CloudFormation StackSets to build the AMI inside every account is operationally heavy and leads to version sprawl, making it hard to retire old AMIs consistently and block new launches from them.

Create the AMI in a central account and copy it to each account and Region whenever a new version is published proliferates stale copies that remain launchable, so it does not guarantee that old AMIs are blocked.

Publish the approved AMI as a product in AWS Service Catalog across the organization may guide provisioning but does not prevent users from bypassing the catalog and launching older AMIs directly, nor does it provide organization-wide compliance reporting.

For org-wide AMI governance, think in two steps: enforce usage through central sharing and revocation, and audit with AWS Config custom rules aggregated at the organization level.

The best ways to get near-real-time alerts for AWS Organizations membership or account changes are AWS CloudTrail organization trail with EventBridge to SNS and AWS Config organization aggregator with rules to SNS or EventBridge. An organization-level CloudTrail records Organizations API activity such as invites, account creation, and handshakes. EventBridge rules can match these events and push alerts through SNS with minimal delay, which directly addresses the requirement.

AWS Config with an organization aggregator provides centralized visibility and evaluation across accounts. While it is not the primary event source for Organizations API calls, it can drive notifications when evaluated configurations indicate account-related changes across the org, complementing CloudTrail for governance monitoring.

The option AWS Security Hub and Amazon Detective is incorrect because these services focus on security findings and investigation rather than authoritative detection of Organizations membership changes.

AWS Control Tower notifications is incorrect because Control Tower focuses on landing zone governance and does not serve as a comprehensive eventing source for Organizations membership or invite events.

Third-party SIEM with Amazon GuardDuty is incorrect because GuardDuty provides threat detections, not explicit Organizations change events, and SIEM tooling does not inherently add that specificity.

For near-real-time alerts on administrative changes, look for patterns that combine CloudTrail as the authoritative activity log with EventBridge for event-driven routing to alerting (SNS, Lambda). Remember that Security Hub, Detective, and GuardDuty focus on security findings, not control plane governance for Organizations. When you see “organization-wide” visibility and evaluation, consider AWS Config aggregators, but prioritize CloudTrail + EventBridge for precise API-change alerts.

The best approach is to use Create a parallel environment behind the ALB with the new build and configure API Gateway canary release to send a small portion of requests to it. API Gateway REST API canary deployments let you gradually shift a small percentage of traffic to the new backend, observe behavior, and instantly roll back by changing or disabling the canary weight. This requires no application code changes and only minimal configuration updates at the API stage.

Use AWS CodeDeploy blue/green with the Auto Scaling group behind the ALB and shift production traffic to the new revision can work, but it adds deployment tooling, agents, and AppSpec files, which is more invasive than necessary for a deployment controlled at the API layer.

Stand up a duplicate environment and update the Route 53 alias to the new stack forces a full cutover that affects every user, lacks progressive exposure, and makes rollback a second DNS flip rather than a quick weight change.

Create a new target group for the ALB and have API Gateway weight requests directly to that target group is not feasible because API Gateway does not weight across ALB target groups; the supported mechanism for weighted exposure in API Gateway is a canary release.

When an API Gateway REST API fronts an ALB and EC2 fleet, think canary release at the API stage for minimal-risk rollouts and fast rollback; avoid full DNS cutovers and avoid overengineering when a simple API-level weight shift will do.

AWS Service Catalog is correct because it lets administrators publish vetted CloudFormation products and apply constraints and TagOptions so users can provision only approved architectures with required tags. This delivers preventative governance at the moment of provisioning while preserving self-service.

AWS Organizations SCPs with tag policies is insufficient because tag policies primarily validate and report, and while SCPs can conditionally deny creates for missing tags in some services, they do not package or present pre-approved architectures as a curated catalog.

AWS Config provides detective controls after resources are launched, which does not prevent noncompliant resources from being created.

AWS CloudFormation Guard validates templates via policy-as-code but relies on integration in pipelines or hooks and does not provide a catalog nor enforce controls for ad hoc provisioning.

When you see pre-approved architectures, curated products, enforced parameters or tags, and preventative control at provisioning, think Service Catalog. Distinguish preventative (Service Catalog, some SCP patterns) from detective (AWS Config). Catalog plus constraints strongly points to Service Catalog.

The most operationally efficient solution for fully meshed, transitive connectivity across many VPCs is Use AWS Transit Gateway for transitive connectivity among VPCs and manage network access policies centrally with AWS Firewall Manager. Transit Gateway acts as a scalable hub for VPC attachments and natively provides transitive routing, which avoids the complexity of managing numerous point-to-point connections. Firewall Manager lets you centrally apply and govern network security policies across accounts and VPCs, including policies for AWS Network Firewall.

Configure VPC peering between every VPC to build a full mesh and centralize WebACLs with AWS WAF is inefficient and does not meet requirements because VPC peering does not support transitive routing, and AWS WAF is for web-layer protection, not centralized network access controls.

Set up AWS PrivateLink endpoints between each VPC and use AWS Security Hub for centralized security policies is unsuitable since PrivateLink exposes services over interface endpoints rather than providing general routing, and Security Hub aggregates findings but does not enforce network policies.

Establish AWS Site-to-Site VPN tunnels between each pair of VPCs and manage policies with AWS Firewall Manager is operationally heavy and not aligned with AWS-managed VPC-to-VPC connectivity; Site-to-Site VPN is intended for connecting on-premises networks to AWS rather than building VPC meshes.

When you see requirements for transitive routing and centralized network policy management across many VPCs and accounts, think AWS Transit Gateway plus AWS Firewall Manager for the most scalable and operationally efficient design.

The correct choice is Turn on S3 server access logging and analyze logs with Amazon Athena. S3 server access logs capture per-request details including object key, requester, operation, and bytes. Writing these logs to S3 and querying with Athena provides immediate, serverless, pay-per-query analysis to rank the most accessed objects at minimal cost.

Amazon S3 Storage Lens is incorrect because it provides aggregated insights at the bucket or prefix level and on a periodic schedule, not detailed per-object request counts needed for precise ranking.

Enable S3 data events in AWS CloudTrail and query with Amazon Athena is not cost-effective at high request volumes because CloudTrail data events are billed per request and can become expensive compared to native S3 access logs.

Use Redshift Spectrum with a Redshift cluster to query S3 access logs is unnecessary for this use case since it requires provisioning a cluster and incurs higher ongoing costs; Athena is simpler and cheaper.

When a question emphasizes per-object access insights that must be quick and low cost, prefer serverless, pay-per-query analytics on existing logs. Watch for distractors like Storage Lens (aggregated, not per-object), CloudTrail data events (accurate but costly for heavy traffic), and solutions that require provisioning clusters or complex pipelines.

The most cost-effective way to ingest frequent health checks while storing metrics at 1 minute granularity is to aggregate locally and publish once per minute using CloudWatch statistic sets. Create a custom CloudWatch metric and publish statistic sets that roll up the 5 second results, sending one update every 60 seconds meets the monitoring and alarm needs while minimizing PutMetricData calls.

Use a default CloudWatch metric at standard resolution and add a dimension so the script can publish once every 60 seconds is not viable because default metrics are created by AWS services and cannot accept your application’s script output; dimensions only annotate metrics you already publish.

Amazon CloudWatch Synthetics could run external checks but it does not use the instance script and typically costs more than batching custom metrics for this requirement.

Use a custom CloudWatch metric at high resolution and push data every 5 seconds would increase ingestion cost and is unnecessary since the requirement is 1 minute granularity.

When you collect high-frequency samples but only need 1 minute visibility, publish a custom metric using statistic sets once per minute to cut PutMetricData calls and cost; reserve high-resolution metrics for true sub-minute alarms.

UpdatePolicy: AutoScalingRollingUpdate is correct because it is the CloudFormation UpdatePolicy that performs rolling updates for Auto Scaling groups and supports MinInstancesInService and MaxBatchSize to maintain capacity while updating instances to a new launch configuration. This matches the requirement to keep a specified number of instances in service during the rollout.

AutoScalingReplacingUpdate is incorrect because it replaces all instances (or the entire group) rather than doing controlled batch updates, which risks breaching the in-service capacity target.

AWS CodeDeploy is incorrect since it is a deployment service outside of CloudFormation’s UpdatePolicy mechanics and is not used to orchestrate ASG rolling updates within a template.

UpdateReplacePolicy is incorrect because it governs whether to retain, delete, or snapshot a resource when it is replaced, not how updates roll through instances. On the exam, look for cues like MinInstancesInService and MaxBatchSize tied to CloudFormation. These strongly indicate UpdatePolicy with AutoScalingRollingUpdate. Be careful not to confuse UpdateReplacePolicy (retention behavior) or broad replacement mechanisms like AutoScalingReplacingUpdate with rolling updates. If the question emphasizes maintaining capacity during an ASG update from a template, prioritize the rolling update policy.

The least overhead solution is to leverage what CodeDeploy already exposes. Use a single script that reads the DEPLOYMENT_GROUP_NAME environment variable in CodeDeploy and call it in the BeforeInstall hook to set NGINX logging per group. This requires no additional AWS API calls or credentials and lets you apply configuration before services start.

Tag each EC2 instance with its deployment group and have a ValidateService hook script call aws ec2 describe-tags to choose the log level introduces unnecessary tagging management and CLI usage during deployment, and ValidateService occurs late in the lifecycle.

Define a custom environment variable in CodeDeploy for each environment such as QA, PREPROD, and PROD, and have a ValidateService hook script read it to set the log level is not viable because CodeDeploy hook scripts only get predefined variables and do not support arbitrary custom variables.

Invoke a script during ApplicationStart that uses the DEPLOYMENT_GROUP_ID environment variable to detect the group and update the NGINX log level relies on the group ID and runs later than necessary; even though the ID exists, using the group name is simpler and configuring earlier in BeforeInstall is preferred.

Remember that CodeDeploy provides built-in environment variables like DEPLOYMENT_GROUP_NAME; use them to drive environment-specific behavior and pick the earliest suitable lifecycle event such as BeforeInstall when you need configuration changes in place before services start.

https://aws.amazon.com/blogs/devops/using-codedeploy-environment-variables/

https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html#reference-appspec-file-structure-environment-variable-availability

Amazon Route 53 ARC zonal shift for the ALB is correct because it provides an operational control to quickly evacuate a single Availability Zone for an existing Application Load Balancer without changing the infrastructure. Zonal shift instructs AWS to stop sending traffic to targets in the specified AZ, effectively isolating the impaired zone while keeping the stack intact.

The option Configure Auto Scaling health checks to replace instances in that AZ is incorrect because replacing instances does not stop the ALB from routing traffic to the impaired zone; it does not achieve zonal isolation.

The option Remove the impaired AZ subnet from the ALB can isolate the zone but requires modifying the load balancer configuration or updating infrastructure as code, which is not the minimal, fast operational step the question seeks.

The option Route 53 weighted routing across two ALBs is incorrect because it introduces additional load balancers and DNS complexity and still does not solve zonal isolation for a single ALB.

When you see requirements like isolate a single AZ, within one Region, and perform it quickly with minimal or no stack changes, think Route 53 ARC zonal shift. If the scenario talks about global entry points or multi-Region failover, consider alternatives like Global Accelerator or Route 53 failover across endpoints.

The delete operation fails because the bucket still has objects from the test run, and CloudFormation cannot remove a non-empty S3 bucket. The right approach is to add a custom resource that runs on the stack’s Delete event to empty the bucket, including versions and delete markers if versioning is enabled.

The S3 bucket is not empty and CloudFormation cannot delete it; use a Lambda-backed custom resource to purge the bucket on stack deletion is correct because CloudFormation requires the bucket to be empty before deletion, and a custom resource can programmatically delete all contents during stack teardown.

A stack policy is blocking stack deletion; remove the stack policy and try again is incorrect because stack policies only control update operations and do not prevent stack deletion.

Add a Delete: Force setting to the S3 bucket in the template so CloudFormation auto-empties the bucket is incorrect because CloudFormation has no such property, and it will not automatically purge bucket contents.

The Lambda function is still using the bucket; add a WaitCondition to the function to allow the delete to proceed is incorrect because WaitCondition is not used with Lambda and would not solve the requirement that the bucket be empty before deletion.

When stacks create S3 buckets for tests, ensure teardown empties the bucket first; use a Delete event on a custom resource to remove objects, and remember there is no force delete setting for S3 in CloudFormation.

The correct solution is to front the application with CloudFront for global performance and TLS, and enforce WAF at the edge. Attach an AWS WAF web ACL to the CloudFront distribution ensures requests are inspected and blocked at edge locations, stopping common web exploits before reaching the origin. Deploy CloudFront in front of the ALB and use ACM for the custom domain TLS provides HTTPS via ACM certificates, reduces global latency via edge caching, and includes AWS Shield Standard for L3/L4 DDoS protections.

The option Use AWS Global Accelerator in front of the ALB improves global routing and adds DDoS protections but does not provide web exploit filtering or caching, so it does not meet all requirements.

Associate an AWS WAF web ACL with the ALB secures at the regional layer but lacks edge-level filtering and does not address global latency.

Create a CloudFront distribution using the Auto Scaling group as the origin is invalid because CloudFront cannot directly target an Auto Scaling group; you must use an ALB or other supported origin.

When you see requirements for global latency reduction and edge protections, think CloudFront. For custom domain TLS at the edge, pair CloudFront with ACM certificates (uploaded or issued in us-east-1 for CloudFront). Attach AWS WAF to CloudFront for edge inspection. Remember WAF cannot attach to an Auto Scaling group, and CloudFront cannot use an Auto Scaling group directly as an origin.

The most suitable pattern is cross-stack references. By using Outputs that the database stack exports and referencing them via Fn::ImportValue in the application stack, Export Outputs from the database stack and import them into the application stack with Fn::ImportValue preserves independent stacks, enables resource-level change set reviews per team, and lets the CI/CD pipeline update the application stack without redeploying the database stack.

Use AWS CloudFormation StackSets to share parameters across the database and application stacks is not appropriate because StackSets target multi-account or multi-Region governance, not sharing resources between two stacks in the same account and Region.

Convert the database template into a nested stack within the application stack would couple the stacks under one parent where change sets apply across the hierarchy, which conflicts with the requirement for independent resource-level reviews.

Store database resource identifiers in AWS Systems Manager Parameter Store and reference them via dynamic references in the application template lacks CloudFormation-managed dependencies and change set tracking, making it harder to validate changes and increasing drift risk.

Use Exports and Fn::ImportValue for cross-stack references within the same account and Region when teams need independent lifecycles and change sets; prefer nested stacks only when a single stack hierarchy and unified reviews are acceptable, and remember StackSets are for multi-account and multi-Region propagation.

The best way to reduce time-to-ready is to make instances as immutable as possible. Golden AMI with app preinstalled; runtime config via user data removes the 27-minute install step entirely by pre-packing the application into the AMI. User data (or SSM Parameter Store) then supplies environment-specific configuration at boot without baking volatile values. Local caches should not be baked into images because they are ephemeral and change frequently; rely on external caches like ElastiCache and allow instances to warm quickly from that shared layer.

The option Use CodeDeploy during lifecycle hooks to install the app on launch; let the cache warm later still performs full installation during scale-out, preserving the lengthy 27-minute delay. The choice AMI with app and baked local cache; set dynamic config via user data is brittle because cached content becomes stale and inconsistent, leading to correctness issues and frequent AMI rebuilds. The approach AMI with app; user data; invoke Lambda at boot to prefill local cache adds coordination complexity and remains tied to dynamic, frequently changing cache data, which undermines predictability and speed.

Look for cues like stateless web tier, Auto Scaling, and long bootstrap times. Prefer immutable images to eliminate installation steps, and separate configuration from code via user data or Systems Manager. Avoid baking volatile runtime data such as caches into AMIs. If mentioned, warm pools can complement this pattern, but they do not replace the benefits of a properly baked AMI.

The right choice is Publish vetted CloudFormation products in AWS Service Catalog. Service Catalog allows the platform team to curate approved templates, publish multiple product versions for different releases, and apply constraints that restrict parameters and effectively scope usage to approved regions while enforcing required tags through template rules and product controls.

Launch approved CloudFormation templates through StackSets is not sufficient because StackSets orchestrates distribution but does not enforce mandatory tags or prevent developers from launching in disallowed regions.

Create AWS Trusted Advisor checks to detect unapproved StackSets is incorrect since Trusted Advisor cannot enforce CloudFormation governance or block noncompliant launches.

Use CloudFormation drift detection to find and remediate noncompliant stacks is reactive and detects differences only after deployment, so it cannot guarantee pre-deployment policy compliance.

For governance of IaC at scale, look for curated, versioned, and constrained launches via Service Catalog; tools like StackSets solve distribution, not policy enforcement.

The correct choice is Rolling deployment with 30% batches. Rolling deployments update instances in-place in batches within the existing environment, which keeps the DNS endpoint unchanged, avoids standing up a new environment or Auto Scaling group, and maintains availability because some instances remain in service during each batch.

Set up blue/green and swap CNAMEs is incorrect because it provisions a separate environment before the swap, introducing new resources.

In-place all-at-once deployment is incorrect because updating every instance simultaneously causes downtime.

Rolling deployment with an additional batch is incorrect because it temporarily adds instances to increase capacity, which violates the requirement to avoid creating new resources.

Match constraints to deployment modes. If you see keep DNS, exclude blue/green. If you see no new resources, exclude immutable and additional-batch. If you see maintain availability, exclude all-at-once. That leaves standard rolling deployments with an appropriate batch size.

The best choice is Use AWS Systems Manager Automation runbooks triggered by AWS CodePipeline via Amazon EventBridge to bake AMIs and publish the AMI IDs to Systems Manager Parameter Store. Systems Manager Automation provides runbooks such as AWS-UpdateLinuxAmi and AWS-UpdateWindowsAmi to standardize image baking without maintaining servers. Triggering via CodePipeline and EventBridge keeps the process event-driven, and Parameter Store offers a low-cost, centrally managed, and programmatically accessible location for AMI IDs.

Run Packer from a Jenkins job on a provisioned EC2 instance and record AMI IDs in Amazon DynamoDB adds operational burden by running and patching Jenkins on EC2 and paying for always-on infrastructure, and DynamoDB is unnecessary for simple parameter retrieval compared to Parameter Store.

Provision EC2 build workers in CodePipeline to download OVF images, customize with guestfish, import as AMIs, and save AMI IDs in Systems Manager Parameter Store is overly complex and manual, requiring EC2 build capacity and VM import workflows that increase cost and time.

Use AWS CodePipeline to snapshot EBS-backed instances, patch via AWS Lambda, create AMIs from snapshots, and write AMI IDs to Amazon S3 introduces many components and uses S3 for configuration values, which is less suitable than Parameter Store and increases operational overhead.

When you see image baking with a requirement for least overhead and a central, programmatic store for IDs, think Systems Manager Automation for AMI creation and Parameter Store for distribution, triggered by CodePipeline and EventBridge.

WAF web ACL on API Gateway stage with managed SQLi rules; track via AWS Config is correct because AWS WAF integrates directly with API Gateway stages. Applying the AWS Managed Rules for SQLi provides immediate protections against common injection patterns, and a scope-down statement can target only sensitive routes (for example, login) to reduce false positives. AWS Config records WAFv2 resource configuration changes, giving a searchable, auditable history without adding unnecessary services or cost.

The option AWS Shield Advanced with CloudTrail logs is incorrect because Shield Advanced focuses on DDoS mitigation rather than application-layer attacks like SQL injection, and CloudTrail is primarily API activity logging, not a dedicated, queryable configuration history like AWS Config provides.

The option CloudFront before API Gateway, WAF on CloudFront, block attacker IP in VPC NACL, use AWS Config is incorrect because this adds complexity and cost; NACLs do not protect API Gateway since it is not in your VPC, and placing CloudFront in front of API Gateway is unnecessary solely for SQLi protection.

The option API Gateway throttling and usage plans with CloudWatch Logs for change history is incorrect because throttling does not prevent injection payloads and CloudWatch Logs do not deliver authoritative configuration timelines like AWS Config.

Remember that API Gateway can be directly associated with a regional AWS WAF web ACL. Map attack types to the right service: SQL injection implies WAF managed rules, while DDoS implies Shield. For searchable configuration change history, prefer AWS Config over CloudTrail. Also note that VPC NACLs and security groups protect VPC resources, not regional edge services like API Gateway.