Grafana Administration
Grafana administration is the operational domain of a self-managed Grafana instance. It tests how configuration is loaded and overridden, how dashboards and data sources are provisioned, how users, organizations, teams, and roles interact, and how to keep the service healthy through backups, plugins, and upgrades. The exam favors precedence rules and the operational consequences of file-based versus database-backed state.
Configuration precedence
Grafana reads defaults, then /etc/grafana/grafana.ini (or --config), then GF_* environment variables, then command-line flags. A setting such as [server] http_port becomes GF_SERVER_HTTP_PORT. Sections include [database], [security], [auth.*], [smtp], [log], and [paths]. The provisioning root defaults to /etc/grafana/provisioning.
Provisioning and state
YAML under provisioning/datasources, provisioning/dashboards, and provisioning/alerting is read by Grafana. Datasource files use apiVersion: 1 and separate non-secret jsonData from secureJsonData. Dashboard providers point to JSON files and can poll with updateIntervalSeconds; allowUiUpdates: false keeps those dashboards read-only in the UI. Provisioning is declarative: files remain the source of truth.
Identity and access
Users can belong to multiple organizations. Org roles are Admin, Editor, and Viewer; Server Admin is global. Teams group users; folder permissions cascade to dashboards. Authentication can use basic auth, LDAP, OAuth, or SAML, with group or role mapping. Service accounts and tokens are preferred over legacy API keys for automation.
Operations
SQLite is the default database; HA needs a shared MySQL/PostgreSQL database and a shared session store. Back up the database, provisioning files, and plugins. Plugins are installed with the Grafana CLI and may require signing configuration. Admin password recovery is done with the CLI, not by hand-editing the database.
Worked example: A team wants an identical Prometheus datasource and dashboard set in staging and production, with no UI edits. They create a datasource YAML with the URL supplied by an environment variable and credentials in secureJsonData, plus a dashboard provider with allowUiUpdates: false pointing at JSON files. Grafana applies the datasource at startup and loads the dashboards through the provider. Reasoning: provisioning is idempotent and file-driven; the provider flag blocks UI drift; secrets stay out of committed files. Editing the dashboard in the UI would not persist because the file is authoritative.
Traps: editing grafana.ini while a GF_* variable overrides it; expecting UI edits to provisioned dashboards to survive; running multiple replicas on SQLite; confusing Server Admin with Org Admin; forgetting folder permission inheritance; installing unsigned plugins without enabling them.