ACE-Professional common mistakes
ACE-Professional · Understand the traps and how to avoid them.
Treating a managed service's default settings as production-ready without checking whether they meet the workload's durability, availability, or performance requirements.
Candidates assume that because a service is managed, its defaults are always appropriate, and they skip comparing default behavior against the stated non-functional requirements.
What to do instead
For every scenario, explicitly map the requirement (RPO/RTO, throughput, HA) to the service's configurable options and verify that the chosen settings satisfy it rather than relying on defaults.
Selecting a compute option based on familiarity rather than matching workload characteristics (burst vs steady, stateful vs stateless, latency sensitivity) to the service's execution model.
Candidates default to the service they know best and overlook constraints such as cold-start latency, maximum execution duration, or lack of persistent local storage.
What to do instead
Before choosing, list the workload's key traits (duration, concurrency, state, scaling pattern) and eliminate compute options whose documented limits contradict any trait.
Choosing a storage class or data service without accounting for access frequency, retrieval cost, and minimum storage duration.
Candidates focus on the headline storage price and ignore retrieval fees, early-deletion charges, or latency differences that dominate total cost for the actual access pattern.
What to do instead
Estimate total cost and latency for the described access pattern (read/write frequency, object size, retention period) across candidate storage classes before selecting.
Designing network connectivity without verifying route propagation, overlapping CIDR ranges, and the direction of security controls between the connected networks.
Candidates treat connectivity as a single configuration step and forget that overlapping address spaces or asymmetric security rules silently break communication.
What to do instead
For any hybrid or multi-network design, check for CIDR overlap first, then trace the route path and confirm that security rules exist in both directions for the required traffic.
Conflating authentication, authorization, and encryption controls when answering a security requirement, applying one where another is needed.
Candidates see a security keyword and reach for the most familiar control (e.g., a policy) without identifying whether the requirement is about proving identity, granting access, or protecting data.
What to do instead
Classify the requirement first: who is allowed (authorization), how identity is proven (authentication), or how data is protected (encryption), then select the control that addresses that category.
Assuming a permission granted at one scope automatically applies at a narrower or broader scope without checking inheritance and explicit-deny behavior.
Candidates memorize that permissions flow down a hierarchy but forget that explicit denies override allows and that some services require permissions at a specific resource scope.
What to do instead
For each identity question, trace the effective permission from the scope where it is granted to the resource in question, checking for explicit denies and scope mismatches.
Proposing a monitoring or logging solution that captures metrics but not the specific signal needed to detect or diagnose the described failure.
Candidates equate 'enable monitoring' with 'solved' and do not verify that the chosen metrics, logs, or traces actually surface the condition in the scenario.
What to do instead
Work backward from the failure symptom: identify the exact signal that would reveal it, then confirm the proposed monitoring emits and retains that signal.
Optimizing cost by downsizing or removing resources without confirming that the change preserves the stated availability, performance, or recovery requirements.
Candidates treat cost optimization as an isolated exercise and miss that removing redundancy or reducing capacity can violate an explicit SLA or RTO in the scenario.
What to do instead
Before recommending a cost reduction, restate the non-negotiable requirement from the scenario and verify the reduced design still meets it; reject savings that breach it.
Answering a multi-part scenario by addressing only the first requirement and ignoring secondary constraints such as compliance, latency, or operational overhead.
Candidates latch onto the most salient requirement and stop reading, so the chosen option satisfies one constraint while violating another stated in the prompt.
What to do instead
Enumerate every constraint in the scenario (explicit and implied) and check each candidate option against the full list before selecting.
Treating a service's scaling behavior as automatic and unlimited, without checking quotas, warm-up time, or state dependencies that limit scaling.
Candidates assume 'managed scaling' removes all capacity planning, overlooking service quotas, scale-out latency, and the need for externalized session state.
What to do instead
For any scaling design, verify the relevant quotas, estimate scale-out time against the traffic pattern, and confirm that the application can run statelessly across instances.