Datadog Fundamentals Certification / 02 / 06
Infrastructure Development
What this domain covers
In this domain, you learn the steps for building the foundation that sends data to Datadog. Specifically, these are the paths for installing the Datadog Agent on hosts and containers (the in-app steps in Fleet Automation, Docker, Kubernetes, and configuration management tools), the difference in roles between the API key the Agent uses to submit data and the Application key used for the programmatic API, the commands for starting, stopping, and checking the status of the Agent, and the rules by which the Agent decides its own hostname. The exam presents these as a slice of real-world work, such as which key to use in a given situation, where the configuration file is located, how to pass the API key in a container, and which hostname is adopted from multiple candidates. Numbers and default values are based on the official documentation as of September 2026.
Topics listed in the official guide
- Installing the Agent
- API keys
- Application keys
- Running the Agent
- Agent hostname
Key points
- The Datadog Agent is open source software that runs on a host, collecting metrics and events and sending them to Datadog.
- An API key is unique to the organization and required for the Agent to submit data. An Application key is tied to a user and is combined with an API key to access the programmatic API.
- An organization can create up to 50 API keys by default, and a revoked key can be restored within 7 days.
- Submissions from browsers and mobile apps use a client token, not an API key. API keys must never be exposed on the client side.
- On Linux, the main configuration file is /etc/datadog-agent/datadog.yaml, and integration configuration goes in conf.d/ in the same location.
- When running the Agent in Docker, the DD_API_KEY environment variable is required, and DD_SITE specifies the destination site (the default is datadoghq.com).
- On Linux, use systemctl to start, stop, and restart the datadog-agent service, and check its status with datadog-agent status.
- The Agent's canonical hostname is the first candidate that meets the conditions, evaluated in the order of the name set explicitly in the configuration file, the DNS hostname, and the EC2 instance ID.
- Datadog sites (US1, EU1, AP1, and so on) are independent of one another, so the Agent's site parameter must be set to match your organization's site.
Terms and concepts
Datadog Agent
Software that runs on monitored hosts and containers, collecting system metrics such as CPU and memory, events, logs, and traces and sending them to Datadog. The source code is published in the datadog-agent repository on GitHub. External monitoring from cloud providers samples at intervals of several minutes, whereas the Agent collects statistics every 15 seconds from inside the host, so you get a finer-grained picture of what is happening. Tags set at the Agent level are attached to every metric, log, and trace that Agent sends. Datadog recommends updating at least once a month.
- Datadog AgentProduct
- HostGlossary
Installation Paths and Fleet Automation
The recommended way to install the Agent is to run, on the host, the script generated by the in-app steps in Datadog (Fleet Automation). On Kubernetes you can use the Helm chart or the Datadog Operator, and for configuration management you can use Ansible, Chef, Puppet, SaltStack, and others. Beyond installation, Fleet Automation lets you handle, from a single screen, the list of running Agents, their versions, configuration history, remote upgrades, and auditing of API key usage. A full Agent installation is normally recommended.
- Fleet AutomationGlossary
- Installing the Agent on LinuxArticle
- Deploying the Agent to Kubernetes (Helm)Article
API Key
A credential unique to the organization (org), required when the Agent submits metrics and events to Datadog. An organization needs at least one API key and can create up to 50 by default. Key names must be unique within the organization. Preparing a separate API key for each deployment method lets you revoke only the affected key in the event of a leak and limit the impact. A revoked API key remains in the Revoked state for 7 days, during which it can be restored with its original value. Unlike an Application key, an API key stays valid even if the user who created it is disabled.
- API KeyGlossary
- OrganizationGlossary
Application Keys and Scopes
A key that is combined with the organization's API key to call the programmatic API, for example to create dashboards and monitors. It is tied to the user account that created it and by default has the same permissions as that user. Specifying scopes that narrow the key to only the minimum permissions required is recommended, and scope names are case sensitive. When a user is disabled, the Application keys that user created are revoked. They cannot be transferred between users, so when a team needs a shared key, issue it from a service account. In organizations where One-Time Read mode is enabled, the secret value is shown only once, at creation time.
- API KeyGlossary
- Service AccountGlossary
- RBACGlossary
Client Token
A credential for sending data to Datadog from apps that run on end users' devices, such as browser, mobile, and TV apps. API keys cannot be used for this purpose because they would be exposed to users. RUM and the log collection libraries for browsers, Android, iOS, and others use client tokens. Client tokens are also unique to the organization and are managed on the Client Tokens tab in Organization Settings. Unlike API keys, a deleted client token has no grace period for restoration. It remains valid even if the user who created it is disabled.
- RUM (Real User Monitoring)Product
Configuration Files: datadog.yaml and conf.d
datadog.yaml is the main configuration file that holds the Agent-wide connection settings (api_key, site, proxy, and so on). Its location differs by OS: /etc/datadog-agent/ on Linux, /opt/datadog-agent/etc/ on macOS, and under %ProgramData%\Datadog\ on Windows. The configuration for each integration goes in the <CHECK_NAME>.d/ folder under conf.d, and you enable it by renaming conf.yaml.example to conf.yaml. In containers, settings are passed with environment variables that start with DD_.
- datadog.yamlGlossary
- AutodiscoveryGlossary
Starting the Agent and Checking Its Status
On Linux, you control the service with sudo systemctl start / stop / restart datadog-agent and display the status page with sudo datadog-agent status. Agent 6 and later use a subcommand style, with subcommands such as hostname, configcheck, diagnose, flare, and version. The Agent Manager GUI is enabled by default on Windows and macOS (port 5002, localhost only) and disabled by default on Linux.
- Datadog AgentProduct
- FlareGlossary
Datadog Sites and the site Parameter
Datadog operates independent sites for each region, such as US1 (datadoghq.com), US3, US5, EU1 (datadoghq.eu), AP1 (ap1.datadoghq.com, Japan), AP2, UK1, and government sites. Because data is not shared between sites, no data arrives unless the Agent's site parameter (DD_SITE in Docker) matches your organization's site. The default is datadoghq.com (US1). You can find your organization's site at the top of the My Preferences page in the Datadog app.
- Datadog SiteGlossary
Hostname Determination Rules
The Agent gathers multiple candidates, such as hostname in the configuration file, the DNS hostname, and the EC2 instance ID, and makes the first one that meets the conditions, in the following order, the canonical hostname. First, the hostname set explicitly in the configuration file (it must not start with ip- or domu); second, the DNS hostname (it must not be the EC2 default name ip-...); third, the EC2 instance ID; fourth, the DNS hostname even if it is the EC2 default name. Non-unique names such as localhost.localdomain are rejected, and evaluation moves on to the next rule.
Host Aliases and hostname_fqdn
Candidate names not chosen as the canonical hostname are registered as aliases of that host. Aliases can be viewed in the inspect panel of the Infrastructure List but cannot be used for search or filtering. Agent v5 obtained the FQDN with hostname -f, but v6 and later obtain the short hostname through the OS API, so the displayed name can change after an upgrade. Setting hostname_fqdn, added in v6.3, to true restores the same FQDN behavior as v5 (the default is false). In containers, you can set the hostname explicitly with the DD_HOSTNAME environment variable.
- HostGlossary
- Deploying the Agent to DockerArticle
Check your understanding
Check what you have learned with 5 questions