English
中文English

DOP-C02 Practice Exam — DOP-C02：DevOps Engineer – Professional

1. The cloud-based question bank updates automatically, no need to retrieve it again.

2. Activate the question bank to access both Chinese and English versions.

3. Features include online exercises, mock exams, PDF downloads and video courses.

4. Study via mini-program or computer web page, valid for one year.

5. Activation codes can be bought directly or from Tmall official flagship store.

6. Contact customer service via WeChat, WhatsApp and Line for any issues.AWS Certified DevOps Engineer – Professional DOP-C02

Exam information

DevOps Engineer – Professional Exam Code: DOP-C02


·Registration Link: https://aws.amazon.com/cn/certification/certification-prep/testing/

·Exam Fee: 300 USD. Exam vouchers are available for purchase at approximately 1550 RMB  (For voucher inquiries, https://item.taobao.com/item.htm?id=991899961156 ).

·Exam Languages: Simplified Chinese, English, Japanese, etc. Certificates issued in different languages carry equal recognition. You may take the exam in Chinese and still download an English‑language certificate.

·Exam Location: Offline Pearson VUE test centers in designated cities, or online proctored exam on your personal computer (webcam monitoring throughout the exam; cheating is strictly prohibited).

·Exam Environment: For online exams, a plain background and noise‑free surroundings are required. A company meeting room is recommended if available, with a backup internet connection (VPN is not mandatory).

·Exam Format: 75 multiple‑choice questions. Total score is 1000 points; a score of 750 or higher is required to pass.

·Exam Duration: 180 minutes. Score reports will be sent via email within one business day after completion.

Sample questions

DOP-C02 · Q1
Topic 1 Question #1 A company has a mobile application that makes HTTP API calls to an Application Load Balancer (ALB). The ALB routes requests to an AWS Lambda function. Many different versions of the application are in use at any given time, including versions that are in testing by a subset of users. The version of the application is defined in the user-agent header that is sent with all requests to the API.After a series of recent changes to the API, the company has observed issues with the application. The company needs to gather a metric for each API operation by response code for each version of the application that is in use. A DevOps engineer has modified the Lambda function to extract the API operation name, version information from the user-agent header and response code.Which additional set of actions should the DevOps engineer take to gather the required metrics?
  • A.
    Modify the Lambda function to write the API operation name, response code, and version number as a log line to an Amazon CloudWatch Logs log group. Configure a CloudWatch Logs metric filter that increments a metric for each API operation name. Specify response code and application version as dimensions for the metric.
  • B.
    Modify the Lambda function to write the API operation name, response code, and version number as a log line to an Amazon CloudWatch Logs log group. Configure a CloudWatch Logs Insights query to populate CloudWatch metrics from the log lines. Specify response code and application version as dimensions for the metric.
  • C.
    Configure the ALB access logs to write to an Amazon CloudWatch Logs log group. Modify the Lambda function to respond to the ALB with the API operation name, response code, and version number as response metadata. Configure a CloudWatch Logs metric filter that increments a metric for each API operation name. Specify response code and application version as dimensions for the metric.
  • D.
    Configure AWS X-Ray integration on the Lambda function. Modify the Lambda function to create an X-Ray subsegment with the API operation name, response code, and version number. Configure X-Ray insights to extract an aggregated metric for each API operation name and to publish the metric to Amazon CloudWatch. Specify response code and application version as dimensions for the metric.

Answer: A

The scenario requires collecting granular metrics segmented by API operation, response code, and application version, all of which the Lambda function already extracts natively. The most efficient and natively supported approach for this use case leverages CloudWatch Logs metric filters, which are purpose-built to parse structured log data into persistent, dimensioned CloudWatch metrics. This approach avoids unnecessary additional services or complex configurations, directly addresses the requirement for segmented metrics, and aligns with AWS best practices for custom metric generation from application log data, a core competency for the DOP-C02 certification. Option Analysis: A. Correct. The Lambda function already has all required data points, so writing them directly to CloudWatch Logs is a low-effort first step. CloudWatch Logs metric filters natively support parsing values from log entries and assigning those values as dimensions for custom metrics. Each matching log entry increments the associated metric, providing the exact segmented count metrics required per API operation, response code, and application version with minimal overhead. B. Incorrect. CloudWatch Logs Insights is designed for ad-hoc, interactive log analysis and querying, not for continuous, automated population of persistent CloudWatch metrics. There is no native capability to configure Logs Insights to automatically generate and update dimensioned metrics from incoming log streams, so this option cannot meet the requirement for ongoing metric collection. C. Incorrect. This option introduces unnecessary complexity and redundant steps. The Lambda function already holds all required data points, so there is no need to pass custom metadata back to the ALB for logging. ALB access logs are also not designed to capture custom Lambda response metadata, and this approach adds unneeded latency and configuration overhead compared to direct logging from Lambda. D. Incorrect. While X-Ray supports custom subsegments for trace data, X-Ray Insights is focused on anomaly detection and distributed request tracing, not on generating aggregated, dimensioned count metrics for CloudWatch. This approach is significantly more complex than using metric filters, and X-Ray does not natively support the automated publication of the required segmented metrics, making it a poor fit for the use case. Key Concepts: 1. CloudWatch Logs Metric Filters: These are native CloudWatch features that parse log event data to extract numerical values and generate custom CloudWatch metrics. They support dimension assignment for metric segmentation, making them ideal for generating metrics from structured application log data as required in this scenario. 2. CloudWatch Metric Dimensions: Dimensions are key-value pairs that allow users to categorize, filter, and aggregate CloudWatch metrics. For this use case, dimensions enable the required segmentation of API metrics by operation name, response code, and application version. 3. CloudWatch Logs Insights Use Cases: Logs Insights is intended for interactive, on-demand log analysis and troubleshooting, not for continuous, automated custom metric generation. This distinction is critical to selecting the right tool for the requirement. References: Search and filter log data using metric filters, https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html Amazon CloudWatch Concepts - Dimensions, https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension
DOP-C02 · Q2
Topic 1 Question #2 A company provides an application to customers. The application has an Amazon API Gateway REST API that invokes an AWS Lambda function. On initialization, the Lambda function loads a large amount of data from an Amazon DynamoDB table. The data load process results in long cold-start times of 8-10 seconds. The DynamoDB table has DynamoDB Accelerator (DAX) configured.Customers report that the application intermittently takes a long time to respond to requests. The application receives thousands of requests throughout the day. In the middle of the day, the application experiences 10 times more requests than at any other time of the day. Near the end of the day, the application's request volume decreases to 10% of its normal total.A DevOps engineer needs to reduce the latency of the Lambda function at all times of the day.Which solution will meet these requirements?
  • A.
    Configure provisioned concurrency on the Lambda function with a concurrency value of 1. Delete the DAX cluster for the DynamoDB table.
  • B.
    Configure reserved concurrency on the Lambda function with a concurrency value of 0.
  • C.
    Configure provisioned concurrency on the Lambda function. Configure AWS Application Auto Scaling on the Lambda function with provisioned concurrency values set to a minimum of 1 and a maximum of 100.
  • D.
    Configure reserved concurrency on the Lambda function. Configure AWS Application Auto Scaling on the API Gateway API with a reserved concurrency maximum value of 100.

Answer: C

The core requirement is eliminating Lambda cold start latency while adapting to highly variable traffic patterns, which aligns with the DOP-C02 performance optimization domain for serverless workloads. The long cold starts occur because the Lambda function runs an expensive data load from DynamoDB during initialization for each new execution environment. Provisioned concurrency directly addresses this by pre-initializing Lambda execution environments, so the data load completes before any customer requests are processed. Application Auto Scaling for provisioned concurrency adjusts the number of pre-warmed instances to match traffic levels: the minimum of 1 ensures at least one warm instance is always available for low traffic periods at the end of the day, while the maximum of 100 accommodates the 10x midday peak load without overprovisioning and incurring unnecessary costs during low volume periods. This solution also preserves the existing DAX configuration which already optimizes DynamoDB read latency. Option Analysis: A. Incorrect. A provisioned concurrency value of 1 is insufficient to handle the 10x midday peak load, so most customer requests will still be routed to on-demand instances that experience long cold starts. Additionally, deleting the DAX cluster removes the existing DynamoDB read latency optimization, which will increase overall application latency even for warm Lambda instances, making performance worse. B. Incorrect. A reserved concurrency value of 0 sets the maximum number of concurrent execution instances for the Lambda function to zero, which blocks all invocations of the function entirely. This will break the application completely, and reserved concurrency does not address cold start latency at all. C. Correct. Provisioned concurrency pre-warms Lambda execution environments, completing the data load from DynamoDB during initialization before any customer requests are processed, eliminating the 8-10 second cold start latency. Configuring Application Auto Scaling for the provisioned concurrency with a minimum of 1 and maximum of 100 aligns the number of pre-warmed instances with the variable traffic patterns: the minimum ensures low latency even during off-peak periods at the end of the day, while the maximum accommodates the 10x midday peak load, balancing performance and cost efficiency. D. Incorrect. Reserved concurrency only sets a limit on the maximum number of concurrent instances for the Lambda function, it does not pre-warm instances so it does nothing to reduce cold start latency. Additionally, Application Auto Scaling for reserved concurrency is configured for Lambda functions, not API Gateway, so this configuration is invalid. Key Concepts: 1. Lambda Provisioned Concurrency: This feature pre-initializes Lambda execution environments, so all initialization code including data loads from external resources like DynamoDB runs before requests are received, eliminating cold start latency for latency-sensitive serverless workloads. 2. Provisioned Concurrency Auto Scaling: Application Auto Scaling can dynamically adjust the number of provisioned concurrency instances for a Lambda function based on traffic metrics, scheduled actions, or custom alarms, allowing teams to match pre-warmed capacity to variable workload demand while controlling costs. 3. Reserved vs. Provisioned Concurrency: Reserved concurrency allocates a fixed maximum number of account-wide concurrent execution slots to a Lambda function to prevent throttling from other workloads, while provisioned concurrency pre-warms instances to reduce cold start latency, serving distinct operational purposes. References: Configuring Lambda function concurrency, https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html Managing provisioned concurrency auto scaling, https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html#configuration-provisioned-concurrency-autoscaling
DOP-C02 · Q3
Topic 1 Question #3 A company is adopting AWS CodeDeploy to automate its application deployments for a Java-Apache Tomcat application with an Apache Webserver. The development team started with a proof of concept, created a deployment group for a developer environment, and performed functional tests within the application. After completion, the team will create additional deployment groups for staging and production.The current log level is configured within the Apache settings, but the team wants to change this configuration dynamically when the deployment occurs, so that they can set different log level configurations depending on the deployment group without having a different application revision for each group.How can these requirements be met with the LEAST management overhead and without requiring different script versions for each deployment group?
  • A.
    Tag the Amazon EC2 instances depending on the deployment group. Then place a script into the application revision that calls the metadata service and the EC2 API to identify which deployment group the instance is part of. Use this information to configure the log level settings. Reference the script as part of the AfterInstall lifecycle hook in the appspec.yml file.
  • B.
    Create a script that uses the CodeDeploy environment variable DEPLOYMENT_GROUP_ NAME to identify which deployment group the instance is part of. Use this information to configure the log level settings. Reference this script as part of the BeforeInstall lifecycle hook in the appspec.yml file.
  • C.
    Create a CodeDeploy custom environment variable for each environment. Then place a script into the application revision that checks this environment variable to identify which deployment group the instance is part of. Use this information to configure the log level settings. Reference this script as part of the ValidateService lifecycle hook in the appspec.yml file.
  • D.
    Create a script that uses the CodeDeploy environment variable DEPLOYMENT_GROUP_ID to identify which deployment group the instance is part of to configure the log level settings. Reference this script as part of the Install lifecycle hook in the appspec.yml file.

Answer: B

This scenario requires environment-specific Apache log level configuration during CodeDeploy deployments with minimal management overhead, no separate application revisions, and no per-deployment-group script versions. The optimal solution leverages native CodeDeploy functionality to avoid custom configuration, additional IAM permissions, or external API calls. The suggested answer B uses the predefined DEPLOYMENT_GROUP_NAME environment variable that CodeDeploy automatically injects into all lifecycle hook script execution environments, eliminating the need for custom variable configuration or external context lookups. Running the configuration script in the BeforeInstall lifecycle hook ensures the log level setting is applied before the application is installed and started, so the Apache service uses the correct log level immediately upon launch with no extra restarts required. This approach meets all requirements with the least management overhead, as no additional resources, permissions, or per-group configuration are needed beyond the single universal script referenced in the appspec.yml that works across all deployment groups. Option Analysis: A. Incorrect. Tagging EC2 instances per deployment group and calling the EC2 metadata service and EC2 API adds unnecessary management overhead, including maintaining instance tag consistency, adding IAM permissions for instances to call EC2 APIs, and risk of error if instances are reused across deployment groups. This approach is far less efficient than using native CodeDeploy environment variables. B. Correct. CodeDeploy natively provides the DEPLOYMENT_GROUP_NAME predefined environment variable to all lifecycle hook scripts with no extra configuration required. Using this human-readable variable to select the appropriate log level requires no custom setup, no separate script versions, and no additional API calls. The BeforeInstall lifecycle hook is appropriate for this configuration change, as it runs before the application is installed or started, ensuring the log level is applied before the Apache service launches. C. Incorrect. Creating custom CodeDeploy environment variables for each deployment group adds unnecessary management overhead compared to using the native, out-of-the-box DEPLOYMENT_GROUP_NAME variable. Additionally, the ValidateService lifecycle hook runs after the application has already started, so modifying log level at this stage would require a restart of Apache, introducing extra steps and potential downtime, making this approach inefficient and high risk. D. Incorrect. While DEPLOYMENT_GROUP_ID is a valid predefined CodeDeploy variable, it is an opaque alphanumeric identifier, not a human-readable name, so mapping IDs to log levels requires extra maintenance whenever deployment groups are added, removed, or modified, increasing management overhead. Additionally, the Install lifecycle hook runs while the application revision is being unpacked and copied to its target location, so modifying configuration during this phase can lead to conflicts with the deployment process itself, making this an inappropriate hook for configuration changes. Key Concepts: 1. CodeDeploy Predefined Environment Variables: CodeDeploy automatically injects a set of standard environment variables during all lifecycle hook executions, including DEPLOYMENT_GROUP_NAME, DEPLOYMENT_GROUP_ID, and APPLICATION_NAME, which eliminate the need for custom logic or external API calls to identify deployment context. 2. CodeDeploy Lifecycle Hook Order: The sequence of CodeDeploy lifecycle hooks (ApplicationStop, DownloadBundle, BeforeInstall, Install, AfterInstall, ApplicationStart, ValidateService) dictates the appropriate timing for configuration changes to avoid conflicts, ensure settings are applied before application startup, and prevent unneeded service restarts. 3. Multi-Environment Deployment Best Practices: Deployment groups are designed to support environment-specific configurations without requiring separate application revisions, leveraging native CodeDeploy features to minimize management overhead for dev, staging, and production deployment pipelines. References: CodeDeploy AppSpec File Structure - Hooks, https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html CodeDeploy Predefined Environment Variables, https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure-environment-variables.html
DOP-C02 · Q4
Topic 1 Question #4 A company requires its developers to tag all Amazon Elastic Block Store (Amazon EBS) volumes in an account to indicate a desired backup frequency. This requirement Includes EBS volumes that do not require backups. The company uses custom tags named Backup_Frequency that have values of none, dally, or weekly that correspond to the desired backup frequency. An audit finds that developers are occasionally not tagging the EBS volumes.A DevOps engineer needs to ensure that all EBS volumes always have the Backup_Frequency tag so that the company can perform backups at least weekly unless a different value is specified.Which solution will meet these requirements?
  • A.
    Set up AWS Config in the account. Create a custom rule that returns a compliance failure for all Amazon EC2 resources that do not have a Backup Frequency tag applied. Configure a remediation action that uses a custom AWS Systems Manager Automation runbook to apply the Backup_Frequency tag with a value of weekly.
  • B.
    Set up AWS Config in the account. Use a managed rule that returns a compliance failure for EC2::Volume resources that do not have a Backup Frequency tag applied. Configure a remediation action that uses a custom AWS Systems Manager Automation runbook to apply the Backup_Frequency tag with a value of weekly.
  • C.
    Turn on AWS CloudTrail in the account. Create an Amazon EventBridge rule that reacts to EBS CreateVolume events. Configure a custom AWS Systems Manager Automation runbook to apply the Backup_Frequency tag with a value of weekly. Specify the runbook as the target of the rule.
  • D.
    Turn on AWS CloudTrail in the account. Create an Amazon EventBridge rule that reacts to EBS CreateVolume events or EBS ModifyVolume events. Configure a custom AWS Systems Manager Automation runbook to apply the Backup_Frequency tag with a value of weekly. Specify the runbook as the target of the rule.

Answer: B

The scenario requires continuous enforcement of the Backup_Frequency tag on all EBS volumes, with a default value of weekly if no tag is specified, including both new and pre-existing untagged volumes. The correct solution leverages AWS Config, which is purpose-built for ongoing configuration compliance monitoring across all resources in an account. The managed required-tags rule is scoped exclusively to EC2::Volume (EBS volume) resources to avoid impacting out-of-scope EC2 resources. The automated remediation action uses a custom Systems Manager Automation runbook to apply the default weekly tag to non-compliant untagged volumes, eliminating manual effort and ensuring consistent enforcement for all EBS volumes regardless of their creation date, fully meeting the stated requirements. Option Analysis: A. Incorrect. This option specifies the AWS Config rule applies to all Amazon EC2 resources, rather than only EBS volumes (EC2::Volume resource type). The requirement only mandates the Backup_Frequency tag for EBS volumes, so this solution would incorrectly apply the tag to unrelated EC2 resources such as instances, elastic network interfaces, or snapshots that are out of scope for the requirement. B. Correct. This solution uses the AWS Config managed required-tags rule scoped specifically to EC2::Volume (EBS volume) resources, ensuring only the intended resources are evaluated. AWS Config continuously monitors both new and existing volumes for compliance, so previously created untagged volumes identified during the audit are also addressed. The automated remediation action applies the default weekly tag to non-compliant volumes, ensuring all EBS volumes always have the required tag as specified. C. Incorrect. This event-driven solution only triggers when an EBS CreateVolume event occurs, meaning it only applies the tag to new volumes at creation. It does not address existing untagged EBS volumes that were created before the EventBridge rule was deployed, which fails the requirement that all EBS volumes always have the Backup_Frequency tag. D. Incorrect. While this solution adds ModifyVolume events as a trigger, it still only acts on volumes when they are created or modified. Existing untagged volumes that are not modified after the rule is deployed will remain untagged, violating the requirement for 100% tag coverage across all EBS volumes. ModifyVolume events are also irrelevant to addressing untagged volumes that are not being actively modified. Key Concepts: 1. AWS Config Continuous Compliance: AWS Config provides ongoing assessment of resource configurations against compliance rules, covering both newly created and pre-existing resources, making it the appropriate tool for organization-wide tag enforcement requirements that apply to all resources in an account. 2. AWS Config Automated Remediation: AWS Config supports automatic remediation of non-compliant resources using pre-built or custom Systems Manager Automation runbooks, reducing manual overhead and ensuring rapid, consistent resolution of compliance gaps. 3. Tag Enforcement Scope: Correctly scoping tag enforcement rules to only the required resource type prevents unintended changes to unrelated resources, aligns with least-privilege best practices, and ensures compliance requirements are met efficiently. References: AWS Config Managed Rule: required-tags, https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html AWS Config Automated Remediation, https://docs.aws.amazon.com/config/latest/developerguide/remediation-actions.html
DOP-C02 · Q5
Topic 1 Question #5 A company is using an Amazon Aurora cluster as the data store for its application. The Aurora cluster is configured with a single DB instance. The application performs read and write operations on the database by using the cluster's instance endpoint.The company has scheduled an update to be applied to the cluster during an upcoming maintenance window. The cluster must remain available with the least possible interruption during the maintenance window.What should a DevOps engineer do to meet these requirements?
  • A.
    Add a reader instance to the Aurora cluster. Update the application to use the Aurora cluster endpoint for write operations. Update the Aurora cluster's reader endpoint for reads.
  • B.
    Add a reader instance to the Aurora cluster. Create a custom ANY endpoint for the cluster. Update the application to use the Aurora cluster's custom ANY endpoint for read and write operations.
  • C.
    Turn on the Multi-AZ option on the Aurora cluster. Update the application to use the Aurora cluster endpoint for write operations. Update the Aurora cluster’s reader endpoint for reads.
  • D.
    Turn on the Multi-AZ option on the Aurora cluster. Create a custom ANY endpoint for the cluster. Update the application to use the Aurora cluster's custom ANY endpoint for read and write operations

Answer: A

The scenario involves a single-instance Amazon Aurora cluster that requires minimal interruption during scheduled maintenance. A single-instance Aurora cluster experiences downtime when maintenance is applied to the only instance, as there is no available failover target. The correct solution adds redundancy to the cluster, uses native Aurora endpoints to automatically route traffic appropriately during failover, and eliminates single points of failure during maintenance. This approach aligns with DevOps best practices for managed database high availability and minimal downtime for scheduled updates, directly addressing the requirement for least possible interruption. Option Analysis: A. Correct. Adding a reader instance provides a redundant failover target for the writer. When maintenance is applied to the original writer instance, Aurora automatically fails over to the reader instance, which becomes the new writer. The cluster endpoint always resolves to the current active writer, so write operations continue seamlessly after failover. The reader endpoint automatically distributes read traffic across all healthy reader instances, so read operations remain available even if one instance is undergoing maintenance. This configuration requires minimal application changes and eliminates unplanned downtime during the maintenance window. B. Incorrect. A custom ANY endpoint routes traffic to all instances in the cluster, including both writer and reader instances, and is designed exclusively for read workloads that benefit from distribution across all cluster instances. Sending write operations to an ANY endpoint will result in frequent write failures, as only the active writer instance can accept write requests. This configuration does not support uninterrupted read and write operations. C. Incorrect. Aurora does not have a standalone "Multi-AZ option" to toggle like standard RDS instances. Aurora inherently replicates data across 3 Availability Zones by default, and Multi-AZ high availability for Aurora is achieved by adding reader instances (preferably in separate AZs) to act as failover targets. The step to "turn on the Multi-AZ option" describes a non-existent configuration action for Aurora clusters, making this option invalid. D. Incorrect. First, the "turn on the Multi-AZ option" step is not a valid configuration action for Aurora, as explained for option C. Second, using a custom ANY endpoint for both read and write operations will cause write failures, as the ANY endpoint can route traffic to reader instances that do not support write operations. This configuration cannot support uninterrupted application operations. Key Concepts: 1. Aurora Maintenance Behavior: For multi-instance Aurora clusters, AWS applies maintenance updates in a rolling fashion: updates are first applied to reader instances, then a failover is performed to a patched reader instance, before the original writer is updated. This process results in near-zero downtime for clusters with at least one additional reader instance. 2. Aurora Endpoint Types: The cluster endpoint is a static endpoint that always resolves to the current active writer instance, enabling seamless write traffic routing during failover events. The reader endpoint load balances read traffic across all healthy reader instances in the cluster, ensuring read availability even if individual instances are unavailable. 3. Aurora High Availability Configuration: Unlike standard RDS, Aurora does not use a separate, passive standby for Multi-AZ deployments. High availability for failover is achieved by adding reader instances that act as active failover targets for the writer, with automatic failover completing in typically under 30 seconds. References: Maintaining an Amazon Aurora DB cluster, https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html Aurora endpoints, https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html

FAQ

How many practice questions are available for DOP-C02?

This question bank includes 429 DOP-C02 practice questions covering single and multiple choice, each with answers and explanations.

Are DOP-C02 practice questions available in Chinese and English?

Yes, DOP-C02 practice questions are provided in both Chinese and English.

Can I try DOP-C02 practice questions for free?

Yes. Free sample questions are available on this page, and the full question bank is available after signing up on Zhangxuetu.

Try practice questions Get the question bank

Related exams