PDAA-001
Certified Expert - PingDirectory
Parte de 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.
Material de estudo independente, construído a partir do blueprint público da prova. Sem afiliação, autorização ou endosso da ping. Os objetivos são transcritos e mapeados à mão, então esta página pode conter erros ou estar defasada em relação ao material atual do fabricante: objetivos, versões, numeração e disponibilidade mudam sem aviso. Trate o portal de certificação da própria ping como a fonte da verdade e confira nele antes de agendar qualquer coisa.
Objective 1: Advanced Configuration
PDAA-001.1.01 Create and/or manage an ACI.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
O que saber:- 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.
Fontes públicas, usadas de boa-fé
Estes guias são materiais de estudo independentes, montados a partir de conteúdo publicamente disponível: blueprints de exame publicados, documentação oficial de produto e catálogos de treinamento dos fabricantes. Nomes de produtos, códigos de exame e marcas pertencem a seus titulares e são usados apenas para identificar o assunto ensinado. Este site não é afiliado a nenhum fabricante aqui citado nem endossado por ele. Se você detém direitos sobre material publicado nesta página e entende que ele deve ser removido ou corrigido, envie a URL exata e uma breve nota sobre o problema pela página de contato; os pedidos são analisados com rapidez e boa-fé. Ler o aviso legal completo →