Free Datadog Fundamentals Exam Flashcards

The Agent runs as a system service or daemon so it can continuously collect and forward metrics, logs, traces, and events without requiring an interactive user session. This keeps monitoring alive through reboots and logouts.

The main Agent configuration file on Linux lives at /etc/datadog-agent/datadog.yaml. It holds host-wide settings such as the API key, site parameter, proxy configuration, and global tags.

YAML is whitespace-sensitive: nested keys must use consistent spaces, and tabs break parsing. A single mismatched indent in datadog.yaml can prevent the Agent from starting.

Supplies configuration values to a process from the environment instead of hardcoding them in files or commands. This is the standard way to pass secrets and site settings to containerized Agent deployments.

Descriptive key-value context (such as host, env, service, or region) attached to telemetry. Metadata lets you filter, group, and correlate metrics, logs, and traces across dashboards and monitors.

Measures sustained processor load. Consistently high CPU utilization indicates the server cannot keep up with workload demand and may need scaling or optimization.

TCP is connection-oriented and reliable, guaranteeing ordered, retransmitted delivery. UDP is connectionless and lightweight with no delivery guarantee, making it suitable for fast, fire-and-forget telemetry like DogStatsD packets.

A logical identifier that lets two programs on the same host multiplex network traffic. Each service binds to its own port so traffic reaches the correct destination application.

The /etc/datadog-agent/ directory is owned by root, so editing datadog.yaml requires elevated privileges. Using sudo grants the temporary root access needed to modify the file.

The > operator overwrites the target file, replacing its contents. The >> operator appends to the end, preserving existing content. Use >> when adding lines to config or log files without destroying prior data.

RAM holds the data and instructions a running process needs immediately. Disk stores data persistently and serves as swap space when RAM is exhausted, but disk access is far slower.

JSON is the standard request and response format for Datadog's HTTP APIs and most modern web services. It is human-readable, language-agnostic, and easy to parse programmatically.

The credential the Datadog Agent must have to submit metrics, events, and logs to your Datadog organization. It authorizes data ingestion and is required for every Agent installation.

Paired with an API key to access Datadog's management APIs for programmatic automation, including creating dashboards, managing monitors, and querying resources. The API key authenticates data submission; the app key authorizes management actions.

Safer for shared automation than a personal user's app key because it persists even after individual users are deactivated. It avoids tying critical automation to one person's access.

Agent v6+ accepts most datadog.yaml settings as environment variables with a DD_ prefix (e.g., DD_API_KEY, DD_SITE). This enables containerized deployments without mounting config files.

Editing datadog.yaml or an integration's conf.yaml does not apply settings immediately. You must restart the Agent service for new configuration to take effect.

Setting hostname explicitly in datadog.yaml makes Datadog report that fixed name instead of the OS-detected hostname. This provides stable identity but can cause duplicate host entries if the same name is reused across hosts.

When a user who created API or application keys is deactivated, those keys are deactivated by default. Automation relying on those keys will break unless keys are transferred to a service account beforehand.

Embedding an organization API key in browser JavaScript exposes it to anyone viewing the page. Use server-side calls with application keys and restricted scopes instead of client-side ingestion.

The Agent listens for DogStatsD custom metric packets on UDP port 8125 by default. Applications send metrics to this local port, which the Agent then forwards to Datadog.

The Agent's APM trace receiver listens on TCP port 8126 by default. Application trace libraries send span data to this port for the Agent to forward to Datadog.

Most outbound Agent traffic uses HTTPS over TCP port 443 to send metrics, logs, traces, and events to Datadog intake endpoints. This port must be open for the Agent to function.

Use domain-based allowlisting (e.g., *.datadoghq.com or site-specific domains) rather than hardcoding IP addresses. Datadog's IP ranges change over time, and static IPs can cause silent data loss.

Lets the Agent automatically detect and monitor containers and services using Docker labels or Kubernetes annotations. Configuration follows workloads instead of requiring manual edits each time a container starts.

A statsd-compatible protocol for submitting custom metrics from application code to the Agent over UDP. Supports gauges, counts, timers, and sets without needing direct API calls.

A gauge represents a snapshot value at a point in time (e.g., memory used). A count represents an accumulated value or rate that resets periodically (e.g., requests per second).

When you zoom a graph from one hour to one week, Datadog aggregates data points into bins to fit the display width. Each bin shows an averaged value, making the graph appear smoother at longer time ranges.

Cloud integration metrics (such as AWS or Azure) arrive later than host Agent metrics because crawlers poll cloud provider APIs on intervals rather than streaming continuously. Expect a delay of minutes, not seconds.

If you cannot run the Agent, submit custom metrics by POSTing to the Datadog API metrics endpoint with your API key. This is useful for serverless or short-lived environments where the Agent is impractical.

In Metrics Explorer, avg smooths across tagged sources by averaging values. Max shows the highest value across all sources, surfacing spikes and outliers that avg can hide.

A metric exists but does not appear in the Metrics Explorer because it has not received data recently. Datadog hides inactive metrics until they receive new points or you search for them explicitly.

Tags should use key:value format (e.g., env:prod, service:web, role:database). This standard enables consistent filtering and grouping across dashboards, monitors, and infrastructure views.

Putting the environment in a tag (env:prod) lets you filter dynamically without creating separate metric names. This keeps the metric namespace clean and allows cross-environment comparison.

Datadog's recommended standard of tagging every telemetry with env, service, and version. This trio correlates metrics, traces, and logs across the full stack, forming the foundation for unified observability.

Tags like request_id, user_id, or ephemeral container IDs create too many unique groupings. This degrades query performance, increases storage, and makes dashboards unreadable.

Grouping by a tag key (e.g., service) splits a single metric into one line per tag value. This reveals per-segment behavior instead of an aggregate that hides individual differences.

Filters the metric pool to a subset matching a tag scope (e.g., from:env:prod). You only query metrics matching that tag, reducing noise and focusing on the relevant infrastructure.

Copy the integration's example file (conf.yaml.example) to conf.yaml, fill in connection parameters, then restart the Agent. The Agent reads active conf.yaml files from the conf.d directory.

Indicates the Agent is running but has not received data for that integration recently. Common causes include incorrect credentials, network connectivity issues, or the target service being down.

Two YAML log collection files pointing to the same log source cause the Agent to tail it twice, producing duplicate log entries. Consolidate into a single configuration to avoid this.

The Agent's tailer reads files line by line, using newlines as delimiters. Custom log files written without newline terminators can delay or break log ingestion because the Agent cannot separate entries.

On systemd-based Linux hosts, `journalctl -u datadog-agent` shows detailed Agent logs when `systemctl status` output is too terse. This is the primary way to inspect Agent errors on modern Linux.

Collects a diagnostic bundle containing logs, configuration, and system information for Datadog Support. Use this subcommand when troubleshooting requires assistance from Datadog's support team.

Validates and displays the Agent's resolved configuration. It shows whether settings parsed correctly and which integrations are active, helping catch YAML errors before they cause silent failures.

Shows the Agent's running state, connected integrations, and recent errors in a single summary. This is the first command to run when verifying the Agent is healthy and collecting data.

A visual grid of all hosts colored by a selected metric (such as CPU or memory). It lets you spot outliers, patterns, and unhealthy hosts across infrastructure at a glance, without writing a query.

Datadog lets you graph a metric directly from search or the Metrics Explorer without building a full dashboard first. This is the fastest way to investigate a single metric on the fly.

Groups monitor evaluation by a tag key so the alert condition is checked per group (e.g., per host or per service) instead of globally. This ensures one failing instance triggers an alert without waiting for all instances to degrade.

Tags on monitors help route, filter, and organize alert notifications. They do not change the query itself but make it easier to find and manage monitors across teams and services.