JFrog Artifactory Certified DevOps Engineer cheat sheet

Repository types are local (direct deploy target), remote (caching proxy for an external source), and virtual (aggregates local and remote repositories behind one URL).

A repository's package type is selected at creation and fixes its layout, metadata model, and client behavior; it cannot be changed later.

A virtual repository resolves a requested path by searching its aggregated repositories in their configured order, so order determines which copy wins.

Remote repositories fetch and cache artifacts on first request; cache entries can be invalidated and unused cached artifacts can be cleaned up.

Include and exclude patterns use Ant-style wildcards and restrict which paths a remote, replication, or virtual repository handles.

Repository layouts define the path structure and metadata extraction rules; default layouts exist for each package type and custom layouts can be added.

Deployment calculates checksums and stores binaries in the filestore while the database records coordinates, properties, and security metadata.

Supported package types include Maven, Gradle, npm, PyPI, Docker, Helm, NuGet, Go, RubyGems, Debian, RPM, Conda, Composer, and generic.

Artifactory 7.x runs as a set of microservices behind a router; the router is the single HTTP entry point and forwards requests to the correct service.

The Artifactory service handles repository and binary operations, the Access service handles identity and authorization, and the metadata service indexes properties.

Binary payloads live in a filestore backed by filesystem, S3, GCS, or Azure; the database stores metadata, checksums, properties, and configuration.

An HA cluster requires all nodes to share one database and one filestore, with a load balancer in front of the router.

Default service ports include router 8082, Artifactory 8081, and Access 8040; reverse proxies normally expose the router port.

Supported production databases include PostgreSQL, MySQL, Oracle, and SQL Server; embedded databases are not intended for production.

Filestore storage is checksum-addressed, so identical binaries can be deduplicated and verified independently of repository paths.

The system.yaml file centralizes platform configuration for database, filestore, router, and security settings across services.

JFROG_HOME is the installation root; system.yaml under it defines database, filestore, router, and security configuration.

The master key encrypts sensitive configuration and credentials; it must be backed up because loss can make encrypted data unrecoverable.

The join key is a shared secret that cluster nodes use to authenticate when joining the platform; all nodes must use the same value.

binarystore.xml selects the binary provider (filesystem, S3, GCS, Azure) and supplies its parameters.

Installation options include RPM/DEB packages, Docker images, Helm charts for Kubernetes, and ZIP archives for manual installs.

A reverse proxy typically terminates TLS and forwards traffic to the router on port 8082, preserving forwarded headers.

Database settings can be supplied in system.yaml; PostgreSQL is the most commonly documented production backend.

Reindexing rebuilds the search index from stored metadata and binaries; it is not a substitute for a database or filestore backup.

A permission target grants users and groups roles on repositories, repository paths, builds, or release bundles.

Artifactory roles include read, annotate, deploy, delete, and manage; effective access is the union of direct and group grants.

Xray watches define the repositories, builds, or bundles to scan; policies define the rules and severity thresholds for violations.

Artifactory computes checksums on deploy and can verify client-supplied checksum headers before accepting an upload.

Scoped access tokens restrict actions and resources and carry expiry; they are preferred over legacy API keys for automation.

Anonymous access is controlled globally and per repository; disabling it forces authentication for every request.

Password policies, lockout settings, TLS, and secure cookies are configured in the Access service and platform configuration.

Release bundles can be GPG-signed so distribution targets can verify integrity and provenance before deployment.

Authentication realms include internal users, LDAP, SAML, OIDC, Crowd, and HTTP SSO; the Access service centralizes identity handling.

Users inherit permissions through group membership; external directory groups can be mapped to Artifactory groups.

Permission targets attach roles to resources and path patterns; include and exclude patterns refine the scope.

Artifactory generally has no explicit deny rule, so a user's effective permissions are the union of all granted roles.

Administrative rights are granted through group membership or the built-in admin user, not through repository roles alone.

SAML and OIDC integrations require metadata or issuer details, certificates, and a configured callback URL in Access.

Access tokens can be issued to users or service accounts and can be revoked independently of the user's password.

Build info records a build's modules, artifacts, dependencies, environment variables, and VCS details as structured JSON.

jf rt build-publish <build-name> <build-number> uploads collected build-info to Artifactory's build-info repository.

Build promotion copies or moves artifacts to a target repository and attaches status properties such as promoted or qa_passed.

Build retention discards old build-info records and optionally their artifacts based on count or age thresholds.

Maven and Gradle integrations use Artifactory plugins; other package managers commonly publish through the JFrog CLI.

Build-info includes checksums, so Xray and promotion workflows can trace artifacts back to the producing build.

Build dependencies can be recorded with jf rt build-add-dependencies, linking resolved third-party artifacts to the build.

Artifact properties are key-value metadata pairs attached to files or folders and searchable through the REST API and AQL.

Properties can be set at deploy time through matrix parameters or later with the properties REST endpoint.

AQL queries use domains such as items, builds, modules, and properties; results can be sorted and paginated.

Build promotion and release bundles move artifacts through stages while preserving metadata and checksums.

Webhooks send HTTP callbacks on artifact, build, or distribution events and can be scoped to specific repositories.

Release bundle v2 is immutable and signed; changes require creating a new version rather than editing the existing bundle.

AQL is submitted as a POST body to the search endpoint, while simple property searches can use query parameters.

Checksums and properties survive promotion and replication, enabling traceability across repositories and sites.

Push replication is configured on a local repository and asynchronously copies artifacts and properties to a remote Artifactory.

Pull replication is configured on a remote repository and fetches artifacts from an external Artifactory into the local cache.

Replication triggers can be cron-scheduled or event-based; event-based replication reacts to deploy and delete events.

Include and exclude patterns limit which paths are replicated, and delete replication can be enabled separately.

Multi-push replication sends one local repository's content to multiple target URLs for fan-out distribution.

Replication uses checksums to avoid transferring unchanged binaries and can replicate artifact properties.

Replication is asynchronous and is not a backup; it does not replicate permission targets or full platform configuration.

Artifactory REST endpoints live under /artifactory/api/, while repository content is served under /artifactory/<repository>/<path>.

REST calls authenticate with Authorization: Bearer <token> for access tokens or with basic credentials where enabled.

JFrog CLI commands such as jf rt upload, jf rt download, and jf rt search wrap the REST API for automation.

jf config add stores a platform URL and credentials or token; jf rt ping verifies connectivity.

AQL queries are executed with POST /artifactory/api/search/aql and return JSON results.

Release bundle v2 is created and distributed through the Distribution service, with GPG signing for integrity.

Webhooks and distribution targets can be managed through REST endpoints under the platform API.

List endpoints commonly support offset and limit parameters, or return paging headers for large result sets.