Datadog APM & Distributed Tracing Fundamentals exam-day guide
Datadog APM & Distributed Tracing Fundamentals · Prepare for the day ahead.
Your checklist
Confirm test format, delivery method, and time limit with the provider
This guide covers content preparation, not logistics. Before finalizing your plan, confirm with the provider whether the exam is proctored online, taken at a test center, or unproctored, how many questions it contains, and how much time you get. Do not assume a format based on other Datadog or APM exams. Mark this as needs_review until you have a written confirmation.
Government-issued photo ID matching your registration name
Most proctored exams require a valid passport or government photo ID whose name matches your registration exactly. If your registration name differs from your ID (for example, a nickname or a maiden name), confirm with the provider how to correct it before test day. Keep the ID on your desk in case the proctor asks to see it.
Know your tracing vocabulary cold
Be able to define trace, span, parent-child relationship, span context, service, resource, operation name, tags, span type, and sampling, and explain how they relate. Exam questions often test whether you can distinguish a trace ID from a span ID, or a service from a resource, so practice stating each definition in one sentence.
Review the Datadog Agent and tracing library setup path
Know the sequence: install and configure the Agent, enable APM, point the tracer at the Agent (host, port, and whether it uses a Unix socket or TCP), set the service, environment, and version tags via the tracer, then verify traces appear in the APM UI. Be ready to identify which setting lives in the Agent config versus the application's tracer configuration.
Practice reading a flame graph and a service map
You should be able to look at a described trace and say which span is the bottleneck, which service is the root, where an error originated, and how a downstream timeout propagates upward. Since you cannot rely on exhibits, practice narrating traces in words: 'the web request span is 800 ms, of which 700 ms is a child database span.'
Memorize the propagation mechanisms and their trade-offs
Know how trace context moves between services (for example, HTTP headers and message-queue injection/extraction), why header propagation must be configured for non-instrumented hops, and what breaks when a proxy or async boundary drops headers. Understand the difference between automatic instrumentation and manual span creation, and when each is needed.
Understand sampling controls and their observability consequences
Be able to explain head-based versus tail-based sampling at a conceptual level, what happens to trace completeness and metric accuracy when you sample, and why you would keep error traces while dropping routine ones. Confirm with the provider which sampling features are in scope for this exam version, since product capabilities change.
Review retention, ingestion, and cost controls
Know that trace retention is limited and configurable, that ingestion volume drives cost, and that you can control volume with sampling, exclusion filters, and retention filters. Be ready to reason about a scenario where a team sees too many traces or too-high bills and pick the appropriate lever.
Prepare a one-page formula and concept sheet
Write, by hand, the definitions and decision rules you keep forgetting: latency versus duration, error rate calculation, the difference between a span tag and a metric tag, how to correlate logs and traces, and how to query traces by service, resource, and status. Rewriting these from memory is the single highest-yield review activity in the last 72 hours.
Do timed practice on scenario-style questions
Answer questions that describe a symptom ('traces are missing for one service', 'latency spikes only in production') and require you to choose the most likely cause or next diagnostic step. Time yourself so you learn your pace, and review every wrong answer to find the underlying concept gap, not just the correct letter.
Set up your test environment if the exam is remote
If the provider confirms a remote-proctored format, test your camera, microphone, browser, and internet connection in advance, and clear your desk of notes and devices unless explicitly allowed. Confirm with the provider which materials are permitted; do not assume open-book rules.
Plan sleep, food, and a buffer around the start time
Schedule the exam for a time when you are alert, avoid heavy meals beforehand, and give yourself 30 to 60 minutes of buffer so a login or connection problem does not cost you exam time. Fatigue and panic cause more lost points than missing trivia.
Plan the day
Do a full diagnostic pass: take one timed practice set covering the whole blueprint, then list every topic where you guessed or were unsure. Rank those gaps by how often they appeared. Spend the remaining three days on the top gaps, not on material you already know. Re-read your own notes on tracing fundamentals, Agent and tracer setup, propagation, and sampling.
Write your one-page concept sheet from memory, then check it against your notes and correct it. This forces recall rather than recognition. Keep the corrected sheet as your only review document for the final day.
Work through scenario-style questions on the topics you ranked highest. For each one, say out loud why the wrong answers are wrong. Focus especially on troubleshooting symptoms: missing traces, broken service maps, partial traces caused by dropped context, and unexpectedly high ingestion.
Do a light review only: your concept sheet plus a short list of definitions. Do not start a new topic. Confirm your exam time, time zone, and login or arrival details with the provider. Prepare your ID and, if remote, test your equipment once more. Sleep a full night.
Skim the concept sheet for 15 to 20 minutes, nothing more. Eat a normal meal, hydrate, and avoid cramming new material. Log in or arrive early to absorb any setup friction. Have your ID, water, and any provider-approved materials within reach.
Read each question fully and identify what is actually being asked: a definition, a most-likely cause, a next step, or a best configuration. Answer confident questions first and flag long scenario questions for a second pass. Eliminate clearly wrong options before choosing. If a question depends on a product detail you cannot verify, choose the answer that follows sound observability reasoning rather than guessing at a specific UI label. Watch the clock and reserve the last few minutes to revisit flagged items.
Rules to check
Follow the provider's identity rules exactly: present a valid government-issued photo ID whose name matches your registration, and confirm with the provider in advance what to do if it does not.
Do not use unauthorized materials, notes, devices, or assistance. Whether the exam is open- or closed-book varies by provider and delivery method, so confirm the permitted-materials policy with the provider before test day rather than assuming.
Understand the scoring model before you sit: confirm with the provider whether there is a pass threshold, whether wrong answers are penalized, and whether sections are weighted. If there is no penalty for guessing, never leave a question blank.
Know the break policy in advance. Proctored exams often restrict breaks and may not stop the clock, so confirm with the provider whether breaks are allowed and how they affect your time.
Respect the time limit and any section timers. If you fall behind, prioritize questions you can answer quickly and return to long scenarios only if time remains.
If technical problems occur during a remote exam, stop and contact the proctor or provider support immediately through the official channel; do not attempt to fix the session by yourself in ways that could be read as a conduct violation.
Do not attempt to record, screenshot, or share exam content. Treat all questions as confidential, regardless of whether the exam is proctored.
If a question seems to depend on a specific product version or feature that may have changed, answer from the underlying concept and note that exact feature scope should be confirmed with the provider; do not invent policy or product behavior.