New Relic Verified Foundation common mistakes
New Relic Verified Foundation · Understand the traps and how to avoid them.
Treating the Apdex T threshold as a global setting and assuming one value applies to all transactions, then misreading Apdex scores as an average response time.
Candidates learn the Apdex formula (satisfied + tolerating/2) / total but forget that T is configured per application and per transaction type, so they compute or interpret scores against a single assumed threshold. They also confuse Apdex with a latency average.
What to do instead
Memorize that Apdex T is user-defined per app/transaction, and that scores range 0-1 where 1 is all satisfied. Practice reading a scenario where T is given and classify samples into satisfied/tolerating/frustrated before computing. Never treat Apdex as a mean latency.
Confusing response time breakdown segments in transaction traces, attributing database or external call time to application code, and misidentifying where the bottleneck sits.
The trace waterfall shows segments (database, external service, framework, app code) but candidates skim the total duration and blame the slowest-looking row without checking segment type and exclusive time.
What to do instead
Learn the segment categories and that exclusive time subtracts child segment time. Practice reading a trace: identify the largest exclusive-time segment, then check whether it is a datastore, external, or app segment. Answer the question 'where is time spent' before 'what is slow'.
Assuming browser monitoring data is captured the same way regardless of agent type, and expecting session traces or AJAX details from a browser agent deployment that does not provide them.
Candidates conflate the full browser agent (Pro+SPA) with the lighter browser lite/pro configurations and expect identical feature coverage, or they assume server-side APM automatically produces browser data without a deployed browser agent.
What to do instead
Map features to agent type: full browser agent supports page load timing, AJAX, JS errors, and session traces; lighter configurations do not. Remember browser data requires the browser agent snippet in the page, separate from the APM agent. Verify by checking the deployment method in the scenario.
Mixing up synthetic monitor types and their run locations, expecting a simple ping monitor to validate a multi-step login flow or assuming scripted browsers run from the user's own network.
Synthetic monitoring offers ping, simple browser, and scripted browser monitors, and private vs public locations. Candidates pick 'synthetic' generically without matching monitor type to the check being performed.
What to do instead
Memorize: ping checks availability/response, simple browser loads a page, scripted browser executes Selenium-style steps. Public locations run from New Relic's global network; private locations run from customer-hosted minions. Match the monitor type to the user journey described in the question.
Treating New Relic AI features as autonomous remediation and expecting the platform to apply fixes, rather than as anomaly detection, alerting, and assistant-style analysis that surfaces insights for a human.
Marketing language around AIOps leads candidates to overstate automation. Questions test what the platform actually does: applied intelligence correlates incidents, detects anomalies, and summarizes, but does not auto-remediate production without configured workflows.
What to do instead
Frame AI features as detection, correlation, and recommendation. Remediation requires explicitly configured workflows or integrations. When a question asks what happens automatically, choose the observability action (alert, correlate, summarize), not the change action (restart, rollback).
Confusing alert policy constructs, such as thinking a condition directly notifies users, or that a policy is a single threshold rather than a container of conditions and notification channels.
Alerting has layers: policies contain conditions (NRQL, APM, infrastructure, synthetic), and notification channels/workflows are attached at the policy level. Candidates collapse these layers and misattribute where thresholds and destinations are set.
What to do instead
Draw the hierarchy: policy > conditions (with thresholds and evaluation windows) > notification destinations or workflows. Remember conditions determine when an incident opens; the policy's notification configuration determines who is told. Practice tracing a scenario from signal to recipient.
Assuming infrastructure data requires the infrastructure agent for all hosts, when cloud integrations and the Kubernetes integration collect much of the same data without a host-installed agent.
Candidates treat the infrastructure agent as mandatory everywhere, missing that AWS/GCP/Azure integrations poll cloud APIs and the Kubernetes integration uses a DaemonSet plus kube-state-metrics. This leads to wrong answers about prerequisites.
What to do instead
Map data source to mechanism: infrastructure agent for host metrics/processes, cloud integrations for managed services, Kubernetes integration for cluster/container data, and Prometheus/OpenTelemetry for custom metrics. Check the environment in the question before choosing an installation path.
Misunderstanding log parsing and forwarding, expecting logs to be structured automatically or assuming the logging agent ships everything without a parsing rule.
Log management requires a forwarder (infrastructure agent's logging plugin or Fluent Bit/Fluentd) plus parsing rules to extract attributes. Candidates answer as if raw lines become queryable attributes by default.
What to do instead
Remember the pipeline: collect/forward > parse (Grok or built-in rules) > enrich with attributes > query in logs UI/NRQL. If a question asks how to make a field queryable, the answer involves a parsing rule, not just forwarding. Know that attributes enable filtering and faceting.
Confusing NRQL aggregation behavior, such as using average where a percentile is needed, or forgetting that FACET splits results and TIMESERIES changes output shape.
Candidates write or read NRQL casually and treat AVG, percentile(), and count() as interchangeable, or misread a faceted result as a single aggregate. This drives wrong conclusions about dashboards and alerts.
What to do instead
Review core NRQL clauses: SELECT ... FROM ... WHERE ... FACET ... TIMESERIES ... LIMIT. Know that percentile(...,95) answers tail-latency questions, AVG hides outliers, and FACET returns one row per group. Practice predicting the shape of a result before reading options.
Assuming all accounts have identical data retention and feature access, ignoring how data options (such as the free tier's shorter retention) and user roles change what is visible and queryable.
New Relic's pricing and account model ties retention and ingest to data options and plan, and roles/permissions gate access to features. Candidates answer capability questions without checking the tier or role in the scenario.
What to do instead
Learn that retention differs by data option/tier (shorter on free, longer on paid), that ingest is metered by data type, and that user type/role controls access. For any 'can this user see or query X' question, check both the account's data option and the user's permissions.