Akamai App & API Protector common mistakes
Akamai App & API Protector · Understand the traps and how to avoid them.
Treating a WAF rule action of 'alert' as if it were blocking, and answering that traffic was denied when the policy was in alert mode.
Candidates conflate the concept of a rule matching with the concept of enforcement, so they assume any match equals a block.
What to do instead
Before answering, identify the configured action (alert, deny, or none) for the specific rule and state that alert mode only logs and does not block the request.
Assuming a request that passes the WAF is automatically safe from bots, ignoring that bot detection is a separate evaluation layer.
The four domains overlap in the product, so candidates merge WAF matching with bot classification and forget the request can be legitimate to the WAF yet still be automated traffic.
What to do instead
Treat bot management as its own decision path: determine whether the client was classified (human, bot, or unknown) and whether a bot action was applied, independently of WAF rule outcomes.
Confusing a rate-control threshold with a DDoS scrubbing threshold, and answering that volumetric traffic was absorbed when only rate limiting applied.
Both involve counting requests or packets over time, so the mechanisms blur together under exam pressure.
What to do instead
Map the scenario to the layer: rate controls act on application-layer request rates per client, while DDoS protection addresses volumetric or protocol-layer floods; state which one the described condition triggers.
Selecting a positive-security (allowlist) model when the scenario describes a negative-security (signature/blocklist) deployment, or vice versa.
Candidates learn both models but do not check which one the described policy actually implements before choosing a remediation.
What to do instead
Ask whether the policy defines what is allowed or what is blocked; match the answer to that model, and note that allowlisting requires the full set of legitimate traffic to be enumerated.
Answering that an API endpoint is protected simply because the web WAF policy covers the hostname, without considering API-specific schema and parameter enforcement.
Candidates treat API traffic as ordinary HTTP and skip the request/response schema validation and method/parameter constraints that API protection adds.
What to do instead
Separate web protection from API protection: confirm whether API definitions and schema validation are applied, and whether the specific method and path are in scope.
Reporting that a bot was blocked when the configured action was a challenge or a tarpit rather than a denial.
All bot actions are mentally grouped as 'stopping the bot', so the distinction between challenging, delaying, and blocking is lost.
What to do instead
Name the exact action taken (deny, challenge, tarpit, or monitor) and describe its effect: a challenge verifies the client, a tarpit slows it, and only deny refuses service.
Attributing a false positive to a missing rule when the actual cause is a custom rule or a rule in a specific evaluation stage interacting with the request.
Candidates jump to 'add an exception' without tracing which rule matched and at which stage of evaluation the match occurred.
What to do instead
Trace the match to the specific rule and its evaluation stage, then apply the narrowest fix such as a targeted exception or condition adjustment rather than disabling protection broadly.
Assuming DDoS mitigation requires manual intervention when the described configuration provides automatic, always-on detection and mitigation.
Candidates picture traditional on-premises scrubbing that needs an operator to divert traffic, and apply that mental model to a cloud service.
What to do instead
State whether the protection is always-on and automated for the described condition, and reserve manual steps for scenarios that explicitly describe escalation or custom runbook actions.
Ignoring that an API request can be malicious even when it is well-formed and authenticated, and answering that authentication alone establishes safety.
Candidates equate valid credentials and valid JSON with legitimate intent, missing abuse of authorized API access.
What to do instead
Distinguish authentication from authorization and abuse detection: confirm whether the request violates schema, rate, or behavioral expectations even though it authenticated successfully.
Treating 'monitor' or 'learn' mode results as enforcement outcomes, concluding that malicious traffic was stopped during a tuning period.
Candidates see detections in the scenario and assume detection implies prevention, forgetting that learning modes only observe.
What to do instead
Check the deployment mode first; if the policy is in monitor or learning mode, state that detections were recorded but traffic was not blocked, and describe what would change in enforce mode.