AWS DevOps Engineer Professional common mistakes
AWS DevOps Engineer Professional · Understand the traps and how to avoid them.
When asked to make a CodeDeploy deployment to EC2/on-premises instances safe, the candidate configures the deployment group's rollback settings and calls it done, without verifying that the instances have the CodeDeploy agent installed and running and that the service role trusts ec2.amazonaws.com.
Rollback configuration is the most visible knob in the console, so it becomes the default answer. The agent and IAM trust relationship are prerequisites that fail silently at deployment time, and candidates rarely have had to debug a failed agent registration.
What to do instead
For EC2/on-premises deployments, list the prerequisites explicitly: CodeDeploy agent installed and running on each instance, instances tagged and matched by the deployment group's tag/ASG filter, and a service role with the CodeDeploy trust policy plus the managed policy. For ECS/Lambda, replace the agent check with the target group/container port and the Lambda alias/version wiring.
The candidate treats a CodePipeline stage as able to run actions in parallel by default, or expects a manual approval to gate only one action, when approvals and run order in a stage are governed by runOrder and the stage-level gate semantics.
Pipeline stages look like simple sequential lists in the console; runOrder and the fact that a manual approval blocks the whole stage are not obvious until you have built a multi-action stage.
What to do instead
Memorize the stage model: actions in a stage run in parallel unless runOrder groups them, and a manual approval action halts the entire stage until approved. When a question asks for parallel test suites or a gate before deploy, answer with runOrder grouping and an approval action placed in the correct stage, not with separate pipelines.
For a CloudFormation question about updating a stack that must not interrupt traffic, the candidate picks the default UpdateStack behavior or recommends deleting and recreating the stack, instead of selecting a change set plus the appropriate stack policy or update type.
Candidates conflate 'apply the template' with 'update safely' and forget that change sets preview impact while stack policies and UpdateReplacePolicy/DeletionPolicy control what happens to replaced resources.
What to do instead
Separate the concepts: change sets preview but do not protect; stack policies deny updates to specified resources; UpdateReplacePolicy and DeletionPolicy govern retention of replaced/deleted resources. For zero-downtime updates, answer with the service's own mechanism (e.g., ASG rolling update, ECS deployment configuration, RDS blue/green) and use change sets to review before executing.
The candidate hand-writes a CloudFormation template for a multi-account, multi-Region rollout when the question is really testing StackSets, or conversely proposes StackSets for a single-account single-stack change.
StackSets is a distinctive service name that candidates latch onto whenever 'multiple accounts' appears, without checking whether the requirement is drift remediation, delegated administration, or a one-off stack update.
What to do instead
Map the requirement first: multiple accounts/Regions with centralized administration means StackSets with the right administrator account and target OU/account filters; a single stack change means UpdateStack with a change set. If drift must be corrected across accounts, name StackSets drift detection and remediation rather than manual re-deploys.
When asked to design a highly available multi-tier application, the candidate places resources in multiple Availability Zones but leaves a single NAT gateway, a single-AZ RDS instance, or a stateful component pinned to one AZ, then declares the design resilient.
AZ redundancy is easy to claim at the subnet level and candidates stop there, forgetting that managed services have their own Multi-AZ settings and that NAT gateways are zonal.
What to do instead
Audit every component for zonal single points: one NAT gateway per AZ with route tables per subnet, RDS Multi-AZ (or Aurora with multiple instances across AZs), ALB across at least two AZs, and stateless tiers behind the load balancer. State the failure being survived (AZ loss) and show each tier has capacity in the remaining AZ.
The candidate answers a resilience question with 'enable backups' or 'take snapshots' when the scenario requires a defined RTO/RPO and a tested recovery procedure, and does not distinguish backup/restore from pilot light, warm standby, or multi-site.
Backups are the most familiar safety net, and candidates do not practice mapping RTO/RPO numbers to the four disaster recovery strategies.
What to do instead
Learn the DR ladder by cost and recovery time: backup and restore (highest RTO), pilot light, warm standby, multi-site active/active (lowest RTO). Read the RTO/RPO in the prompt, pick the cheapest strategy that meets it, and include the failover mechanism (Route 53 health checks/failover routing, cross-Region replication) rather than just snapshots.
The candidate configures CloudWatch alarms but omits the action wiring, or relies on default metrics for something that needs a custom metric or metric filter, so the alarm never fires in the scenario described.
Alarms are usually taught as threshold plus notification; the gap between 'metric exists' and 'metric is emitted with the right dimensions and has an action' is where real incidents are missed.
What to do instead
For every alarm, state the metric source (default vs. custom vs. Logs metric filter), the statistic/period that matches the failure, and the action (SNS topic, Auto Scaling policy, Systems Manager automation). If the signal lives in logs, build a metric filter and alarm on it; if it lives in the app, publish a custom metric with consistent dimensions.
The candidate proposes CloudTrail for application error monitoring or CloudWatch Logs for API audit history, swapping the two services' purposes when the question asks where to find a specific event.
Both are 'logging' services and the distinction between control-plane API auditing and application/runtime logs blurs under time pressure.
What to do instead
Anchor the split: CloudTrail records AWS API/control-plane activity (who called what, when) and is the answer for audit trails and security investigations; CloudWatch Logs holds application, system, and service logs and is the answer for troubleshooting runtime errors and building metric filters. X-Ray is for tracing request paths across services, not for either of the above.
When a question describes a suspicious finding or a compromised instance, the candidate jumps to terminating the instance or rotating keys without preserving evidence or following the event-driven response pattern the question asks for.
The instinct is to remediate fast, and candidates do not rehearse the containment-then-investigate sequence that incident response questions reward.
What to do instead
Order the response: detect (GuardDuty/Security Hub/EventBridge), contain (isolate via security group or move to a quarantine subnet, snapshot for forensics), investigate (CloudTrail, VPC Flow Logs, logs), then remediate and rotate credentials. Use EventBridge rules to trigger Systems Manager Automation or Lambda for the automated containment step the prompt describes.
The candidate answers a cross-account access question by creating an IAM user with keys in the target account, or by widening a resource policy to '*', instead of using a role with a trust policy and sts:AssumeRole.
Long-lived access keys are the simplest mental model, and the trust-policy-plus-assume-role pattern requires holding two policies in mind at once.
What to do instead
For cross-account access, define the role in the trusting account with a trust policy naming the trusted account/principal, grant sts:AssumeRole to the caller, and have the caller assume the role (with ExternalId where a third party is involved). Never solve least-privilege or cross-account questions with long-lived keys or wildcard principals.