Datadog IPs and Connectivity

Connectivity Is an Outbound Problem

The Datadog Fundamentals outline treats IP allowlisting and connectivity as its own sub-topic because enterprise firewalls routinely block "unknown outbound HTTPS." The mental model that earns points: your Agent calls Datadog; Datadog does not call your Agent for routine metric and log delivery. Security reviews therefore focus on egress allow rules, not punching inbound holes for a monitoring vendor.

When an exam vignette says checks run locally but nothing appears in the UI, suspect blocked outbound 443, a wrong site, or a proxy misconfiguration before you rotate API keys.

Site Endpoints and Regional Hostnames

Every Datadog organization lives on a site—US1 (datadoghq.com), EU (datadoghq.eu), US3, US5, AP1, and others documented in Datadog's site list. The Agent's site setting (or DD_SITE) selects which regional hostnames it uses for intake, logs, and related services.

Firewall language should reference the domains for your site, not a single IP address copied from one dig query yesterday. Datadog publishes the hostnames Agent traffic uses; matching your organization's site is step one in any connectivity checklist.

Datadog IP Addresses and Published Ranges

Many security teams cannot allow "all outbound HTTPS." Datadog documents that intake and API destinations resolve through CNAME records backed by static IP ranges that Datadog publishes for allowlisting. The Fundamentals exam favors answers that say use Datadog's published IP ranges for the relevant endpoints rather than "allow whatever IP DNS returns right now."

Why published ranges win:

• Endpoint addresses can change as Datadog scales infrastructure.
• A one-time nslookup snapshot becomes stale and causes intermittent upload failures that look like flaky integrations.
• Product-specific ranges (metrics, logs, APM, etc.) let you minimize exposure instead of allowing the entire internet on 443.

If your organization maintains strict egress controls, the supported workflow is: identify your site, identify which products the Agent uses, and allow the documented domains and/or IP ranges for those products. Disabling TLS to simplify inspection is never the right answer on the exam—Datadog expects encrypted transport.

Proxies and Restricted Egress

When direct outbound internet access is impossible, Datadog supports routing Agent traffic through an HTTPS proxy. Proxy settings live in datadog.yaml under the proxy section or via environment variables such as DD_PROXY_HTTPS. The Agent still initiates the connection; it simply tunnels through your corporate proxy appliance.

Exam traps here:

• Opening inbound management ports does not replace outbound allow rules.
• A proxy configured for browsers but not for the Agent service account produces "works in curl, fails in Agent" symptoms.
• Forgetting to allow the proxy itself to reach Datadog endpoints leaves you one hop short.

Verifying Connectivity in Practice

Before opening a support ticket, operators usually confirm:

1. DNS resolution for site hostnames from the Agent host.
2. Outbound TCP 443 (or proxy path) using curl or Datadog's documented connectivity tests where available.
3. datadog-agent status — running checks with no API errors versus explicit intake errors in the status output.
4. Site alignment — API key created in EU but Agent pointed at datadoghq.com is a classic misconfiguration.

The Agent flare bundle (datadog-agent flare) is support-oriented, but for Fundamentals you should recognize that connectivity failures surface in status and logs long before flare is needed.

Firewall Scenarios the Exam Loves

Scenario A — Locked-down datacenter. Host metrics never arrive. Status shows running checks. Fix: allow outbound 443 (or proxy + published ranges) to the correct site endpoints.

Scenario B — DogStatsD works host-local only. Sidecar containers send metrics; nothing arrives. Fix: networking to UDP 8125 and DD_DOGSTATSD_NON_LOCAL_TRAFFIC—this is port configuration (chapter section one) plus reachability.

Scenario C — Stale IP allowlist. Worked for months, then random upload failures after Datadog infrastructure changes. Fix: refresh from published IP ranges, not a fixed /32 from last year.

How This Connects to Autodiscovery

Connectivity gets data out of your environment; Autodiscovery (next section) decides what to collect from dynamic containers. Both show up under Networking & Agent Configuration because Kubernetes clusters fail in two independent ways: Agents cannot reach Datadog, or Agents reach Datadog but never resolve integration templates. Learn to separate those failure modes in exam narratives.

Site Examples (Illustrative)

The exact hostname list changes; the exam tests whether you know to consult Datadog's site and network documentation for your region—not whether you memorized every subdomain.

IP Allowlist Maintenance Workflow

A durable workflow security teams use:

1. Identify products in use (metrics, logs, APM, etc.).
2. Download or subscribe to Datadog's published ranges for those products and your site.
3. Allow outbound connectivity to those ranges (or to the documented domains if policy prefers FQDN rules).
4. Schedule periodic refresh—treat ranges like any other cloud vendor egress list.

Choosing "allow only the last IP returned by DNS" fails step 4 and is explicitly the weaker answer in practice questions.

Connectivity questions are not authentication questions: timeouts suggest network path problems; 401/403 in status suggest key or site issues.