2.2 API Keys and Application Keys

Two Keys, Two Jobs

Datadog uses two primary credential types that Infrastructure Development questions love to contrast: API keys and application keys (sometimes called app keys). Confusing them is one of the fastest ways to lose points, because each key answers a different authentication question.

An API key is an organization-level intake credential. The Datadog Agent uses an API key to prove it is allowed to submit metrics, events, and other telemetry into your organization. Every Agent — across thousands of hosts if needed — can share the same API key. API keys are not tied to an individual user account in the same way application keys are.

An application key is a user- or service-account-scoped credential paired with an API key when calling Datadog's programmatic HTTP API. If you want a script, Terraform provider, or CI job to list monitors, create dashboards, or query metrics through the API, you typically present both an API key and an application key. The API key identifies the organization; the application key identifies who is making the request and what permissions they inherit.

What Each Key Can and Cannot Do

Write path: Submitting metrics and events requires an API key. The Agent does not need an application key for normal telemetry collection.

Read and manage path: Many Datadog API endpoints that return organizational data require both an API key and an application key. Calling those endpoints with only an API key returns an authorization error. Exam questions often describe an automation job that can push data but cannot query monitors — the missing piece is almost always an application key.

Browser trap: API keys are secrets and must never be embedded in client-side JavaScript where end users could extract them. Datadog provides client tokens for browser Real User Monitoring and similar products. If a scenario mentions a public web application sending telemetry from the user's browser, API keys are the wrong answer.

Lifecycle, Propagation, and Security Practices

When you create or revoke an API or application key in the Datadog UI, the change is eventually consistent — it may take a few seconds to propagate globally. Automation that uses a brand-new key should retry briefly rather than failing permanently on the first attempt.

Application keys created under One-Time Read mode display the secret only at creation time. If you do not store it immediately in a secrets manager, you cannot retrieve it later and must generate a new key. This behavior is deliberate: it limits long-term exposure of the secret in the UI.

Ownership matters for operations teams:

• Personal application keys belong to the user who created them. If that employee is deactivated, their application keys are revoked automatically — which can break shared cron jobs overnight.
• Service account application keys decouple automation from individual headcount. Datadog recommends service accounts for CI/CD, Terraform, and other durable integrations.
• API keys are organization-level. Deactivating a user does not automatically delete API keys that user created; you must revoke those keys explicitly if needed.

Environment Variables and Key Storage

In containers and configuration-management workflows, teams often inject DD_API_KEY rather than baking secrets into images. The same principle applies to API clients: read keys from environment variables or a secrets backend, never from source control.

Official Datadog API client libraries default to the US site (datadoghq.com) unless you configure the host or site parameter. An EU automation job that authenticates correctly but points at the wrong regional API host will fail or write to the wrong organization context — a separate but frequently paired mistake with key configuration.

Scenario Reasoning for the Exam

Work through credential questions in three steps:

1. Who is sending data? Agent or server-side forwarder → API key.
2. Who is calling the management API? Script, Terraform, or support tooling → API key plus application key.
3. Where does the code run? End-user browser → client token, not API key.

When a question mentions key propagation delays or a job that succeeds after a short retry, that is Datadog's documented consistency window — not a sign that the Agent must be restarted.

Strong key hygiene — least-privilege scopes on application keys, service accounts for automation, and prompt revocation on employee offboarding — is operational best practice. On the exam, the tested skill is knowing which key belongs in which workflow and what breaks when the wrong one is used or when a deactivated user owned your only application key.

Scopes, Rotation, and Audit

Modern Datadog organizations can scope application keys to specific permissions rather than granting full administrator API access. On the exam, scope language may appear as "an application key with only read access to dashboards" versus a full-access personal key.

Rotation workflow matters operationally: create the replacement key, update automation secrets, deploy, verify traffic, then revoke the old key. Because of propagation delay, revoke only after the new key is confirmed working. API key rotation follows the same pattern across every Agent and forwarder that shares the old value — missing one host is how ghost telemetry stops while the rest of the fleet reports normally.

Datadog's Audit Trail (an organizational feature) records many key-management events. While audit logging is not a Fundamentals deep dive, recognizing that API and application key changes are security-sensitive operations helps you eliminate absurd distractors such as "API keys are visible in browser local storage by default."