2.1 Agent Install and Architecture

Why Agent Installation Matters on the Exam

Infrastructure Development is the second-largest domain on the Datadog Fundamentals outline. Roughly one in six scored questions tests whether you can install the Datadog Agent, understand its architecture, and connect it to the correct Datadog organization. The exam does not expect you to memorize every package-manager flag, but it does expect you to know where configuration lives, which credentials belong in the main config file, and how the Agent's internal components divide responsibility.

The Datadog Agent is a lightweight process (or set of processes) that runs on hosts, containers, or virtual machines to collect infrastructure metrics, run integration checks, receive DogStatsD custom metrics, forward logs and traces, and ship everything to your Datadog site over HTTPS. Unlike a passive SNMP poller, the Agent is an active participant in observability: it executes checks on a schedule, enriches data with host metadata and tags, and buffers telemetry when connectivity is briefly interrupted.

Installation Paths and Platform Basics

Datadog publishes first-class install methods for Linux, Windows, macOS, Docker, Kubernetes (Helm or the Datadog Operator), and major cloud marketplaces. On a standard Linux host, the one-line install script from Datadog's documentation registers the Agent as a systemd service and drops configuration under /etc/datadog-agent/. On Windows, the equivalent main file is datadog.yaml under C:\ProgramData\Datadog\, and the Agent runs as a Windows service.

Regardless of platform, every new Agent needs two organization-wide settings before it can report data:

The default US site is datadoghq.com. European organizations use datadoghq.eu. Other commercial sites include us3.datadoghq.com, us5.datadoghq.com, and ap1.datadoghq.com. Pointing an EU organization's Agent at the US default is one of the most common real-world misconfigurations — the Agent may look healthy locally while data never appears where the team expects.

Agent Architecture: What Runs on the Host

Modern Agent v7 bundles several cooperating subsystems behind a single service entry point:

Think of the Agent as a local observability hub: applications talk to DogStatsD or the trace port on localhost, integrations run as scheduled checks inside the Agent, and the core process batches and forwards results outbound on TCP 443.

Integration-specific settings live in conf.d/<integration>.d/conf.yaml, not in the main datadog.yaml. Datadog ships each integration folder with a conf.yaml.example template. The usual enablement workflow is to copy or rename that example to conf.yaml, fill in instance parameters, and restart the Agent so the new check loads.

Container and Automation Considerations

For Agent v6+, nearly every datadog.yaml key has an environment-variable equivalent: uppercase the option name and prefix it with DD_. Container deployments rarely edit files in place; instead they pass DD_API_KEY, DD_SITE, DD_HOSTNAME, and tag variables through the orchestrator manifest. This pattern is exam-relevant because scenario questions often describe Kubernetes or Docker rather than bare-metal Linux.

After installation, verify connectivity before moving on to dashboards. A successful install ends with the Agent service running and datadog-agent status showing the Forwarder able to reach Datadog intake endpoints. If the API key is missing or the site is wrong, the status output and Agent logs surface the failure early — long before you waste time building monitors on empty data.

Exam Traps to Avoid

• Integration config in the wrong file — api_key and site belong in datadog.yaml; database URLs and check intervals belong in integration conf.yaml files.
• Forgetting restart after install — package installs start the service, but manual config edits and integration enablement still require a restart.
• Confusing Agent with the Datadog web application — the Agent is host-side software; it does not compile dashboards locally.
• Assuming one API key per host — API keys are organization-level intake credentials shared across many Agents.

Infrastructure Development builds directly on the computer-fundamentals skills from Chapter 1: reading YAML, managing services, and reasoning about environment variables. Master Agent install and architecture here, and the networking, data-collection, and troubleshooting chapters become much easier to navigate.

Configuration File Layout on Linux

Knowing the on-disk layout prevents path questions from becoming guesswork. On a standard Linux Agent install:

Windows mirrors the same concepts under C:\ProgramData\Datadog\. macOS uses /opt/datadog-agent/etc/. Exam questions rarely ask for every path, but they frequently contrast the main config file with integration conf.yaml locations.

Package installs also register repository metadata so apt, yum, or dnf can upgrade the Agent independently of your application releases. Pinning Agent versions in production is a reliability practice — upgrading during an incident window is a common self-inflicted outage. The Fundamentals exam is more likely to ask what happens when config is wrong than which RPM channel you used, but understanding that the Agent is a managed package explains why restart and service-control questions appear alongside install questions.