7 AWS DevOps Engineer Professional Questions Most Candidates Get Wrong
Here are 7 multiple-choice questions designed to mirror the difficulty, style, and domain coverage of the AWS DevOps Engineer Professional (DOP-C02) exam. These questions focus on practical application, troubleshooting, and architectural decision-making.
Welcome to this practice quiz. Each question presents a realistic scenario that a DevOps engineer might encounter. Analyze the requirements carefully, consider the trade-offs of each option, and select the most operationally efficient and cost-effective solution. Good luck! Another useful resource: AWS DevOps Engineer Professional Difficulty: What Actually Makes People Fail.
Before you begin, a free AWS Certified DevOps Engineer - Professional study plan gives you a week-by-week schedule to fit your available study time.
Question 1
A company is deploying a new microservices application on Amazon ECS. The application experiences unpredictable traffic spikes. The DevOps team must ensure that the ECS service can scale out quickly to handle the load, but they are concerned about the time it takes for new tasks to become healthy. The current setup uses a standard Application Load Balancer (ALB) target group with a health check grace period of 30 seconds. What is the MOST effective way to reduce the time it takes for a new task to begin receiving traffic?
A. Switch the ALB target group health check to use HTTP with a faster interval and a lower unhealthy threshold.
B. Configure the ECS service to use a target tracking scaling policy based on the ALB's RequestCountPerTarget metric.
C. Enable managed scaling for the ECS service and configure the target group's connection draining to a minimum value.
D. Set the ECS service's health check grace period to 0 and configure the container's STOPSIGNAL to be sent immediately upon startup.
Answer: A
Explanation: The health check grace period delays the deregistration of a task if it fails health checks, but the primary delay is the time for the ALB to successfully perform health checks against the new task. By configuring the target group health check to be more aggressive (faster interval, lower unhealthy threshold), the ALB will mark the new task as healthy sooner, allowing it to receive traffic. Option B helps with scaling policy but doesn't speed up the initial registration process. Option C's connection draining affects how long existing connections are maintained during scale-in, not scale-out speed. Option D is incorrect because the grace period is a safety mechanism to prevent the service from killing a task that is still starting up, and setting it to 0 could cause tasks to be killed before they are ready.
Question 2
A DevOps engineer is migrating a legacy monolithic application to AWS. The application is stateful and stores session data locally on the instance. The team plans to use an Auto Scaling group with a custom AMI. To ensure high availability and fault tolerance, what is the MOST robust and operationally efficient solution for handling session state?
A. Create a new AMI from a running instance after the session data is flushed to disk, and use this AMI for the Auto Scaling group.
B. Modify the application to store session data in an Amazon ElastiCache for Redis cluster and configure the Auto Scaling group to use a lifecycle hook to warm the cache.
C. Modify the application to store session data in a shared Amazon EFS file system mounted to all instances in the Auto Scaling group.
D. Modify the application to store session data in an Amazon S3 bucket, using the session ID as the object key.
Answer: C
Explanation: Storing session data on a shared EFS file system is a classic pattern for making stateful applications stateless at the instance level. It provides a highly available, shared, and POSIX-compliant file system that all instances can mount. Option A is incorrect because baking session data into an AMI is not scalable or fault-tolerant. Option B (ElastiCache) is a good solution, but it requires significant application modification and introduces a new operational burden for cache warming, making EFS more operationally efficient for a simple file-based session store. Option D (S3) is not ideal for high-frequency read/write session data due to latency and consistency considerations.
Question 3
An application running on AWS Lambda processes messages from an Amazon SQS queue. The processing time for each message is variable, ranging from 5 seconds to 5 minutes. The team is seeing a high number of Lambda service exceptions and Throttles in CloudWatch. The Lambda function's reserved concurrency is set to 100, and the SQS queue is configured with a visibility timeout of 30 seconds. Which combination of changes will resolve the throttling issue and prevent messages from being processed multiple times? (Choose two.)
A. Increase the SQS queue's visibility timeout to 6 minutes.
B. Increase the Lambda function's reserved concurrency to 1000. If this interests you, 10 Google Professional ML Engineer Questions Most Candidates Get Wrong goes into more detail.
C. Configure the SQS queue to use a dead-letter queue (DLQ) for messages that fail to process.
D. Implement a CloudWatch alarm on the ApproximateNumberOfMessagesVisible metric to trigger a manual intervention.
E. Set the Lambda function's MaximumBatchingWindowInSeconds to 0 and its BatchingWindow to 0.
Answer: A, B
Explanation: Throttling occurs when the Lambda function's concurrency limit (100) is reached. Increasing the reserved concurrency to 1000 (option B) removes this bottleneck. Since the function's execution time can be up to 5 minutes, the SQS visibility timeout of 30 seconds is too short. If a message is being processed and the visibility timeout expires, the message becomes visible again in the queue and is processed by another invocation, leading to duplicate processing. Increasing the visibility timeout to 6 minutes (option A) ensures the message is not redelivered while the first invocation is still processing. Option C (DLQ) is for handling failed messages, not throttling. Option D is a manual, non-scalable solution. Option E is incorrect because it doesn't address the root cause of throttling or the visibility timeout issue.
Question 4
A company is using AWS CodePipeline to deploy a web application. The pipeline has a build stage and a deploy stage. The DevOps team needs to implement a manual approval step that can only be performed by senior engineers from the "Release-Managers" IAM group. The approval action must also send a notification to an Amazon SNS topic. Which configuration should be used in the pipeline's stage definition?
A. Add an action with Category: Approval, ActionMode: Single, and specify the Configuration with NotificationArn and CustomData. Use a separate IAM policy to restrict who can approve.
B. Add an action with Category: Build, ActionMode: Approval, and specify the Configuration with TopicArn and ExternalEntityLink. Use a resource-based policy on the pipeline to restrict access.
C. Add an action with Category: Approval, ActionMode: Single, and specify the Configuration with SNSTopicArn and Message. Use an IAM policy attached to the pipeline's service role to restrict access.
D. Add an action with Category: Test, ActionMode: Approval, and specify the Configuration with NotificationArn and Comments. Use an S3 bucket policy to restrict access to the pipeline artifact.
Answer: A
Explanation: In CodePipeline, a manual approval action is defined with Category: Approval and ActionMode: Single. The configuration for this action includes the NotificationArn (the SNS topic to send notification) and CustomData (optional information for the approver). Access control for who can approve is managed through IAM policies that grant codepipeline:PutApprovalResult permission, typically restricted to the "Release-Managers" group. Options B, C, and D use incorrect category or action mode values and incorrect configuration keys.
Question 5
A DevOps engineer is managing a CloudFormation stack that creates an Amazon RDS database. The stack was successfully created, but the database's master password is stored in plaintext in the template. The team wants to migrate to using AWS Secrets Manager to store the password. What is the MOST secure and operationally efficient way to update the stack to use Secrets Manager without causing downtime?
A. Use CloudFormation's AWS::SecretsManager::Secret resource to create a new secret and update the MasterPassword property of the RDS instance to reference the secret's SecretString value. Do this in the same stack update.
B. Create the secret in Secrets Manager manually. Then, update the RDS instance's password to match the secret value using the AWS CLI. Finally, update the CloudFormation template to reference the secret.
C. Use CloudFormation's AWS::SecretsManager::Secret resource and the AWS::RDS::DBInstance resource, and use the MasterUsername and MasterUserPassword properties with a Fn::Sub intrinsic function to reference the secret.
D. Delete the existing RDS instance and recreate it in a new CloudFormation stack that uses AWS::SecretsManager::Secret for the password. Use a snapshot to restore the data. Looking for more detail? See Choosing Between AWS DevOps Engineer Professional and AZ-400: The Deciding Factors.
Answer: C
Explanation: In modern CloudFormation, the AWS::RDS::DBInstance resource supports MasterUsername and MasterUserPassword properties that can reference a secret. However, the most efficient and secure method is to use the AWS::SecretsManager::Secret resource to generate and manage the password, and then use CloudFormation's dynamic reference feature (e.g., {{resolve:secretsmanager:secret-id:SecretString:password}}) to pass the password to the RDS instance. This is done in a single stack update, which CloudFormation handles seamlessly, minimizing downtime. Option A is incorrect because you cannot directly reference the SecretString value in a property without using dynamic references. Option B involves manual steps and is not operationally efficient. Option D causes downtime.
Question 6
A company has a multi-account AWS environment managed by AWS Organizations. The DevOps team is implementing a centralised CI/CD strategy where a pipeline in the "SharedServices" account deploys applications to "Dev", "Test", and "Prod" accounts. The pipeline uses an Amazon S3 artifact bucket in the SharedServices account. What is the MOST secure way to allow the pipeline to deploy to the target accounts?
A. Create an IAM role in each target account with permissions to deploy. Configure the pipeline's deploy actions to use the AWSCloudFormation action with a RoleArn parameter that can assume the target account role.
B. Create an IAM user in each target account, create access keys, and store them as plaintext variables in the pipeline's environment variables.
C. Create a single IAM role in the SharedServices account with cross-account permissions to all target accounts. Use this role for all deploy actions.
D. Create an IAM policy in each target account that grants the SharedServices account's pipeline service role permission to deploy. Configure the deploy action to use the CodeDeploy action with the target account's alias.
Answer: A
Explanation: The standard pattern for cross-account deployments is to use IAM roles. The pipeline (in SharedServices) assumes a role in the target account (e.g., "Dev") that has the necessary permissions to deploy. In CodePipeline, this is configured by specifying the RoleArn in the deployment action (e.g., AWSCloudFormation or CodeDeploy). This avoids long-lived credentials. Option B is insecure. Option C is incorrect because a role in the SharedServices account cannot directly have permissions in another account; it must assume a role in the target account. Option D is not a standard or supported configuration for CodePipeline actions.
Question 7
An application running on Amazon EKS uses an AWS Load Balancer Controller to provision an Application Load Balancer (ALB) for an Ingress resource. The DevOps team notices that the ALB's security group is not being updated automatically when the Ingress resource is updated to allow traffic from a new CIDR block. The Ingress is configured with an ip block in an ipBlock section. What is the MOST likely cause of this issue?
A. The AWS Load Balancer Controller does not support automatic security group updates for Ingress resources.
B. The IAM role used by the AWS Load Balancer Controller does not have the ec2:AuthorizeSecurityGroupIngress permission.
C. The Ingress resource is missing the alb.ingress.kubernetes.io/security-groups annotation.
D. The security group is managed by CloudFormation and cannot be modified by the Load Balancer Controller.
Answer: B
Explanation: The AWS Load Balancer Controller is responsible for managing the security group rules for the ALB it provisions. To do this, it requires specific IAM permissions, including ec2:AuthorizeSecurityGroupIngress, ec2:RevokeSecurityGroupIngress, and ec2:DescribeSecurityGroups. If these permissions are missing from the controller's IAM role, it will fail to update the security group rules when the Ingress spec changes. The controller does support automatic updates (option A is false). Option C's annotation is used to specify a custom security group, but it's not required for the default managed security group. Option D is unlikely; the controller can modify security groups even if they were created by CloudFormation, assuming the IAM permissions are correct.
Approach exam day with proof that you are ready — AWS Certified DevOps Engineer - Professional exam questions provide that proof.
Before exam day, a free AWS Certified DevOps Engineer - Professional readiness check can quickly reveal the topic you need to review most.