New Relic APM Practitioner common mistakes
New Relic APM Practitioner · Understand the traps and how to avoid them.
Treating the three APM 360 pillars (application, browser, and infrastructure context) as unrelated products, so the candidate answers a question about correlating a slow transaction with a slow host or a slow browser page by picking a single pillar instead of the correlated view.
Candidates study each pillar in isolation and never practice the workflow of pivoting from an APM transaction trace to host metrics and to browser session data, so they miss questions that test cross-pillar correlation.
What to do instead
Practice the pivot path explicitly: start on a slow transaction, open its trace, inspect the external service and database spans, then follow the host link to infrastructure metrics and the browser link to page-load data. Before exam day, be able to describe, in one sentence each, what each pillar contributes to a single user's slow request.
Confusing Apdex score, response time percentiles, throughput, and error rate when asked which metric best detects a specific condition, for example choosing average response time to detect that a small subset of users is affected.
Averages are intuitive and candidates default to them, forgetting that averages hide tail latency and that Apdex is a satisfaction threshold ratio rather than a latency measure.
What to do instead
Memorize the definition of each: Apdex = (satisfied + tolerating/2) / total; percentiles describe the distribution tail; throughput is requests per minute; error rate is failed transactions over total. Drill with scenarios such as 'a few users see 10-second loads while the average is fine' and confirm the answer is a high percentile, not the mean.
Mixing up transaction traces, slow query traces, and error traces, and answering a question about finding the slowest database call with the wrong artifact or the wrong place in the UI.
All three are trace-like artifacts surfaced under APM, and candidates skim the docs without noting which artifact captures which signal and how sampling affects whether a trace exists.
What to do instead
Build a one-page comparison: transaction trace shows the full call tree for one slow request; slow query trace isolates database statement time; error trace captures an exception with its stack. Note that trace capture is sampled and threshold-based, so a missing trace is not proof the event did not occur.
Assuming browser monitoring requires manual agent installation in the page source, or that it cannot work without APM, and answering deployment questions accordingly.
Candidates carry over assumptions from other tools and do not distinguish the APM-injected browser agent from the standalone copy-paste snippet.
What to do instead
Learn both deployment modes: automatic injection through the APM agent versus a standalone JavaScript snippet for apps without APM. Know that browser monitoring reports Core Web Vitals, JavaScript errors, AJAX calls, and session data, and that it can run independently of APM.
Confusing synthetic monitors (scripted or ping checks run from managed locations) with real user monitoring, and picking synthetic monitoring to answer a question about actual end-user experience in a specific region.
Both are grouped under digital experience, and candidates treat them as interchangeable rather than complementary, missing that synthetic gives controlled baseline coverage while RUM gives real traffic distribution.
What to do instead
State the distinction as a rule: synthetic answers 'can users reach it and how fast from here, on a schedule' while RUM answers 'what are real users actually experiencing, including by browser, device, and geography'. Practice choosing between them for scenarios like pre-release smoke checks versus production field data.
Treating New Relic AI and applied intelligence features as a single generic 'AI assistant' and failing to distinguish alerting features such as anomaly detection, baseline alert conditions, and NRQL alert conditions from the generative assistant.
Marketing-level familiarity with AI features replaces hands-on knowledge of which capability does what, so candidates cannot map a described need to a specific feature.
What to do instead
Map each capability to its job: NRQL alert conditions for explicit thresholds, baseline conditions for deviation from learned behavior, anomaly detection for outlier signals, and the AI assistant for natural-language querying and investigation help. For each, write one scenario where it is the right tool and one where it is not.
Answering infrastructure questions as if the infrastructure agent only collects CPU and memory, ignoring the integrations and on-host integration layer that collect service-specific metrics such as Apache, MySQL, or Kubernetes data.
Candidates memorize the agent install step and stop there, never learning that the agent is a host-level collector extended by integrations and that custom attributes and labels control how data is tagged.
What to do instead
Learn the layered model: infrastructure agent on the host, on-host integrations for service metrics, and tagging through custom attributes that flow into NRQL filtering. Practice writing a NRQL query that filters host metrics by a custom tag to prove you understand how tagging drives segmentation.
Writing NRQL that filters on the wrong attribute or event type, or using SELECT with a facet on a field that does not exist in the queried event, and then choosing that query as correct because it looks syntactically plausible.
Candidates memorize NRQL syntax shape without learning the event and attribute model, so they cannot tell that Transaction, PageView, and SystemSample carry different attributes.
What to do instead
Before the exam, list the core event types and three or four key attributes for each (for example Transaction with duration and appName, PageView with browser and device type, SystemSample with host and CPU fields). Practice reading a query and naming which event it targets and whether each attribute belongs to it.
Confusing alerts, alert policies, and notification channels, or assuming an alert condition fires notifications without a policy binding and a destination configured.
The three-part structure is easy to read but easy to forget, and candidates answer incident questions as though creating a condition is sufficient.
What to do instead
Trace the full path once: condition defines what is evaluated, policy groups conditions and defines the incident, workflow or notification destination decides who is told and how. Then answer practice questions by asking 'which layer is being described' before choosing.
Misunderstanding data retention, sampling, and query cost limits, such as assuming all telemetry is retained indefinitely at full fidelity or that every event is stored for every trace.
Candidates skip platform-level documentation because it seems administrative, then miss questions about why historical data is unavailable or why trace counts appear lower than request counts.
What to do instead
Learn the retention tiers for events, metrics, and traces, and the difference between sampled trace capture and full metric aggregation. Be able to explain why a query over an old date range returns less data and why a trace may be absent even though the transaction occurred.