AWS DevOps Engineer – Professional (DOP-C02) — Free Sample Questions
Practice with 30 free DevOps Engineer Professional questions covering CI/CD automation, infrastructure as code, and operational excellence at scale on AWS.
Exam Domains
- SDLC Automation (22%) — CodePipeline cross-account deployments, CodeBuild caching, approval gates, artifact encryption
- Configuration Management and IaC (17%) — CloudFormation macros, custom resources, CDK constructs, Terraform state management
- Resilient Cloud Solutions (15%) — multi-region active-active, Route 53 failover, chaos engineering, auto-scaling policies
- Monitoring and Logging (15%) — centralized logging with Kinesis Firehose, CloudWatch cross-account observability, X-Ray service maps
- Incident and Event Response (14%) — EventBridge rules, SNS fan-out, SSM Incident Manager, automated runbooks
- Security and Compliance (17%) — secrets rotation, container image scanning, compliance as code with Config rules
What DOP-C02 Expects
This exam tests your ability to automate everything — from source commit to production deployment to incident response. You must:
- Design pipelines that deploy to multiple accounts and regions safely
- Implement canary and blue/green deployments with automatic rollback
- Centralize logs and metrics across hundreds of accounts
- Automate compliance enforcement and remediation
Study Recommendations
- Build a multi-stage CodePipeline with cross-account deployment — hands-on experience is critical
- Understand CloudFormation StackSets, drift detection, and change sets in depth
- Study ECS/EKS deployment strategies: rolling, blue/green, canary with App Mesh
- Know how to implement guardrails: SCPs, Config rules, EventBridge + Lambda remediation
Full Question Bank
Access 600 DOP-C02 questions in 30 quizzes and 2 full-length 75-question practice exams.
All 30 Free Sample Questions
Question 1 — Domain 1: SDLC Automation (22%)
A DevOps engineer is configuring a CodeBuild project that must build Docker images and push them to Amazon ECR. The build environment needs to run Docker commands. The engineer wants to use the most secure and efficient approach. Which CodeBuild environment configuration should be used?
- Use a Linux environment with the aws/codebuild/standard:5.0 image and enable privileged mode to allow Docker daemon access.
- Use a Windows environment with Docker Desktop installed. Configure the build to use Windows containers for better compatibility.
- Use a Linux environment with the aws/codebuild/standard:5.0 image without privileged mode. Use buildah or kaniko to build images without requiring Docker daemon access. — Correct answer
- Use a custom Docker image with Docker-in-Docker (DinD) installed. Run the build without privileged mode for better security.
Explanation:
- Why correct: Using buildah or kaniko eliminates the need for privileged mode, which significantly improves security by reducing the attack surface. These tools can build OCI-compliant container images without requiring access to the Docker daemon. This approach follows security best practices while maintaining full functionality for building and pushing images to ECR.
- Why A is wrong: While this approach works, enabling privileged mode grants the build container elevated permissions that could be exploited if the build environment is compromised. Privileged mode should be avoided when alternatives exist. This is a functional but less secure solution.
- Why B is wrong: Docker-in-Docker has known security and performance issues. Running Docker inside Docker creates complex networking and storage scenarios. Additionally, DinD typically requires privileged mode to function properly, so this configuration likely wouldn't work as described.
- Why D is wrong: Windows environments are more expensive and slower to provision than Linux environments. Docker Desktop licensing may have restrictions for enterprise use. Windows containers are not necessary for building Linux container images, which are the standard for most AWS deployments.
Question 2 — Domain 1: SDLC Automation (22%)
A DevOps team is designing a multi-stage CI/CD pipeline using CodePipeline with CodeBuild for a microservices application deployed on Amazon ECS. The team needs to integrate multiple types of automated tests to maximize deployment confidence while keeping total pipeline execution time reasonable. Which arrangement of test types across pipeline stages follows AWS best practices for test placement?
- Run unit tests and static code analysis during the build stage in CodeBuild. After deploying to a staging environment, run integration tests and API contract tests in a separate CodeBuild action. After deploying to production, run smoke tests using CloudWatch Synthetics canaries to verify critical endpoints. — Correct answer
- Run all test types—unit tests, integration tests, performance tests, and end-to-end tests—in a single CodeBuild project during the build stage to simplify pipeline configuration and minimize the number of pipeline stages.
- Run only unit tests during the build stage. Skip integration and acceptance testing to keep the pipeline fast. Rely on production monitoring with CloudWatch alarms and X-Ray tracing to detect issues after deployment.
- Run integration tests and end-to-end tests during the build stage before any deployment. After deploying to staging, run unit tests to verify the deployed code. Run performance tests against production after deployment.
Explanation:
- Why A is correct: This follows the testing pyramid and shift-left principles. Fast, cheap tests (unit tests, static analysis) run first during the build stage, providing rapid feedback. Tests that require a running environment (integration, contract tests) run after staging deployment. Lightweight smoke tests verify production health post-deployment. This arrangement balances speed with confidence—failures are caught as early as possible in the pipeline.
- Why B is wrong: Running all test types in a single build stage is impractical because integration tests, end-to-end tests, and performance tests require a deployed application environment to test against. Unit tests and static analysis can run against source code, but integration and E2E tests need running services, databases, and network connectivity that don't exist in a build-only stage. This also creates an extremely long build step.
- Why C is wrong: Skipping integration and acceptance testing removes critical safety nets before production deployment. While monitoring is important, it is reactive—issues are detected after they impact users. Integration tests catch problems like broken API contracts, database migration failures, and service communication issues that unit tests cannot detect. This violates the principle of testing before deployment.
- Why D is wrong: The test ordering is inverted. Integration and end-to-end tests should not run before any deployment because they need a running environment. Running unit tests after staging deployment is wasteful since unit tests don't require a deployed environment—they should run during the build stage for the fastest feedback. Performance testing against production risks impacting real users.
Question 3 — Domain 1: SDLC Automation (22%)
A company needs to share AMIs built in a central Tools account with multiple application accounts across different AWS regions. AMIs must be encrypted with KMS keys and sharing must be automated when new AMIs are created. Which solution provides automated, secure AMI sharing?
- Configure EC2 Image Builder in the Tools account to automatically share AMIs with target accounts and copy to target regions. Create KMS key grants in each region allowing target accounts to use the encryption keys.
- Create an SSM Automation document that shares AMIs and copies them to target regions. Schedule the automation to run daily using Maintenance Windows to check for new AMIs and process sharing.
- Create an AWS Organizations resource share using AWS Resource Access Manager (RAM). Add AMIs to the resource share to automatically share with accounts in the organization.
- Use EventBridge in the Tools account to detect AMI creation events. Trigger a Lambda function that shares the AMI with target accounts using ModifyImageAttribute API and copies AMIs to target regions with re-encryption using region-specific KMS keys. — Correct answer
Explanation:
- Why correct: EventBridge detects AMI creation events in real-time. Lambda can automate the sharing process using ModifyImageAttribute API and copy AMIs to target regions. When copying encrypted AMIs across regions, they must be re-encrypted with region-specific KMS keys, which Lambda can handle. This provides fully automated, event-driven AMI sharing with proper encryption handling.
- Why A is wrong: Image Builder distribution settings can share AMIs with specific accounts and regions, but only for AMIs built by Image Builder itself. The question states AMIs are built in a central Tools account without specifying Image Builder as the build tool. EventBridge + Lambda (option D) provides a general-purpose, event-driven solution that works regardless of how AMIs are created and can dynamically add new target accounts without reconfiguring pipelines.
- Why C is wrong: AWS RAM does not support sharing EC2 AMIs. RAM supports resources like VPC subnets, Transit Gateways, License Manager configurations, and Capacity Reservations, but AMIs are not a shareable resource type. AMI sharing must be done using the EC2 ModifyImageAttribute API as in option D.
- Why B is wrong: Running SSM Automation on a daily schedule introduces significant delay between AMI creation and sharing. The requirement states sharing must be automated when new AMIs are created, implying near-real-time. EventBridge + Lambda (option D) provides event-driven, immediate sharing triggered by the actual AMI creation event, without waiting for a scheduled window.
Question 4 — Domain 1: SDLC Automation (22%)
A company deploys Lambda functions using AWS CodeDeploy. They want to implement gradual deployment where traffic is shifted linearly over 10 minutes. If errors increase during deployment, it should automatically roll back. Which Lambda deployment configuration should be used?
- Use AWS Step Functions to orchestrate gradual traffic shifting. Implement a state machine that updates Lambda alias weights incrementally and monitors error rates for rollback decisions.
- Use Lambda's built-in alias traffic shifting. Configure alias to shift 10% of traffic every minute using UpdateAlias API. Monitor CloudWatch metrics and manually trigger rollback if needed.
- Configure Lambda function versions with weighted aliases. Use EventBridge scheduled rules to incrementally update alias weights every minute. Use Lambda Insights for error monitoring.
- Use CodeDeploy deployment configuration 'CodeDeployDefault.LambdaLinear10PercentEvery1Minute'. Configure CloudWatch alarms for Lambda errors and associate them with the deployment group for automatic rollback. — Correct answer
Explanation:
- Why D is correct: CodeDeploy for Lambda provides predefined deployment configurations including Linear10PercentEvery1Minute which shifts traffic linearly over 10 minutes. Associating CloudWatch alarms with the deployment group enables automatic rollback if alarms trigger during deployment. This is the AWS-native solution for safe, automated Lambda deployments with monitoring and rollback.
- Why A is wrong: Using Step Functions for traffic shifting adds unnecessary complexity. CodeDeploy provides this functionality natively with better integration and less operational overhead. Step Functions would require custom state machine logic, error handling, and rollback implementation that CodeDeploy handles automatically.
- Why B is wrong: While Lambda aliases support traffic shifting, manually managing incremental shifts and rollback logic requires custom code and orchestration. CodeDeploy automates this entire workflow including monitoring and rollback. Manual approaches are more error-prone and operationally complex.
- Why C is wrong: EventBridge scheduled rules with manual alias updates is a complex, custom solution that doesn't provide the safety features of CodeDeploy. Lambda Insights provides monitoring but doesn't integrate with automated rollback. CodeDeploy provides a complete, managed solution.
Question 5 — Domain 1: SDLC Automation (22%)
A DevOps engineer configures AWS CodeBuild to build and test an application that connects to an Amazon RDS database during integration tests. The database credentials must be rotated every 30 days and must not be visible in build logs or source code. Which approach meets these requirements with the LEAST operational overhead?
- Store credentials in the buildspec.yml file as plaintext environment variables. Restrict access to the source repository to authorized developers only.
- Store credentials in AWS Secrets Manager with automatic rotation enabled. Reference them in the CodeBuild buildspec using the secrets-manager mapping under the env section. Grant the CodeBuild service role permission to read the secrets. — Correct answer
- Store credentials in an encrypted S3 object. Download and decrypt the file in the build commands section of buildspec.yml using the AWS CLI.
- Store credentials as CodePipeline pipeline-level environment variables with the PLAINTEXT type. CodePipeline passes them to CodeBuild at runtime.
Explanation:
- Why correct: Secrets Manager natively supports automatic rotation for RDS credentials, satisfying the 30-day rotation requirement. CodeBuild has built-in integration with Secrets Manager through the secrets-manager mapping in buildspec.yml, which injects secret values as environment variables without exposing them in logs. The CodeBuild service role just needs secretsmanager:GetSecretValue permission. This approach requires the least custom code and operational overhead.
- Why A is wrong: Storing credentials in plaintext in buildspec.yml is a critical security violation. Anyone with access to the repository can read the credentials, and they would appear in version control history. This does not support automatic rotation.
- Why C is wrong: While encrypted S3 objects protect credentials at rest, this approach requires custom scripts to download and decrypt during each build. It does not support automatic rotation. The operational overhead is higher than Secrets Manager's native CodeBuild integration.
- Why D is wrong: CodePipeline environment variables with PLAINTEXT type store values unencrypted and are visible in the pipeline configuration. Even using PARAMETER_STORE type, Parameter Store does not support automatic credential rotation for RDS. Secrets Manager (option B) provides both native rotation and CodeBuild integration.
Question 6 — Domain 2: Configuration Management and IaC (17%)
A DevOps engineer is using AWS CDK to define infrastructure for multiple application teams. They need to create S3 buckets with server-side encryption, versioning, lifecycle rules, and access logging. The configuration must enforce the company's security standards and be reusable across multiple CDK stacks without duplication. Which CDK approach BEST balances reusability with security compliance?
- Use a CDK L1 construct (CfnBucket) to define all bucket properties explicitly including encryption, versioning, lifecycle rules, and logging. Copy the construct definition into each stack that needs a compliant bucket.
- Use a CDK L2 construct (Bucket) with all required properties configured. Define the bucket in a single shared stack and use CloudFormation exports to share the bucket ARN with other stacks that need it.
- Create an AWS CloudFormation module for the S3 bucket configuration with all security settings. Import the module in CDK using CfnResource to use it across stacks.
- Create a custom CDK L3 construct (pattern) that encapsulates the company's S3 bucket standards including encryption, versioning, lifecycle rules, and access logging. Publish it to an internal construct library and import it into any stack that needs a compliant bucket. — Correct answer
Explanation:
- Why correct: CDK L3 constructs (also called patterns) encapsulate best practices and organizational standards into reusable, opinionated components. By packaging the company's S3 security requirements (encryption, versioning, lifecycle rules, access logging) into a custom construct shared as an internal library, teams get compliant buckets by default without needing to remember every configuration detail. L3 constructs can compose multiple L2 constructs and add custom logic, making them the CDK-native pattern for enforcing standards through reusable components.
- Why A is wrong: L1 constructs (Cfn* classes) are low-level 1:1 mappings to CloudFormation resources that require verbose, property-by-property configuration. They don't provide the higher-level defaults and type-safe abstractions that L2/L3 constructs offer. Copying L1 definitions across stacks creates duplication and a maintenance burden when standards change. A shared L3 construct (option D) is more maintainable and ensures consistency.
- Why B is wrong: Defining the bucket in a single stack and sharing its ARN via CloudFormation exports provides a shared resource, not a reusable pattern. If multiple stacks each need their own compliant bucket (for example, different applications needing separate buckets), they cannot create new buckets from a stack export. A reusable L3 construct (option D) allows each stack to create its own fully compliant bucket instance.
- Why C is wrong: Using a CloudFormation module through CfnResource in CDK loses CDK's type safety, IDE auto-completion, and programming language benefits. CDK-native constructs (option D) provide a better developer experience with compile-time checks, idiomatic integration with other CDK constructs, and the ability to use programming logic (loops, conditionals) within the construct definition.
Question 7 — Domain 2: Configuration Management and IaC (17%)
A company with 50 AWS accounts in an organization needs to ensure that no resources are deployed outside of us-east-1 and eu-west-1. The restriction must apply to all member accounts and cannot be bypassed by account administrators. Which approach enforces this requirement?
- Create IAM policies in each account that deny all actions when the requested Region is not us-east-1 or eu-west-1. Attach the policies to all IAM users and roles in every member account.
- Create an SCP that denies all actions when aws:RequestedRegion is not in the approved list of us-east-1 and eu-west-1. Attach the SCP to the organizational units containing the member accounts. Include conditions to exclude global services such as IAM, STS, and CloudFront. — Correct answer
- Deploy AWS Config rules in each account to detect resources provisioned in unapproved Regions. Configure auto-remediation to automatically delete resources found outside of us-east-1 and eu-west-1.
- Enable the AWS Control Tower Region deny guardrail, which uses an SCP to block all AWS API calls to non-approved Regions across the entire organization including the management account.
Explanation:
- Why correct: SCPs with the aws:RequestedRegion condition key are the recommended organizational-level control for restricting which Regions member accounts can use. Attaching the SCP to the OU applies it to all accounts in that OU, including future accounts. Excluding global services (IAM, STS, CloudFront, Route 53, etc.) through conditions prevents breaking critical functionality that only operates in us-east-1.
- Why A is wrong: IAM policies in individual accounts can be modified or removed by account administrators, making them unreliable as a security boundary. SCPs are enforced at the organizational level and cannot be overridden by member account administrators, providing a stronger guarantee.
- Why C is wrong: AWS Config rules are detective controls that detect resources after they are created in unapproved Regions. Auto-remediation by deleting resources is disruptive and creates a window of non-compliance between creation and deletion. SCPs are preventive controls that block the API call before the resource is created.
- Why D is wrong: While Control Tower does offer a Region deny setting, it is implemented as an SCP and therefore does not apply to the management account (SCPs never affect the management account). The option incorrectly states it blocks the management account. Additionally, Control Tower's Region deny may not provide the same granular exclusion control for global services that a custom SCP does.
Question 8 — Domain 2 - Configuration Management and IaC (17%)
A DevOps engineer must ensure that every new EC2 instance launched in a production account automatically receives a specific set of software packages and configuration files within minutes of launch. The solution must work for instances launched manually, by Auto Scaling, or by other AWS services. Which approach provides the MOST reliable automation?
- Create an Amazon EventBridge rule to detect the EC2 instance state change to 'running'. Target an AWS Lambda function that calls the Systems Manager API to add a tag and associate the instance with the State Manager association for the desired configuration. — Correct answer
- Use AWS Config to detect new EC2 instances. Create a Config rule that triggers an AWS Lambda remediation function to install and configure the software when an instance is found without the required tags.
- Create an Auto Scaling lifecycle hook that pauses instances in the Pending:Wait state. Use an Amazon SNS notification to trigger an AWS Lambda function that configures software and completes the lifecycle action.
- Write a cron job on each EC2 instance that checks every 5 minutes whether the required software is installed and configures it if missing.
Explanation:
- Why correct: EventBridge captures EC2 instance state-change events reliably for all launch methods (manual, Auto Scaling, service-initiated). The Lambda function can tag the instance and use Systems Manager State Manager associations to push the desired configuration. State Manager ensures the configuration is applied and can re-apply it if drift occurs, providing continuous compliance. This approach works universally regardless of how instances are launched.
- Why B is wrong: AWS Config evaluation has inherent latency (typically minutes to hours for resource recording and rule evaluation), which doesn't meet the 'within minutes of launch' requirement reliably. EventBridge (option A) provides near-real-time event detection. Config is better suited for ongoing compliance monitoring than immediate remediation.
- Why C is wrong: Auto Scaling lifecycle hooks only work for instances launched by Auto Scaling groups. The requirement specifies instances launched manually, by Auto Scaling, or by other services. EventBridge (option A) captures all EC2 launches regardless of the source.
- Why D is wrong: A cron job on each instance requires the cron job itself to be pre-installed, creating a bootstrapping problem. It also adds unnecessary delay (up to 5 minutes) and doesn't provide centralized visibility or control. Systems Manager State Manager (option A) provides server-side orchestration without requiring pre-installed agents beyond the SSM Agent (which is pre-installed on Amazon Linux and Windows AMIs).
Question 9 — Domain 2: Configuration Management and IaC (17%)
A large enterprise wants to allow development teams to provision their own infrastructure (EC2 instances, RDS databases, S3 buckets) while ensuring all provisioned resources comply with company security and tagging standards. Teams should not be able to provision unapproved configurations. Which approach provides governed self-service with the LEAST operational overhead?
- Create AWS Service Catalog portfolios with pre-approved product templates that define approved resource configurations. Apply launch constraints with IAM roles that enforce tagging and security standards. Share portfolios with development accounts through AWS Organizations. — Correct answer
- Create IAM policies in each development account that use conditions to restrict developers to approved instance types, require encryption, and enforce tagging on all resource creation API calls.
- Deploy AWS Config rules that evaluate resource compliance after provisioning. Configure automatic remediation with Systems Manager Automation to fix or terminate non-compliant resources.
- Build a custom internal self-service portal backed by Lambda functions. The portal validates infrastructure requests against an approved configuration database before provisioning resources via CloudFormation.
Explanation:
- Why A is correct: AWS Service Catalog allows the platform team to create portfolios containing pre-approved CloudFormation-based products. Launch constraints attach an IAM role to a product so that developers can provision resources without needing direct IAM permissions to create those resources—the product's launch role does it on their behalf with built-in guardrails (e.g., enforced tagging, encryption, approved instance types). Portfolios can be shared across accounts via AWS Organizations, providing centralized governance with decentralized self-service.
- Why B is wrong: IAM policies alone can restrict which API calls developers make, but they cannot enforce complex provisioning standards like required tags, specific subnet selections, or approved parameter combinations. IAM conditions become extremely complex to maintain at scale and do not provide a self-service catalog experience. Service Catalog (option A) provides a curated, governed provisioning workflow.
- Why C is wrong: AWS Config rules detect non-compliant resources after they are created, which means non-compliant resources exist (even temporarily) until remediation runs. This is a reactive (detective) approach. Service Catalog (option A) is preventive—it only allows approved configurations to be provisioned in the first place, which is stronger governance.
- Why D is wrong: Building a custom self-service portal requires significant development and maintenance effort for the provisioning logic, validation rules, UI, and authentication. AWS Service Catalog (option A) provides this functionality as a managed service with native CloudFormation integration, IAM launch constraints, and Organizations sharing—without custom code.
Question 10 — Domain 3: Resilient Cloud Solutions (15%)
A developer accidentally runs a script that bulk-deletes 50,000 records from a production DynamoDB table. The incident occurred approximately 2 hours ago. The table has Point-in-Time Recovery (PITR) enabled, DynamoDB Streams active with a 24-hour retention window, Global Tables replicating to us-west-2, and on-demand backups taken every 12 hours (the last backup was 10 hours ago). Which approach recovers the deleted data with the LEAST data loss and operational effort?
- Use DynamoDB Point-in-Time Recovery (PITR) to restore the table to a timestamp just before the deletion. PITR provides continuous backups with per-second granularity for the last 35 days. — Correct answer
- Read the data from the Global Tables replica in us-west-2. The replica should still contain the deleted records since cross-region replication has some lag.
- Process the delete events from DynamoDB Streams and write custom Lambda code to extract the old item images and re-insert the deleted items.
- Restore the table from the most recent on-demand backup taken 10 hours ago. On-demand backups provide full table snapshots for recovery.
Explanation:
- Why A is correct: DynamoDB PITR provides continuous backups that allow restoring the table to any second within the last 35 days. The engineer can restore to a new table at the exact second before the bulk deletion, recovering all 50,000 records with zero data loss from the incident. PITR restoration is a single API call with no custom code required, minimizing operational effort.
- Why B is wrong: DynamoDB Global Tables replicate all operations—including deletes—across all configured regions within milliseconds to seconds. Two hours after the incident, the bulk deletion has long since propagated to the us-west-2 replica. Global Tables protect against regional outages, not against application-level data mutations or accidental deletions.
- Why C is wrong: While DynamoDB Streams contains the delete events from the last 24 hours, writing custom code to parse stream records, extract the previous item images, and re-insert them is complex and error-prone. It requires the stream to be configured with OLD_IMAGE or NEW_AND_OLD_IMAGES, adds development and testing time, and risks partial or incorrect recovery. PITR (option A) is a fully managed, single-step operation.
- Why D is wrong: The most recent on-demand backup was taken 10 hours ago, meaning any data written to the table in the 8 hours between that backup and the deletion incident would be lost. This results in significant data loss compared to PITR (option A), which can restore to the second before the incident.
Question 11 — Domain 3: Resilient Cloud Solutions (15%)
A data processing pipeline ingests files uploaded to S3 and processes them using EC2 instances in an Auto Scaling group. Processing time per file averages 5 minutes. During peak hours, the upload rate increases from 100 to 2,000 files per hour, and files are queued in an SQS standard queue. The team needs the processing fleet to scale based on queue depth so that backlogs are cleared within 30 minutes. Which scaling approach meets this requirement?
- Configure a target tracking scaling policy on the processing Auto Scaling group using the ApproximateNumberOfMessagesVisible metric divided by the number of running instances (backlog per instance), targeting an acceptable backlog that each instance can clear within 30 minutes — Correct answer
- Configure a CloudWatch alarm on the SQS ApproximateNumberOfMessagesVisible metric with a static threshold of 500 messages, triggering a step scaling policy that doubles the fleet size on each breach
- Configure a scheduled scaling action to increase the processing fleet during known peak upload hours and scale down during off-peak hours
- Set the Auto Scaling group minimum capacity high enough to handle the peak upload rate of 2,000 files per hour at all times
Explanation:
- Why A is correct: Target tracking on backlog-per-instance is the AWS-recommended approach for SQS-based scaling. The metric (ApproximateNumberOfMessagesVisible / GroupDesiredCapacity) represents how many messages each instance must process. By setting the target to a value each instance can clear within the 30-minute SLA (e.g., if each instance processes 12 files per 30 minutes, target = 12), Auto Scaling proportionally adjusts fleet size to match actual queue depth. When the backlog grows, more instances are added; when it shrinks, instances are removed. This provides precise, cost-efficient scaling that directly maps to the business SLA.
- Why B is wrong: A single static threshold with fleet-doubling is too coarse. A backlog of 501 messages triggers the same doubling as a backlog of 5,000 messages — overshooting on small backlogs and potentially undershooting on very large ones. Step scaling with multiple thresholds would be better than a single alarm, but target tracking (option A) eliminates the need to manually define thresholds and step sizes entirely.
- Why C is wrong: Scheduled scaling assumes the upload pattern is predictable and time-based. The scenario describes burst uploads that can vary in timing and volume. If a burst occurs outside the scheduled window, the fleet won't have capacity. Scheduled scaling is appropriate for predictable recurring patterns, not variable burst workloads.
- Why D is wrong: Maintaining peak capacity at all times handles any burst but wastes money during the baseline period (100 files/hour). Running 20x the baseline fleet 24/7 to handle occasional peaks is the most expensive option. Target tracking (option A) achieves the same burst handling while scaling down during low-traffic periods.
Question 12 — Domain 3: Resilient Cloud Solutions (15%)
A financial services company must implement a cross-Region disaster recovery solution for a three-tier web application. The solution must automatically detect primary Region failures and initiate recovery in the DR Region without manual intervention. Which THREE components should the DevOps engineer configure to build the automated recovery pipeline? (Select THREE)
- Amazon Route 53 health checks with failover routing policy to automatically redirect traffic to the DR Region when the primary endpoint becomes unhealthy. — Correct answer
- AWS Backup with cross-Region copy rules to replicate EBS snapshots and RDS snapshots to the DR Region on a defined schedule. — Correct answer
- AWS Systems Manager Automation runbooks to orchestrate recovery steps including database promotion, instance provisioning, and application configuration. — Correct answer
- Amazon CloudWatch dashboards configured to display DR Region metrics for manual monitoring by the operations team.
- AWS CloudTrail configured to log all API calls during the failover process for post-incident audit and review.
- Amazon SNS configured to publish failover notifications to the operations team requiring manual approval before each recovery step.
Explanation:
- Why A is correct: Route 53 health checks with failover routing provide the automated detection and traffic redirection needed to initiate recovery without manual intervention. This is the front door of any automated DR solution.
- Why B is correct: AWS Backup with cross-Region copy rules ensures that EBS snapshots, RDS snapshots, and other resource backups are automatically replicated to the DR Region, satisfying RPO requirements.
- Why C is correct: AWS Systems Manager Automation runbooks provide orchestrated, repeatable recovery workflows that can provision infrastructure, promote read replicas, and configure application resources in the correct sequence.
- Why D is wrong: CloudWatch dashboards provide visibility but do not detect failures or initiate recovery. They support manual monitoring, not automated recovery.
- Why E is wrong: CloudTrail provides API call auditing for post-incident review but does not contribute to failure detection or automated recovery initiation.
- Why F is wrong: SNS notifications are useful for alerting operations teams but requiring manual approval introduces delay and defeats the purpose of automated recovery.
Question 13 — Domain 3: Resilient Cloud Solutions (15%)
A global e-commerce company has users in North America, Europe, and Asia. The application requires single-digit millisecond read and write latency for all users and must remain available even if an entire AWS Region becomes unavailable. The company uses Amazon DynamoDB for its product catalog and shopping cart data. Which architecture meets these requirements?
- Deploy DynamoDB tables in us-east-1 with DynamoDB Accelerator (DAX) clusters in each Region to cache reads. Use Amazon CloudFront to route users to the nearest DAX cluster.
- Deploy DynamoDB tables in us-east-1. Configure cross-Region read replicas in eu-west-1 and ap-southeast-1. Use Route 53 latency-based routing to direct users to the nearest replica.
- Configure DynamoDB global tables with replicas in us-east-1, eu-west-1, and ap-southeast-1. Use Route 53 latency-based routing to direct users to the nearest Region's application tier. — Correct answer
- Deploy separate DynamoDB tables in each Region with AWS Lambda functions that synchronize data between Regions using DynamoDB Streams. Use Route 53 latency-based routing.
Explanation:
- Why C is correct: DynamoDB global tables provide fully managed, multi-Region, multi-active replication. Each replica accepts both reads and writes with single-digit millisecond latency for local access. Global tables automatically replicate changes across all Regions using last-writer-wins conflict resolution. If one Region becomes unavailable, the application seamlessly redirects to another Region's replica. Combined with Route 53 latency-based routing, users are directed to their closest Region for optimal latency.
- Why A is wrong: DAX is a read-through/write-through cache that must be deployed in the same Region and VPC as the DynamoDB table. DAX clusters cannot be placed in a different Region from the source table. Also, CloudFront is a content delivery network for HTTP/HTTPS content, not for routing DynamoDB or DAX API requests.
- Why B is wrong: DynamoDB does not offer a standalone "cross-Region read replica" feature. The correct feature for multi-Region replication is global tables. Additionally, read-only replicas would not satisfy the requirement for write operations in all Regions.
- Why D is wrong: Building custom replication using DynamoDB Streams and Lambda introduces significant operational complexity, potential data consistency issues, and replication lag. DynamoDB global tables provide this functionality natively with automatic conflict resolution, eliminating the need for custom synchronization code.
Question 14 — Domain 4 - Monitoring and Logging (15%)
A company runs a microservices application on Amazon ECS. The application logs contain a field called "response_time_ms" in JSON format. The DevOps team needs to create a CloudWatch alarm that triggers when the average response time exceeds 500 ms over a 5-minute period. The solution should not require additional compute resources. Which approach meets these requirements?
- Create a CloudWatch Logs subscription filter that sends log events to a Lambda function. The Lambda function parses the response_time_ms field and publishes it as a custom CloudWatch metric using PutMetricData.
- Create a CloudWatch metric filter on the log group with a filter pattern that extracts the response_time_ms JSON field as a metric value. Create a CloudWatch alarm on the resulting metric with a threshold of 500 ms and a period of 5 minutes. — Correct answer
- Use CloudWatch Logs Insights to run a scheduled query every 5 minutes that calculates the average response_time_ms. Configure an alarm on the query results.
- Export the CloudWatch Logs to Amazon S3 using CreateExportTask. Use Amazon Athena to query the logs and create a metric from the results.
Explanation:
- Why correct: CloudWatch metric filters allow you to extract metric data from log events by defining a filter pattern. When the pattern matches a log event, CloudWatch increments the metric or extracts a numeric value. This approach creates a custom CloudWatch metric that can be used to trigger alarms, all without any additional compute resources.
- Why A is wrong: Streaming logs to a Lambda function via a subscription filter and then calling PutMetricData works functionally, but it introduces unnecessary operational overhead (Lambda function code to maintain, IAM permissions, error handling, potential throttling). CloudWatch metric filters achieve the same result natively without extra infrastructure.
- Why C is wrong: CloudWatch Logs Insights is an interactive query engine for ad-hoc log analysis. It does not create persistent CloudWatch metrics or trigger alarms. It runs queries on demand or on a schedule, but each query result is not a metric data point that CloudWatch Alarms can monitor continuously.
- Why D is wrong: Exporting logs to S3 and using Athena adds significant latency (log export can take up to 12 hours) and requires managing an ETL pipeline. This is suitable for historical analysis, not real-time alerting based on log events.
Question 15 — Domain 4: Monitoring and Logging (15%)
A DevOps team needs to quickly troubleshoot a production issue by searching through 50 GB of application logs generated over the past 24 hours in CloudWatch Logs. They need to identify the most frequent error types, correlate them with specific request IDs, and determine the time range when errors spiked. The results must be available within minutes. Which approach is MOST efficient?
- Export the CloudWatch Logs to Amazon S3, then use Amazon Athena with an AWS Glue crawler to catalog the data and run SQL queries against the exported logs.
- Use CloudWatch Logs Insights to run queries directly against the log groups. Logs Insights supports aggregation functions, field-based filtering, and time-range analysis without requiring data export. — Correct answer
- Stream the logs to Amazon OpenSearch Service using a CloudWatch Logs subscription filter, then use OpenSearch Dashboards to search and visualize the results.
- Use Amazon EMR with Apache Spark to load and process the log data from CloudWatch Logs and identify error patterns.
Explanation:
- Why correct: CloudWatch Logs Insights is purpose-built for interactive, ad-hoc querying of log data already in CloudWatch Logs. It supports aggregations (stats count(*) by errorType), field extraction from JSON logs, filtering, and time-based analysis. Queries return results in seconds to minutes with no infrastructure to provision or data to export.
- Why A is wrong: Exporting logs to S3 and setting up Athena/Glue adds significant delay (CloudWatch log exports to S3 can take hours depending on volume) and operational steps. This approach is better suited for long-term historical analysis, not urgent production troubleshooting.
- Why C is wrong: Setting up an OpenSearch Service domain and subscription filter is a heavyweight architectural change that takes time to provision and configure. It is appropriate for an ongoing log analytics platform, not an urgent troubleshooting need against logs already in CloudWatch.
- Why D is wrong: EMR with Spark requires cluster provisioning, data loading, and Spark job development. This is disproportionate overhead for ad-hoc troubleshooting and is better suited for batch processing of very large datasets.
Question 16 — Domain 4: Monitoring and Logging (15%)
A company stores application logs from multiple services in a centralized S3 bucket. The DevOps team needs to automatically process new log files as they arrive and deliver them to both OpenSearch Service for real-time search and CloudWatch Logs for metric filter analysis. The solution must process logs within minutes of arrival and handle varying log volumes. Which TWO actions should the team configure to meet these requirements? (Select TWO)
- Configure S3 event notifications for s3:ObjectCreated:* events on the log bucket and invoke a Lambda function to parse and forward logs to OpenSearch Service. — Correct answer
- Use AWS Data Pipeline to periodically copy log files from S3 to OpenSearch Service on a daily schedule.
- Configure CloudWatch Logs agent on the application servers to send logs directly to OpenSearch Service, bypassing S3.
- Enable S3 event notifications to trigger a Lambda function that transforms logs into CloudWatch Logs format and creates CloudWatch log groups per application. — Correct answer
- Use S3 replication to copy log files to another S3 bucket in a different Region and query them with Athena.
- Create an EventBridge scheduled rule to invoke Lambda every hour to scan the S3 bucket for new log files.
Explanation:
- Why A is correct: S3 event notifications for ObjectCreated events trigger Lambda in near real-time as log files arrive. Lambda can parse the log content and use the OpenSearch bulk API to index logs, providing real-time search capability within minutes of log arrival. This is the standard pattern for S3-to-OpenSearch ingestion.
- Why D is correct: A second S3 event notification (or the same Lambda function with dual targets) can transform logs and push them to CloudWatch Logs using the PutLogEvents API. Once in CloudWatch Logs, metric filters can extract custom metrics from log patterns. This satisfies the CloudWatch Logs requirement.
- Why B is wrong: AWS Data Pipeline runs on a schedule (e.g., daily) and introduces significant latency. The requirement specifies processing within minutes of arrival, which rules out batch-oriented scheduled approaches.
- Why C is wrong: CloudWatch Logs agent sends logs directly from servers to CloudWatch Logs, but this bypasses the centralized S3 bucket architecture. It also does not address the OpenSearch delivery requirement and changes the existing logging architecture.
- Why E is wrong: S3 cross-Region replication with Athena is a valid analytics pattern, but Athena is designed for ad-hoc SQL queries, not real-time search or metric filter analysis. It does not deliver logs to OpenSearch Service or CloudWatch Logs.
- Why F is wrong: A scheduled EventBridge rule polling every hour introduces up to 60 minutes of latency, which violates the 'within minutes' requirement. S3 event notifications provide near-instant triggers, making polling unnecessary and less efficient.
Question 17 — Domain 4: Monitoring and Logging (15%)
A company needs to continuously stream all CloudWatch metrics from multiple AWS accounts into a centralized Amazon S3 data lake for long-term analytics and cost optimization reporting. The solution must deliver metrics in near-real-time with minimal management overhead. Which approach should a DevOps engineer implement?
- Use the CloudWatch GetMetricData API from a scheduled Lambda function to poll metrics and write them to S3.
- Configure CloudWatch metric streams in each account to stream metrics to an Amazon Kinesis Data Firehose delivery stream that delivers to S3. — Correct answer
- Create CloudWatch Logs subscriptions to forward metric data to an S3 bucket in the central account.
- Export CloudWatch dashboards to S3 on a scheduled basis using EventBridge rules.
Explanation:
- Why A is wrong: CloudWatch GetMetricData API with scheduled Lambda functions requires custom code to poll metrics, handle pagination, manage delivery failures, and write to S3. This is high operational overhead compared to a managed streaming solution.
- Why B is correct: CloudWatch metric streams continuously stream CloudWatch metrics in near-real-time to a Kinesis Data Firehose delivery stream, which can buffer, optionally transform, and deliver data directly to an S3 bucket. This is a fully managed, serverless pipeline that requires no custom code for the streaming and delivery components. Cross-account metric streaming can be configured using CloudWatch metric streams in each source account pointing to a centralized Firehose in the destination account.
- Why C is wrong: CloudWatch Logs subscriptions are for log data, not metric data. Metrics and logs are different data types in CloudWatch. You cannot subscribe to metric data through log subscriptions.
- Why D is wrong: Exporting CloudWatch dashboards produces visual snapshots or JSON definitions of dashboards, not raw metric data points. Dashboards are visualization tools, not data export mechanisms for analytics.
Question 18 — Domain 5: Incident and Event Response (14%)
A security team needs to detect when IAM policies are modified in any way, including CreatePolicy, AttachRolePolicy, PutRolePolicy, and DeletePolicy API calls. When detected, the event details must be sent to a Lambda function for analysis and to an SNS topic to alert the security team. The detection must occur within seconds of the API call. Which solution meets these requirements?
- Enable AWS Config with IAM policy change rules. Configure Config to evaluate on each change and invoke a Lambda function. Add an SNS notification target to the Config rule.
- Configure CloudTrail to deliver logs to a CloudWatch Logs group. Create metric filters for each IAM API call. Set CloudWatch alarms that trigger the Lambda function and SNS topic when filters match.
- Create an EventBridge rule with an event pattern matching CloudTrail IAM API calls for the specified actions. Add both the Lambda function and the SNS topic as targets of the rule. — Correct answer
- Use IAM Access Analyzer to monitor policy changes. Configure Access Analyzer findings to trigger the Lambda function and publish to the SNS topic.
Explanation:
- Why correct: EventBridge receives CloudTrail management events in near real-time and supports event patterns that match on specific API call names within the detail.eventName field. A single rule can match multiple API actions using a list in the event pattern. EventBridge rules support up to five targets, so both the Lambda function and SNS topic can be triggered from the same rule, meeting the seconds-level latency requirement.
- Why A is wrong: AWS Config evaluates configuration changes but introduces latency during evaluation processing. Config rules do not natively support dual targets (Lambda and SNS) from the same evaluation, and the detection latency is typically minutes, not seconds.
- Why B is wrong: CloudTrail log delivery to CloudWatch Logs has inherent latency of several minutes. Metric filters process logs only after delivery, making this approach too slow for the seconds-level requirement. Setting up separate metric filters and alarms for each API call also adds operational complexity.
- Why D is wrong: IAM Access Analyzer evaluates resource-based policies for external access, not for detecting specific IAM API calls. It does not monitor CreatePolicy, AttachRolePolicy, or DeletePolicy actions as events.
Question 19 — Domain 5: Incident and Event Response (14%)
A company requires that all new S3 buckets have default server-side encryption enabled immediately upon creation. The DevOps engineer must implement an automated solution that enforces this requirement with minimal latency. Which approach meets these requirements?
- Create an AWS Config rule for s3-bucket-server-side-encryption-enabled with an automatic SSM Automation remediation action.
- Create an Amazon EventBridge rule that matches CreateBucket API calls from CloudTrail. Configure a Lambda function target that enables default encryption on the newly created bucket. — Correct answer
- Create an S3 bucket policy template that denies PutObject requests without encryption headers. Apply the policy to all buckets using a scheduled Lambda function.
- Create an AWS Organizations SCP that enforces S3 default encryption across all accounts in the organization.
Explanation:
- Why B is correct: Amazon EventBridge can match CloudTrail API events such as CreateBucket. An EventBridge rule with a pattern matching s3.amazonaws.com CreateBucket triggers a Lambda function that calls PutBucketEncryption to enforce AES-256 or aws:kms encryption. This is event-driven and executes within seconds of bucket creation.
- Why A is wrong: AWS Config with auto-remediation can enforce encryption but operates on a configuration recording and evaluation cycle that is slower than a direct EventBridge-to-Lambda path for immediate enforcement. The question specifies enforcement at the moment of creation.
- Why C is wrong: An S3 bucket policy denying unencrypted uploads (aws:SecureTransport or s3:x-amz-server-side-encryption conditions) prevents unencrypted object uploads but does not enable default bucket encryption. Each bucket would need the policy applied manually or through another automation.
- Why D is wrong: SCPs prevent actions across an organization but cannot directly enforce enabling default encryption on new buckets. An SCP could deny s3:CreateBucket conditionally, but that blocks creation rather than remediating the configuration after creation.
Question 20 — Domain 5: Incident and Event Response (14%)
A DevOps engineer is troubleshooting an Amazon ECS service that is stuck in a deployment loop. The service repeatedly starts new tasks, which pass their health checks initially but then fail the Application Load Balancer (ALB) target group health check after 90 seconds. The ECS service's deployment circuit breaker is enabled with rollback. CloudWatch metrics show that the HealthyHostCount for the target group drops to zero during each deployment attempt. What is the MOST likely root cause and appropriate resolution?
- The ECS service's health check grace period is too short, causing ECS to mark tasks as unhealthy before the application finishes starting. Increase the health check grace period on the ECS service to give the application enough time to pass ALB health checks. — Correct answer
- The ECS deployment circuit breaker threshold is too aggressive. Disable the circuit breaker to allow the deployment to eventually succeed after enough task replacements.
- The ALB target group is configured with the wrong protocol. Change the target group protocol from HTTPS to HTTP so that health checks can reach the application.
- The ECS service's desired count is set too low. Increase the desired count to ensure there are enough healthy tasks to maintain the HealthyHostCount above zero during deployment.
Explanation:
- Why correct: The health check grace period tells ECS how long to wait before checking ALB health check results for a newly launched task. If the grace period is shorter than the time the application needs to fully initialize and begin responding to health checks, ECS marks the task as unhealthy and replaces it — creating a deployment loop. Increasing the grace period to match the application's actual startup time resolves the loop.
- Why B is wrong: Disabling the deployment circuit breaker removes a safety mechanism that prevents indefinite failed deployments. It does not address the root cause — the tasks are genuinely failing health checks. Without the circuit breaker, the service would continuously cycle through failing tasks indefinitely.
- Why A is correct: The question states that tasks pass health checks initially but fail after 90 seconds, which indicates the protocol is correct (requests are reaching the app). A protocol mismatch would cause immediate health check failures, not delayed ones.
- Why C is wrong: Increasing desired count does not solve the health check timing issue. More tasks would simply go through the same startup-then-fail cycle. The problem is not insufficient task count but insufficient time for tasks to become healthy.
Question 21 — Domain 5: Incident and Event Response (14%)
A company processes financial transactions through a microservices architecture. When the payment service emits an OrderCompleted event, three independent downstream systems must react: an invoice generator, a loyalty-points service, and an analytics pipeline. Each consumer must receive every event independently and process at its own pace. Which architecture should the DevOps engineer implement?
- Publish the OrderCompleted event to an Amazon SNS topic with three Amazon SQS queue subscriptions, one per downstream system. — Correct answer
- Send the OrderCompleted event to a single Amazon SQS queue and configure all three downstream systems to poll the same queue.
- Create an Amazon EventBridge rule that routes OrderCompleted events to a single AWS Lambda function that calls each downstream system sequentially.
- Write events to an Amazon Kinesis data stream with a single shard and have all three systems consume from the stream.
Explanation:
- Why correct (A): An SNS topic implements the fan-out pattern. When the payment service publishes to the SNS topic, each SQS queue subscription receives an independent copy of the message. Each consumer polls its own queue at its own rate, providing decoupling, independent scaling, and fault isolation between consumers.
- Why B is wrong: A single SQS queue with multiple consumers implements the competing-consumer pattern, where each message is processed by only ONE consumer. The three systems would compete for messages rather than each receiving every event.
- Why C is wrong: EventBridge with a single Lambda target only routes to one consumer. While EventBridge supports multiple targets per rule, this option specifies a single Lambda target, which does not meet the fan-out requirement for all three systems.
- Why D is wrong: Kinesis Data Streams with a single shard limits throughput to 1 MB/s ingress and 2 MB/s egress. While multiple consumers can read from Kinesis, a single shard creates a bottleneck and Kinesis is better suited for high-volume ordered streaming rather than event fan-out to independent services.
Question 22 — Domain 6 - Security and Compliance (17%)
A company with 200 AWS accounts organized into OUs needs to prevent any principal—including root users—from launching resources outside of us-east-1 and eu-west-1. The restriction must apply regardless of the IAM policies attached to individual users or roles. Which solution meets these requirements?
- Create IAM policies that deny all actions outside the two regions and attach them to every IAM user and role in each account.
- Attach an SCP to the organization root or relevant OUs that explicitly denies all actions when the aws:RequestedRegion condition key is not us-east-1 or eu-west-1. — Correct answer
- Enable AWS Config rules in each account to detect and automatically delete resources created outside the approved regions.
- Configure VPC settings and security groups in each account to block traffic to non-approved regions.
Explanation:
- Why correct: Service control policies (SCPs) attached at the OU or organization root level act as guardrails that limit the maximum available permissions for all principals in member accounts, including the root user. An SCP with an explicit deny on all actions where aws:RequestedRegion is not us-east-1 or eu-west-1 enforces the region restriction organization-wide regardless of individual IAM policies.
- Why A is wrong: IAM policies are identity-based and would need to be attached to every user and role across all 200 accounts. They also cannot restrict the account root user because the root user has full access regardless of IAM policies attached to it.
- Why C is wrong: AWS Config rules can detect non-compliant resources in disallowed regions, but they are detective controls, not preventive. Resources could still be launched in unauthorized regions before a remediation action triggers.
- Why D is wrong: VPC configurations and security groups control network access within a VPC, not which AWS regions can be used. Services like S3, IAM, and Lambda operate independently of VPC configurations.
Question 23 — Domain 6: Security and Compliance (17%)
A company runs multiple public-facing web applications behind Application Load Balancers (ALBs). TLS certificates are currently managed manually and have caused outages due to expired certificates. The DevOps team needs an automated solution to provision and renew TLS certificates for these ALBs. Which approach meets this requirement with the LEAST operational overhead?
- Generate certificates using AWS CloudHSM and import them into ACM for use with ALBs. Set up a Lambda function to renew them before expiry.
- Purchase certificates from a third-party CA, import them into ACM, and create CloudWatch alarms to alert 30 days before expiry for manual renewal.
- Use ACM Private CA to issue public certificates for the ALBs. Configure automatic renewal through the Private CA API.
- Use AWS Certificate Manager (ACM) to request public certificates with DNS validation. Associate the certificates with the ALBs. ACM automatically renews certificates before expiry. — Correct answer
Explanation:
- Why correct: ACM public certificates requested with DNS validation are fully managed by AWS. ACM automatically renews these certificates before they expire — as long as the DNS validation CNAME record remains in place and the certificate is associated with an AWS resource. This eliminates the operational burden of tracking certificate expiry and performing manual renewals.
- Why A is wrong: CloudHSM is for storing private keys on dedicated HSMs for compliance requirements (e.g., FIPS 140-2 Level 3). CloudHSM does not integrate directly with ALBs for TLS termination — imported certificates require manual renewal tracking, which doesn't reduce operational overhead.
- Why B is wrong: Imported third-party certificates in ACM are NOT automatically renewed by ACM. This approach still requires manual renewal, which doesn't solve the expiry problem.
- Why C is wrong: ACM Private CA issues private certificates for internal use, not publicly trusted certificates for public-facing websites. Browsers would not trust certificates issued by a private CA.
Question 24 — Domain 6 - Security and Compliance (17%)
A company's compliance framework requires cryptographic proof that CloudTrail logs have not been modified after delivery and that only the security team can decrypt and read log file contents. The operations team must be able to verify that log delivery is occurring but should not be able to read log contents. Which configuration meets these requirements?
- Enable CloudTrail log file integrity validation. Encrypt logs with SSE-S3. Grant operations teams read access to the S3 bucket.
- Enable CloudTrail log file integrity validation. Encrypt logs with a customer-managed KMS key with a restrictive key policy granting kms:Decrypt only to the security team. Grant operations teams s3:GetObject permission on digest files only. — Correct answer
- Enable S3 versioning on the log bucket. Encrypt logs with SSE-KMS using an AWS managed key. Grant both teams full S3 read access.
- Enable CloudTrail log file integrity validation. Store logs in S3 Glacier Instant Retrieval. Grant the security team S3 read access and deny all other principals.
Explanation:
- Why correct: Log file integrity validation generates SHA-256 digest files that provide cryptographic proof logs have not been tampered with — each digest file contains hashes of the log files delivered in the previous hour and is itself signed. A customer-managed KMS key allows granular access control through its key policy — only principals explicitly granted kms:Decrypt in the key policy can read log contents (security team), while operations teams can access digest files to verify delivery without being able to decrypt actual log contents.
- Why A is wrong: SSE-S3 encryption does not provide granular key-based access control. Any principal with s3:GetObject permission automatically decrypts SSE-S3 encrypted objects, meaning operations teams would be able to read log contents, violating the separation requirement.
- Why C is wrong: S3 versioning tracks object changes but does not provide cryptographic proof that logs are unmodified — it only ensures previous versions are retained. AWS managed KMS keys (aws/s3) cannot have their key policy customized to restrict decryption to specific principals, so any IAM principal with appropriate IAM permissions can decrypt objects.
- Why D is wrong: Storing logs in Glacier Instant Retrieval adds retrieval complexity but does not address the cryptographic proof requirement or the need for operations teams to verify delivery. Denying all other principals prevents operations teams from performing delivery verification using digest files.
Question 25 — Domain 6: Security and Compliance (17%)
A company operates 50 AWS accounts under AWS Organizations. The security team needs a single pane of glass to view security findings, compliance status, and threat detection results from all accounts. The solution must automatically include new accounts as they are created. Which approach should a DevOps engineer implement?
- Deploy GuardDuty in each account individually and create separate CloudWatch dashboards per account for the security team to review.
- Enable AWS Config aggregator in the management account and use Config rules to detect security findings across all member accounts.
- Configure CloudTrail organization trail and use Amazon Athena queries to correlate security events across all accounts.
- Designate a Security Hub delegated administrator account in AWS Organizations and enable Security Hub with auto-enable for all member accounts. — Correct answer
Explanation:
- Why D is correct: Security Hub supports a delegated administrator model in AWS Organizations. When auto-enable is turned on, all existing and new member accounts are automatically enrolled, and their findings (from GuardDuty, Inspector, Config, Macie, etc.) are aggregated into the administrator account. This provides the required single-pane-of-glass view with zero manual effort for new accounts.
- Why A is wrong: Deploying GuardDuty per account and building separate dashboards does not provide centralized aggregation. The security team would need to check each dashboard individually, which does not scale to 50+ accounts.
- Why B is wrong: AWS Config aggregator centralizes compliance rule evaluations, but it does not aggregate security findings from services like GuardDuty, Inspector, or Macie. It covers configuration compliance, not the full security posture.
- Why C is wrong: CloudTrail organization trails centralize API audit logs, and Athena can query them, but this only covers API activity. It does not aggregate security findings, compliance status, or threat detection results from multiple security services.
Question 26 — Domain 1 - SDLC Automation
A DevOps engineer is building a CI/CD pipeline using AWS CodePipeline for a healthcare application subject to HIPAA compliance. The security team requires that all pipeline artifacts be encrypted at rest using a customer-managed AWS KMS key that the security team controls. How should the engineer configure artifact encryption?
- Enable S3 default encryption with the AWS managed key (aws/s3) on the artifact bucket, as CodePipeline does not support custom KMS keys.
- Specify a customer-managed KMS key in the CodePipeline pipeline definition under the artifactStore configuration, and grant the CodePipeline service role kms:Encrypt and kms:Decrypt permissions on that key. — Correct answer
- Add a post_build phase in CodeBuild to manually encrypt each artifact using the AWS CLI before uploading to S3.
- Configure an S3 bucket policy that enforces SSE-S3 encryption on all PutObject requests from CodePipeline.
Explanation:
- Why B is correct: CodePipeline natively supports specifying a customer-managed KMS key in the artifactStore section of the pipeline definition. When configured, all artifacts stored in S3 are automatically encrypted using that key. The pipeline service role must have kms:Encrypt, kms:Decrypt, and kms:GenerateDataKey permissions on the specified key. This gives the security team full control over key rotation, access policies, and audit logging via CloudTrail — satisfying the HIPAA compliance requirement.
- Why A is wrong: CodePipeline does support customer-managed KMS keys in its artifactStore configuration. Using the AWS managed key (aws/s3) does not give the security team control over key policies, rotation schedule, or access grants — it is managed entirely by AWS and shared across S3 usage in the account.
- Why C is wrong: Manually encrypting artifacts in a CodeBuild post_build phase is unnecessary because CodePipeline handles artifact encryption natively. This approach adds complexity, introduces potential failure points, and requires custom code to manage encryption and decryption across pipeline stages.
- Why D is wrong: An S3 bucket policy enforcing SSE-S3 uses Amazon S3-managed keys, not customer-managed keys. The security team would have no control over the encryption key lifecycle, rotation, or access policies, which does not meet the compliance requirement for customer-controlled encryption.
Question 27 — Mixed (Multi-Account Governance Deep-Dive)
A DevOps team manages an AWS Organization with 120 accounts. New accounts are frequently provisioned through Control Tower Account Factory. The compliance team requires that API activity logging begins automatically for every new account without any manual intervention, and all logs must be stored in a secured central location that prevents deletion. Which approach meets these requirements?
- Create a CloudTrail organization trail in the management account. Configure the trail to log events from all accounts to a centralized S3 bucket with a bucket policy restricting delete operations. — Correct answer
- Use CloudFormation StackSets with Organizations integration to deploy individual CloudTrail trails to each account, targeting the organization root to include new accounts automatically.
- Create an Amazon EventBridge rule that detects CreateAccount API calls and triggers a Lambda function to create a CloudTrail trail in each new account.
- Configure AWS Config with a managed rule to monitor CloudTrail enablement and use auto-remediation with Systems Manager Automation to create trails in non-compliant accounts.
Explanation:
- Why correct: A CloudTrail organization trail, created in the management account, automatically enables logging for all current and future accounts in the organization. All events are delivered to a centralized S3 bucket. A bucket policy restricting delete operations protects the integrity of the audit logs. This requires zero manual intervention when new accounts are created through Account Factory.
- Why B is wrong: While StackSets with Organizations integration can deploy CloudFormation stacks to new accounts, this deploys individual per-account trails rather than a single organization trail. Each trail would write to its own location unless explicitly configured otherwise, and this creates more resources to manage compared to a single organization trail.
- Why C is wrong: This reactive approach depends on a Lambda function succeeding for every new account. If the Lambda function fails or is throttled, logging gaps occur. An organization trail is a native, declarative solution that doesn't depend on event-driven automation.
- Why D is wrong: This is a detective approach that only identifies non-compliance after the fact. There would be a gap between account creation and remediation. An organization trail provides logging from the moment the account is created.
Question 28 — Mixed (Networking Deep-Dive)
A company hosts a web application on an Application Load Balancer (ALB) in us-east-1. Users in Asia-Pacific and Europe report high latency for both static and dynamic content. The DevOps engineer needs to reduce global latency while keeping the ALB in us-east-1 as the origin. Which solution BEST addresses this requirement?
- Deploy additional ALBs in ap-southeast-1 and eu-west-1 with replicated application stacks, then use Route 53 latency-based routing to direct users to the nearest regional ALB.
- Create an Amazon CloudFront distribution with the ALB as a custom origin, caching static content at edge locations and routing dynamic requests over the AWS backbone. — Correct answer
- Enable AWS Global Accelerator with the ALB as an endpoint to route user traffic over the AWS global network and reduce TCP connection establishment latency.
- Configure Route 53 geolocation routing to direct European and Asia-Pacific users to fully replicated ALBs deployed in their respective nearest AWS Regions.
Explanation:
- Why B is correct: CloudFront caches static content at edge locations worldwide, eliminating round trips to the origin for cached assets. For dynamic content, CloudFront uses optimized AWS backbone connections between edge locations and the origin ALB, reducing latency compared to public internet paths. This solution requires no application replication and keeps the existing ALB as the single origin.
- Why A is wrong: Deploying additional ALBs in other regions requires replicating the entire application stack (compute, database, etc.) in those regions. This is significantly more complex and costly, and the question specifies keeping the ALB in us-east-1 as the origin.
- Why C is wrong: Global Accelerator routes traffic over the AWS backbone and improves TCP connection performance, but it does not cache content. For a web application with both static and dynamic content, CloudFront provides greater latency reduction through edge caching.
- Why D is wrong: Like option A, this requires replicating the full application stack in multiple regions. Geolocation routing directs users by location but does not reduce latency on its own—it requires fully operational regional deployments.
Question 29 — Mixed (Data/Storage/DR Deep-Dive)
A DevOps engineer notices intermittent latency spikes on an Amazon RDS for PostgreSQL Multi-AZ instance. The team needs to identify whether the root cause is CPU saturation, I/O bottlenecks, lock contention, or insufficient memory. Which approach provides the MOST comprehensive visibility into RDS performance with the LEAST operational overhead?
- Enable RDS Enhanced Monitoring and integrate with AWS X-Ray to trace database queries end-to-end.
- Use Amazon CloudWatch metrics for RDS combined with RDS Performance Insights to analyze database load by wait events, SQL statements, and host resources. — Correct answer
- Export RDS slow query logs to Amazon CloudWatch Logs and use CloudWatch Logs Insights to query for high-latency statements.
- Publish all RDS logs to Amazon OpenSearch Service and build custom Kibana dashboards for performance analysis.
Explanation:
- Why correct (B): Amazon CloudWatch provides built-in metrics for RDS such as CPUUtilization, FreeableMemory, ReadIOPS, WriteIOPS, and DatabaseConnections. RDS Performance Insights adds per-query analysis with wait event breakdowns, helping identify whether the root cause is CPU, I/O, lock contention, or memory pressure — all from a single dashboard without modifying the application or deploying additional infrastructure.
- Why A is wrong: RDS Enhanced Monitoring provides OS-level metrics at higher granularity, but AWS X-Ray is an application tracing service that instruments application code to trace requests. X-Ray cannot directly trace RDS internal query performance without application-side instrumentation and does not replace Performance Insights for database-level wait-event analysis.
- Why C is wrong: CloudWatch Logs can capture slow query and general logs, and CloudWatch Logs Insights can query them. However, this only shows queries exceeding the slow query threshold. It does not provide real-time performance metrics, wait event analysis, or holistic database performance monitoring the way Performance Insights does.
- Why D is wrong: Publishing RDS logs to Amazon OpenSearch Service and building Kibana dashboards provides log search capability, but it is a heavyweight solution requiring an OpenSearch cluster. It does not provide native RDS metrics (IOPS, CPU, connections) or Performance Insights wait-event analysis, and adds operational overhead managing the cluster.
Question 30 — Mixed Review (Domains 1–6)
A company runs a CI/CD pipeline using AWS CodePipeline and CodeBuild. Database credentials used during integration tests must be rotated every 30 days. The DevOps team wants to minimize operational overhead for credential management. Which approach meets these requirements?
- Store credentials in SSM Parameter Store as SecureString parameters. Write a custom Lambda function to rotate them monthly. Reference the parameters in the CodeBuild buildspec.
- Store credentials in AWS Secrets Manager with automatic rotation enabled. Reference secrets in the CodeBuild buildspec using the secrets-manager reference. Grant the CodeBuild service role permissions to the specific secrets. — Correct answer
- Encrypt credentials using KMS and store them as CodeBuild environment variables. Create a CloudWatch Events rule to trigger a Lambda function for monthly rotation.
- Deploy HashiCorp Vault on EC2 instances. Configure CodeBuild to retrieve credentials from Vault at build time. Use Vault's built-in rotation for database credentials.
Explanation:
- Why correct: AWS Secrets Manager supports automatic rotation via Lambda functions, making it ideal for database credentials that must be rotated every 30 days. CodeBuild can retrieve secrets at build time using the secrets-manager reference in the buildspec file, so credentials are never stored in the build environment. IAM roles for CodeBuild provide fine-grained access control to specific secrets.
- Why A is wrong: SSM Parameter Store SecureString parameters can store encrypted secrets, but Parameter Store does not have built-in automatic rotation. You would need to build and maintain a custom Lambda function and scheduling mechanism. Secrets Manager provides native rotation with pre-built rotation templates for common databases (RDS, Redshift, DocumentDB), reducing operational overhead.
- Why C is wrong: AWS KMS encrypts data at rest, and storing encrypted values in environment variables means the credentials exist in plaintext in the CodeBuild runtime environment after decryption. Environment variables are visible in the CodeBuild console and API responses, creating a security risk. The secrets-manager buildspec reference injects secrets at runtime without exposing them in environment variable configurations.
- Why D is wrong: HashiCorp Vault is a valid secrets management tool, but running it on EC2 introduces operational overhead (patching, scaling, HA configuration, backup). Since the requirement is to minimize operational overhead and the pipeline already uses AWS-native CodeBuild, Secrets Manager integrates natively without additional infrastructure to manage.
JavaScript is required to use this application.
Please enable JavaScript in your browser to access the full NestedCerts platform.
Contact: support@nestedcerts.com