← All study guides
PDAA-001
Certified Expert - PingDirectory
Part of Certified Expert - PingDirectory
Each voucher code is valid for a single exam attempt only; once redeemed it cannot be reused. Exam covers PingDirectory version 9 or later.
Independent study aid built from the public exam blueprint. Not affiliated with, authorized by, or endorsed by ping. Objectives are transcribed and mapped by hand, so this page may contain mistakes or may have fallen behind the vendor's current material: exam objectives, versions, numbering and availability all change without notice. Treat ping's own certification portal as the source of truth and verify against it before you book anything.
Objective 1: Advanced Configuration
PDAA-001.1.01 Create and/or manage an ACI.
What to know:- An ACI (access control instruction) is stored on the entry it protects, in the aci operational attribute.
- Syntax has three parts: target (what), permission and rights (allow or deny, which operations), and bind rule (who, under what conditions).
- Deny always wins over allow when both match, so build with allows and use denies sparingly.
- Test with an authenticated search as the affected user rather than reasoning about the rule in the abstract.
- dsconfig manages server configuration; ACIs live in the data and are managed with LDAP modifications.
PDAA-001.1.02 Configure PingDirectoryProxy to balance entries between two instances of PingDirectory.
What to know:- PingDirectoryProxy sits in front of backend PingDirectory instances and distributes operations across them.
- Entry balancing partitions the DIT across backend sets so no single set holds all entries.
- A global index is what lets the proxy know which balancing point holds a given entry.
- Entry balancing is for scale beyond a single server's capacity; plain load balancing is for availability and throughput.
- Plan the balancing point carefully, because changing it later requires data movement.
PDAA-001.1.03 Configure PingDataSync to migrate data from another directory.
What to know:- PingDataSync synchronizes entries between a source and a destination, including foreign directories.
- Sync pipes define source, destination, and the attribute mapping between their schemas.
- Resync performs a bulk pass; ongoing sync follows the change log.
- Attribute mappings handle schema differences; transformation is where most migration effort lands.
- Run in dry-run mode first and inspect what would change before enabling the pipe.
PDAA-001.1.04 Update and manage certificates.
What to know:- Certificates live in the keystore and trust store configured on the connection handlers.
- manage-certificates is the tool for inspecting, generating, importing, and exporting key material.
- Replace certificates before expiry and confirm the full chain is present, not just the leaf.
- Replication and inter-server connections use certificates too; a renewal that misses those breaks the topology quietly.
- Track expiry dates as an operational task; expired certificates are the most common self-inflicted outage.
PDAA-001.1.05 Manage setting up, purging, and restoring soft deletes.
What to know:- Soft deletes mark an entry deleted while retaining it, so it can be restored.
- The soft-deleted entry gets a new RDN and is hidden from ordinary searches unless explicitly requested.
- Purging is time-based and configurable; the retention window is a policy decision with storage consequences.
- Restoring an entry returns it to its original location; understand what happens if that DN is now occupied.
- Applications must be aware of soft deletes, because a deleted entry still consumes its unique identifiers.
PDAA-001.1.06 Backup and restore data.
What to know:- backup and restore are the supported tools; file-level copies of an open database are not safe.
- Backups can be full or incremental, and can be encrypted and signed.
- Restoring into a replicated topology requires care: a restored server must be re-initialized or it will replay stale changes.
- Verify backups by restoring them somewhere, not by confirming the job exited zero.
- Retention and off-host storage of backups are part of the design, not an afterthought.
PDAA-001.1.07 Configure and manage replication.
What to know:- Replication is multi-master: any server accepts writes and propagates them to the others.
- dsreplication enable, initialize, and status are the core commands.
- Conflicts are resolved automatically by timestamp and server ID; understand which entry wins and why.
- Replication uses its own port and credentials; firewalling must permit it or the topology silently diverges.
- Monitor replication backlog as a first-class health metric.
PDAA-001.1.08 Configure a global index.
What to know:- A global index lets PingDirectoryProxy resolve which entry-balanced backend set holds a given entry.
- It is populated from the backend data and must be kept current as entries move.
- Index memory sizing is a capacity planning input for the proxy.
- Without it, the proxy must broadcast searches to every set, which defeats the point of balancing.
- Prime the index at startup so the first requests are not slow.
PDAA-001.1.09 Use the makeldif command to generate an LDIF file based on a template.
What to know:- makeldif generates synthetic LDIF from a template for testing and load generation.
- Templates define branch entries, subordinate templates, and per-attribute value generators.
- Generated data lets you test index behavior and sizing without production data.
- Use it to reproduce scale problems safely, which is its main operational value.
- Keep the template with the test plan so results are reproducible.
PDAA-001.1.10 Configure a mirrored subtree.
What to know:- A mirrored subtree is replicated in full to every server in the topology, typically for configuration or topology data.
- It uses a master election rather than multi-master conflict resolution.
- cn=topology holds server registry data as a mirrored subtree.
- Understand which data belongs here: small, rarely changing, and required consistently by all servers.
- Placing high-volume user data in a mirrored subtree is a design error.
PDAA-001.1.11 Add, initialize, and remove a server in a replication topology.
What to know:- Adding a server: install, then dsreplication enable against an existing server, then initialize it from a peer.
- Initialization copies data; enabling only establishes the replication agreement.
- Removing a server requires disabling replication so the topology forgets it, not just stopping the process.
- A server removed without being disabled leaves stale entries in the topology registry.
- Verify with dsreplication status before and after, and confirm the change on every server.
Objective 2: Basic Configuration
PDAA-001.2.01 Create, edit, and delete a schema definition.
What to know:- Schema is stored as entries under cn=schema and modified with LDAP operations or dsconfig-adjacent tooling.
- Attribute types define syntax, matching rules, and single or multi-valued behavior; object classes define required and allowed attributes.
- Custom definitions need a private OID arc and unique names to avoid collision with standard schema.
- Deleting a definition still in use will fail or orphan data; check usage first.
- Schema changes replicate, so validate on a test topology before applying in production.
PDAA-001.2.02 Create and use a sensitive attribute.
What to know:- Sensitive attributes restrict how an attribute can be accessed, updated, or returned, beyond what ACIs express.
- Options include prohibiting return in search results, requiring secure communication, and forbidding modification.
- This is a server-enforced control that applies regardless of the requester's ACI grants.
- Typical uses: national identifiers, payment data, and anything with regulatory exposure.
- Configure per client connection policy where different applications need different treatment.
PDAA-001.2.03 Create and use a virtual attribute.
What to know:- A virtual attribute is computed at request time rather than stored in the entry.
- Built-in providers cover common cases (entryDN, isMemberOf, password policy state); custom ones handle the rest.
- isMemberOf is the classic example: group membership presented from the member's perspective without duplicating data.
- Virtual attributes cost CPU per request; they are not free convenience.
- They can be indexed in some cases, but check before relying on a search filter that targets one.
PDAA-001.2.04 Create and use a JSON attribute.
What to know:- A JSON attribute stores structured JSON in a single attribute value with server-side awareness of its structure.
- The server can index and filter on fields inside the JSON object using extensible matching.
- This avoids inventing dozens of flat attributes for structured application data.
- Understand how updates work: partial modification of a JSON value has specific semantics.
- Schema still governs which entries may carry the attribute.
PDAA-001.2.05 Apply constraints to a JSON attribute.
What to know:- Constraints validate the contents of a JSON attribute so malformed or unexpected data is rejected at write time.
- You can require fields, restrict types, and prohibit unrecognized fields.
- Rejecting bad data at the directory is cheaper than discovering it in every consuming application.
- Tightening constraints on existing data can fail; audit before enforcing.
- Constraint violations surface as LDAP errors, so applications must handle them.
PDAA-001.2.06 Create, export, and import encryption settings definitions.
What to know:- Encryption settings definitions hold the keys used for data encryption at rest.
- encryption-settings is the tool to create, list, export, and import definitions.
- All servers in a topology that must read the same encrypted data need the same definition imported.
- Export the definition and store it securely and separately; losing it means losing the data.
- Rotating to a new preferred definition re-encrypts new writes; existing data is handled per the documented procedure.
PDAA-001.2.07 Use an encrypted LDIF file.
What to know:- An encrypted LDIF file protects exported data at rest, which matters because exports contain everything.
- Export with encryption enabled and the appropriate encryption settings definition.
- Import requires the same definition to be available on the target server.
- This is the correct way to move data between environments without exposing it in transit or on disk.
- Verify you can decrypt a test export before relying on the process for a real migration.
PDAA-001.2.08 Create a password validator.
What to know:- Password validators reject weak passwords at the moment they are set.
- Types include length, character set, dictionary, attribute-value (no password containing the username), repeated characters, and similarity to the previous password.
- Validators attach to a password policy; several can apply together.
- Validation runs on the clear-text password during the modify, which is why it must happen at the server.
- Test the combination, because overly strict stacked validators generate support calls rather than security.
PDAA-001.2.09 Create a password policy.
What to know:- A password policy governs expiration, lockout, history, storage scheme, and which validators apply.
- Policies can be assigned by default, by subtree, or per entry via the password policy attribute.
- Storage scheme choice matters: use a modern salted, computationally expensive scheme.
- Lockout settings trade account security against denial-of-service by deliberate lockout.
- Password policy state is inspectable per user, which is the starting point for most authentication troubleshooting.
PDAA-001.2.10 Create a log retention policy.
What to know:- A log retention policy decides when old log files are deleted, by count, size, or free disk space.
- Retention pairs with rotation: rotation creates new files, retention removes old ones.
- Disk exhaustion from logs is a classic outage; retention is the control that prevents it.
- Compliance requirements may set a minimum retention that conflicts with disk capacity; resolve explicitly.
- Different publishers can carry different retention policies.
PDAA-001.2.11 Create a log rotation policy.
What to know:- A log rotation policy decides when to start a new log file: by time, by size, or on a fixed schedule.
- Rotation makes logs manageable and enables retention to act on whole files.
- Time-based rotation aligns logs with operational windows, which helps investigation.
- Size-based rotation protects against a single enormous file during an incident.
- Policies attach per log publisher, so an access log and an error log can rotate differently.
PDAA-001.2.12 Create a basic access log publisher.
What to know:- The access log records every client operation with result codes and timing.
- Create a publisher with dsconfig, choosing the log file, rotation, and retention policies.
- Access logs are the primary evidence for both performance analysis and security investigation.
- Consider the write cost at high operation rates; asynchronous logging exists for that reason.
- summarize-access-log turns raw logs into an operational picture, which is why the format matters.
PDAA-001.2.13 Create a filtered log publisher.
What to know:- A filtered log publisher records only operations matching defined criteria.
- Filtering by result criteria or request criteria keeps a targeted log without the volume of a full access log.
- Typical uses: log only failures, only operations against a sensitive subtree, or only a specific application's connections.
- This is how you get durable evidence for one concern without paying the full logging cost.
- Confirm the criteria match what you intend by testing against known operations.
PDAA-001.2.14 Create result criteria.
What to know:- Result criteria select operations by their outcome: result code, whether entries were returned, processing time.
- They are referenced by filtered log publishers and by other server components that act on operations.
- Slow-operation criteria (processing time above a threshold) are the standard way to hunt performance problems.
- Combine with request criteria for precision.
- Criteria objects are reusable; define once and reference from multiple publishers.
PDAA-001.2.15 Create request criteria.
What to know:- Request criteria select operations by their inbound characteristics: operation type, target DN, authentication state, client address, controls used.
- They drive filtered logging, client connection policy restrictions, and other conditional behavior.
- Matching on unauthenticated operations is a common security use.
- Criteria are evaluated per operation, so keep them cheap.
- Name them descriptively, because they are referenced from several places and outlive the person who wrote them.
PDAA-001.2.16 Create a client connection policy.
What to know:- A client connection policy governs what a connection is allowed to do, based on how it connected and who it bound as.
- Policies can restrict operation types, result set size, and which subtrees are visible.
- Selection is by connection criteria evaluated at bind time.
- This is the mechanism for giving an application a constrained view without relying solely on ACIs.
- Order of policies matters; the first matching policy applies.
PDAA-001.2.17 Configure uncached entries and/or attributes.
What to know:- Uncached attributes and entries keep data out of the database cache to conserve memory for the working set.
- Large, rarely-read attributes (photos, certificates, blobs) are the usual candidates.
- The trade is memory saved against additional disk reads when that data is requested.
- Configure at the backend level with the appropriate criteria.
- Measure cache hit ratio before and after; this is a tuning decision that should be evidence-driven.
PDAA-001.2.18 Configure PingDirectoryProxy as a load balancer.
What to know:- As a load balancer, PingDirectoryProxy distributes operations across backend servers without partitioning data.
- Algorithms include failover, round-robin, fewest-operations, and health-weighted variants.
- Health checks determine backend availability and drive the algorithm's choices.
- Read operations can be spread while writes go to a preferred server, which matters in a replicated topology.
- This is the availability and throughput answer; entry balancing is the capacity answer.
PDAA-001.2.19 Configure PingDirectoryProxy to transform requested data.
What to know:- Proxy transformations rewrite requests and responses between client and backend.
- Attribute mapping and DN mapping let a client see a different namespace than the backend actually stores.
- Suppression transformations remove attributes from responses.
- Transformations are how a proxy presents a legacy-compatible view over a modernized directory.
- Every transformation costs processing per operation, so apply narrowly.
Objective 3: Troubleshooting
PDAA-001.3.01 Troubleshoot common issues.
What to know:- Start with the server status and the error log, then the access log for the specific operation.
- Reproduce with ldapsearch or ldapmodify using the same credentials and controls as the failing client.
- Isolate layer by layer: network reachability, TLS handshake, bind, then the operation itself.
- Check replication status early when behavior differs between servers.
- Collect a support data archive before restarting anything, because restarts destroy the evidence.
PDAA-001.3.02 Interpret log entries to resolve a problem.
What to know:- Access log entries carry the result code, the message, processing time, and the entries returned.
- LDAP result codes are the vocabulary: 32 no such object, 49 invalid credentials, 50 insufficient access rights, 53 unwilling to perform.
- Correlate request and response by connection and operation ID.
- Unindexed search warnings in the log identify the queries that will not scale.
- summarize-access-log aggregates this into counts and slowest operations, which is the fastest route to the problem.
PDAA-001.3.03 Use cn=monitor analysis to troubleshoot a problem.
What to know:- cn=monitor exposes server state as entries: connection counts, operation rates, cache statistics, replication status, and disk usage.
- Query it with an ordinary LDAP search, which means monitoring systems can consume it directly.
- Backend monitors show cache hit ratios; a falling ratio explains rising latency.
- Replication monitors show backlog and last-change times per server.
- Establish a baseline while healthy, because these numbers only mean something in comparison.
PDAA-001.3.04 Diagnose and resolve a configuration issue.
What to know:- Configuration problems usually surface as an operation that behaves differently than the documented default.
- dsconfig can display the effective configuration; compare against a known-good server.
- The configuration change log records what changed, by whom, and when, which usually answers the question immediately.
- Configuration is replicated in a mirrored subtree for some components; know which parts are local and which are topology-wide.
- Revert using the recorded change rather than guessing at the previous value.
PDAA-001.3.05 Diagnose and resolve a search issue.
What to know:- A search problem is almost always an index problem: check for the unindexed-search warning in the log.
- Index types matter: equality, presence, substring, ordering, and approximate each serve different filters.
- Leading-wildcard substring filters cannot use an ordinary index, which is a design problem not a tuning one.
- rebuild-index repairs or creates indexes; it is an offline or degraded-performance operation, so plan it.
- The index entry limit determines when the server stops maintaining an index for a very common value.
PDAA-001.3.06 Diagnose and resolve a schema issue.
What to know:- A schema problem appears as object class violation or undefined attribute type errors on write.
- Confirm the definition exists and is spelled exactly as used, including case-insensitive but exact naming.
- Check that required attributes of every object class on the entry are present.
- Schema replicates; a mismatch between servers produces failures that follow the client, not the data.
- Validate LDIF against the schema before a bulk import rather than discovering violations mid-load.
PDAA-001.3.07 Diagnose and resolve an ACI issue.
What to know:- An ACI problem presents as result code 50, insufficient access rights, or as data that is unexpectedly invisible.
- Remember that absent an explicit allow, access is denied; and any matching deny overrides all allows.
- Verify which ACIs apply to the target entry, including those inherited from ancestors.
- Bind rules that reference groups require the membership to be resolvable at evaluation time.
- Test as the affected identity; testing as an administrator proves nothing about the user's access.
PDAA-001.3.08 Diagnose and resolve a replication issue.
What to know:- Replication problems show as divergence between servers or as a growing backlog.
- dsreplication status is the first command; it reports missing changes per server.
- Common causes: network partition, certificate expiry on replication connections, and a server restored from backup without re-initialization.
- Re-initializing from a healthy peer is the standard repair for a diverged server.
- Confirm the topology registry reflects reality, because a stale entry for a decommissioned server produces persistent errors.
Public sources, used in good faith
These guides are independent study aids built from publicly available material: published exam blueprints, official product documentation, and vendor training catalogues. Product names, exam codes, and trademarks belong to their owners and are used only to identify the subject being taught. This site is not affiliated with or endorsed by any vendor named here. If you hold rights in material published on this page and believe it should be removed or corrected, please send the exact URL and a short note on the issue through the contact page; requests are reviewed promptly and in good faith. Read the full disclaimer →