obsdog

Datadog Fundamentals Certification / 01 / 06

Computer Fundamentals

What this domain covers

This domain does not cover Datadog-specific features; it covers the computing fundamentals that are a prerequisite for operating the Agent. The scope includes reading and writing YAML and JSON configuration files and responses, knowing how file locations and permissions differ across Linux / macOS / Windows, starting, stopping, and diagnosing the Agent from the shell, reading the intent of a Python custom check, understanding what CPU, memory, and storage metrics mean, and applying the differences between IP, TCP and UDP, and HTTP to the Agent's communication. The exam ties these fundamentals to operational situations, asking things like "what does this configuration fragment mean", "which protocol is used in this situation", and "which command do you use to check". This page is based on the official documentation as of September 2026.

Topics listed in the official guide

  • Editing configuration files
  • OS basics
  • Reading programming languages (YAML / JSON / Python / shell)
  • Hardware concepts (CPU / memory / storage)
  • Working in the shell
  • Metadata
  • Networking basics (IP / HTTP / TCP / UDP)

Key points

  • The default path of datadog.yaml differs by OS. On Linux it is /etc/datadog-agent/, and on macOS it is /opt/datadog-agent/etc/.
  • Check configuration lives in conf.d/<CHECK_NAME>.d/conf.yaml. Enable it by renaming conf.yaml.example, and files of size 0 are ignored.
  • The Agent loads every valid YAML file inside <CHECK_NAME>.d/. Invalid YAML with broken indentation is not loaded, so while the configuration can be split, the format is strict.
  • Agent communication is always initiated from the Agent side toward Datadog, and most of it is HTTPS over TCP 443. Datadog does not connect to the Agent.
  • DogStatsD listens on UDP 8125 by default. Because UDP does not wait for a response, the application's processing is not interrupted even if DogStatsD is down.
  • Destination domains point to a set of static IPs via CNAME, and the JSON at https://ip-ranges.<SITE> holds the CIDR list. Register all of the blocks in the allowlist.
  • On systemd systems, restart with sudo systemctl restart datadog-agent and check the state with sudo datadog-agent status.
  • The Agent's own log is at /var/log/datadog/agent.log on Linux. By default it rotates every 10 MB and keeps 1 backup.
  • Tags are recommended in key:value form, must start with a letter, are limited to 200 characters, and metric tags are normalized to lowercase. Do not use values that grow without bound as tags.
  • CPU, memory, and storage are collected by the System check bundled with the Agent as system.cpu.* / system.mem.* / system.fs.*.

Terms and concepts

Reading and writing YAML configuration files (datadog.yaml / conf.yaml)

Almost all Agent configuration is YAML. The main configuration file, datadog.yaml, holds host-wide connection information such as api_key, site, proxy, and default tags, while each integration's configuration is written in conf.d/<CHECK_NAME>.d/conf.yaml under the two keys init_config and instances. Because YAML expresses hierarchy through indentation, a mismatched number of spaces alone produces a structure different from what you intended. The Agent loads every valid YAML file in the folder, so configuration can be split across multiple files, and datadog.yaml.example is the first reference to consult for how to write it.

File locations and the run-as user on each OS

The same Agent is laid out differently depending on the OS. On Linux, configuration is under /etc/datadog-agent/ and logs under /var/log/datadog/; on macOS everything is under /opt/datadog-agent/; on Windows it is under %ProgramData%\Datadog. Because the Linux Agent runs as the dd-agent user, custom check files need permissions that dd-agent can read, and manual runs are performed with sudo -u dd-agent. Removing the package leaves the configuration, the dd-agent user, and the logs in place.

Shell operations and Agent subcommands

From Agent 6 onward, the command line uses a subcommand style in the form <AGENT_BINARY> <SUBCOMMAND> <OPTIONS>. Starting and stopping the service is left to the OS service manager (systemctl for systemd, startsrc / stopsrc for AIX), while the Agent's state is checked with status, the loaded configuration with configcheck, connectivity diagnostics with diagnose, and sending data to support with flare. Since --help shows the list, knowing where to look is more practical than memorizing. After editing configuration, the change does not take effect until you restart.

Reading JSON (ip-ranges and API responses)

The Datadog API takes GET / POST / PUT / DELETE requests to resource-oriented URLs, indicates success or failure with HTTP status codes, and always responds in JSON. JSON is a nesting of objects and arrays, and keys are enclosed in double quotes. A representative piece of JSON is the IP list at https://ip-ranges.<SITE>, where sections such as agents / api / apm / logs follow version and modified, each holding arrays in CIDR notation under prefixes_ipv4 and prefixes_ipv6.

Reading Python custom checks

A custom check is a class that inherits from AgentCheck, written in checks.d/<NAME>.py, and it sends data with self.gauge('metric name', value) inside check(self, instance). The configuration is conf.d/<NAME>.yaml, with a file name matching the .py file. The custom_ prefix is recommended, and Python 3 compatibility is required on the latest Agent. The collection interval is set per instance with min_collection_interval (default 15 seconds), but because the check shares a queue with other checks, an exact cycle is not guaranteed.

Hardware resource concepts and the System check

CPU, memory, and storage are collected by the System check. CPU is expressed as percentages: system.cpu.user (user space), system (kernel), idle, iowait (waiting on IO), and stolen (a virtual CPU waiting on the hypervisor). Memory is expressed in bytes as system.mem.total / used / usable, where usable corresponds to MemAvailable. For storage, in addition to capacity, the inode usage ratio system.fs.inodes.in_use is also important, because once inodes run out, files cannot be created.

Tags as metadata

Tags are metadata that add dimensions to metrics, logs, and traces, and the key:value form is recommended. They must start with a letter and may contain letters, numbers, underscores, minus signs, colons, periods, and slashes; anything else is converted to an underscore. The length limit is 200 characters for key and value combined, and metric tags are normalized to lowercase. The key extends up to the first colon, so the key of env:staging:east is env. Host tags are inherited by data from the same host. Avoid using values that grow without bound as tags, because they inflate the number of metrics.

Networking basics: IP addresses, CIDR, DNS, and allowlists

The Agent's destinations are per-site domain names that point to a set of static IPs as CNAME records. For an allowlist, use either the domain names or the CIDR blocks published at https://ip-ranges.<SITE>. CIDR is a notation such as 192.168.1.0/24 that indicates the length of the network portion. Because the IPs in use change over time, register all of the blocks. To go through a proxy, use proxy in datadog.yaml or environment variables such as DD_PROXY_HTTPS, and no_proxy accepts domains, CIDR blocks, single IPs, and host names.

Choosing between TCP and UDP, and between HTTP and HTTPS

TCP is a protocol that establishes a connection and confirms delivery as it sends, while UDP is a protocol that sends without a connection and without waiting. Almost all transmission from the Agent to Datadog is HTTPS over TCP 443, delivering data that must not be lost reliably. In contrast, DogStatsD, which passes custom metrics from an application to the local Agent, uses UDP 8125; it does not wait for a response, so it does not slow the application down, and the application does not stop even if DogStatsD goes down. Sending logs directly over TCP is unsupported because it lacks delivery guarantees, and the HTTP intake is recommended.

Precedence of environment variables and configuration files

Many Agent settings can be specified both as keys in datadog.yaml and as environment variables with the DD_ prefix. Environment variables override the values in the configuration file. However, DD_TAGS is space-separated, so writing DD_TAGS="test:this is a test" splits into 4 tags: test:this, is, a, and test. A value containing spaces is converted to underscores if written on the YAML side. To accept DogStatsD from outside a container, DD_DOGSTATSD_NON_LOCAL_TRAFFIC=true is required.

Check your understanding

Check what you have learned with 5 questions