← All study guides
PFAA-001
Certified Expert - PingFederate
Part of Certified Expert - PingFederate
Each voucher code is valid for a single exam attempt only; once redeemed it cannot be reused. Exam covers PingFederate version 11 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
PFAA-001.1.01 Configure attribute mappings from an external data store with failover.
What to know:- Failover on a data store means a second source is queried when the first is unreachable.
- Configure multiple LDAP hostnames on the data store so the connection itself fails over.
- Failover addresses availability of the source, not missing data within a reachable source.
- Test by taking the primary offline, not by reasoning about the configuration.
- Connection timeouts must be short enough that failover happens faster than the user gives up.
PFAA-001.1.02 Configure attribute mappings from an external data store with failsafe mappings.
What to know:- Failsafe mapping supplies a default value when the lookup succeeds but returns nothing.
- This is the distinction the exam draws: failover is about the source being down, failsafe is about the attribute being absent.
- Without a failsafe, a missing attribute can fail the whole SSO transaction.
- Choose defaults that are safe if they reach the service provider, since they will.
- Log when the failsafe fires, or silent defaults hide a data-quality problem.
PFAA-001.1.03 Configure attribute mappings from an external data store using OGNL.
What to know:- OGNL expressions compute attribute values from data-store results and other context.
- Expressions can concatenate, conditionally select, and transform values during mapping.
- Enable expressions explicitly; they are disabled by default because they are powerful.
- Keep expressions short and testable; complex logic belongs in the data source or an adapter.
- An expression that throws will fail the transaction, so handle null cases deliberately.
PFAA-001.1.04 Create custom attributes using OGNL.
What to know:- Custom attributes are contract entries populated by expression rather than by direct lookup.
- Extend the attribute contract first, then fulfil the new attribute with an OGNL expression.
- Typical uses: deriving a role string, normalizing case, or combining given and family names.
- The service provider only receives what the contract carries, so contract and expression must agree.
- Test with representative data including the awkward cases, not just a clean sample user.
PFAA-001.1.05 Customize the HTML Form Adapter.
What to know:- The HTML Form Adapter renders the username and password login page.
- Customization uses the template files in the server's template directory, with localization files for text.
- Branding changes belong in templates and CSS; behavior changes belong in adapter configuration.
- Template changes must be replicated to every node in a cluster.
- Keep customizations minimal and documented, because they must be reapplied at upgrade.
PFAA-001.1.06 Self-service password reset.
What to know:- Self-service password reset lets users set a new password without an administrator.
- Configuration is on the HTML Form Adapter and requires a password credential validator that supports writes.
- Verification method matters: email one-time link, one-time password, or challenge questions each have different security properties.
- Rate limiting and account-enumeration protection belong in the design; a reset flow that reveals whether an account exists is a finding.
- The directory account used by PingFederate needs the rights to change passwords.
PFAA-001.1.07 Self-service account recovery.
What to know:- Account recovery unlocks or restores access after lockout, distinct from resetting a known-bad password.
- It uses the same verification mechanisms as password reset and the same enumeration concerns.
- Coordinate with the directory's lockout policy so recovery actually clears the lock.
- Audit recovery events specifically; they are a common target for social engineering.
- Decide whether recovery requires stronger verification than reset, and justify the choice.
PFAA-001.1.08 Self-service username recovery.
What to know:- Username recovery tells a user which username is associated with a verified identifier such as an email address.
- This is the highest enumeration risk of the three self-service flows, so responses should be uniform regardless of whether the account exists.
- Delivery should go to the registered channel, never displayed on screen.
- Some organizations disable this entirely; that is a legitimate design decision.
- Rate limit aggressively and log every attempt.
PFAA-001.1.09 Advanced use of authentication policies.
What to know:- Authentication policies are a decision tree over adapters and selectors, evaluated per request.
- Selectors branch on context: network range, requested authentication context, client, or attribute values.
- Policy contracts carry attributes out of the tree to the connection, decoupling the tree from the target.
- Advanced use includes step-up authentication, where a branch requires a second factor before reaching success.
- Draw the tree before building it; policies are hard to read in the console once they grow.
PFAA-001.1.10 Local identity profiles.
What to know:- Local identity profiles support registration and profile management for users PingFederate itself manages.
- They define the fields collected, the data store where they are written, and the associated templates.
- Registration, profile update, and email verification are the common flows.
- This is for use cases without an existing enterprise directory of these users, typically customer identity.
- Field validation and required-attribute handling belong in the profile definition.
PFAA-001.1.11 SP Target URL Mapping.
What to know:- SP target URL mapping decides where the user lands at the service provider after SSO.
- It maps a requested target to an allowed destination, rather than trusting an arbitrary supplied URL.
- This is an open-redirect control as much as a usability feature.
- Wildcards must be scoped carefully so they cannot match an attacker-controlled host.
- Coordinate with the service provider on the exact URLs their application uses.
PFAA-001.1.12 Configure Redirect Validation.
What to know:- Redirect validation restricts the URLs PingFederate will redirect a browser to after authentication or logout.
- Configure allowed target resources for SSO and for SLO separately.
- Without it, a crafted target parameter turns the identity provider into an open redirector, which is a phishing amplifier.
- Validation should match on scheme and host, not merely on a substring.
- Test with a deliberately hostile value to confirm the rejection path works.
PFAA-001.1.13 Using RelayState to request a specific resource.
What to know:- RelayState carries application state through the SAML exchange so the user returns to the resource they requested.
- The identity provider echoes it back; it is opaque to the protocol.
- Because it is attacker-influenceable, it must be validated against redirect-validation rules before use.
- Size limits apply; large state should be stored server-side with a reference in RelayState.
- Understand the difference between RelayState and the target parameter of an IdP-initiated URL.
PFAA-001.1.14 Configure certificate revocation checking.
What to know:- Revocation checking confirms a presented certificate has not been revoked, via CRL or OCSP.
- OCSP gives fresher answers; CRLs are simpler but can be large and stale.
- Decide the failure behavior when the revocation source is unreachable: fail open or fail closed, each with consequences.
- Network access to the CRL distribution point or OCSP responder must exist from the PingFederate host.
- Cache settings trade freshness against latency and load on the responder.
PFAA-001.1.15 Configure certificate rotation for self-signed certificates.
What to know:- Self-signed certificates in PingFederate can be rotated so a new certificate is published before the old one stops being used.
- The rotation creates a successor certificate that appears in metadata, letting partners pick it up in advance.
- Partners consuming metadata automatically will follow; partners with pinned certificates need manual coordination.
- Plan rotation before expiry, not at it; a signing certificate that expires breaks every federation at once.
- Verify each partner has accepted the new key before activating it.
Objective 2: SSO IdP/SP Configuration
PFAA-001.2.01 Create custom URLs using single sign-on (SSO) endpoint variables
What to know:- SSO endpoint variables let a single startSSO URL serve multiple targets by parameter.
- Common parameters: PartnerSpId, TargetResource, and IdP adapter selection.
- Custom URLs simplify bookmarking and application integration without a connection per target.
- Every parameter that influences redirection must be covered by redirect validation.
- Document the URL format for application teams, since malformed URLs are a frequent support issue.
PFAA-001.2.02 Configure identity provider to service provider (IdP-to-SP) bridging
What to know:- IdP-to-SP bridging makes PingFederate act as a service provider to an upstream identity provider and as an identity provider to a downstream service provider.
- This is the federation hub pattern: many upstream identity sources, many downstream applications, one translation point.
- Attribute mapping happens twice, and the contract must carry attributes through both hops.
- Authentication policies decide which upstream identity provider handles a given request.
- Bridging concentrates trust, so the hub's own security and availability become critical.
PFAA-001.2.03 Configure session cookies
What to know:- Session cookies represent the authenticated session at PingFederate itself.
- Configure timeouts, whether the session is tracked, and the scope of the cookie.
- Authentication sessions can be stored so re-authentication is not required across applications.
- Cookie attributes (Secure, HttpOnly, SameSite) must be set appropriately for the deployment.
- Session behavior interacts with single logout; understand what a logout actually terminates.
Objective 3: OAuth/OIDC Configuration
PFAA-001.3.01 Configure dynamic client registration
What to know:- Dynamic client registration lets OAuth clients register themselves at runtime rather than being created by an administrator.
- Access to the registration endpoint must be controlled, typically by an initial access token, or anyone can create clients.
- Client registration policies constrain what a self-registering client may request.
- Registered clients receive credentials and a registration access token for later management.
- This is essential at scale and dangerous when unrestricted; the policy configuration is the control.
PFAA-001.3.02 Configure an external DB for persistent grants
What to know:- Persistent grants record a user's consent and refresh-token state, and must survive restarts.
- An external database gives durability and shared visibility across a cluster.
- Schema is supplied by PingFederate; the database account needs the documented rights.
- Grant lifetime and cleanup of expired grants are operational settings with storage consequences.
- Without external storage, grants are limited in ways that break refresh-token behavior at scale.
Objective 4: Clustering
PFAA-001.4.01 Configure an adaptive cluster
What to know:- An adaptive cluster distributes runtime state dynamically among engine nodes without dedicated state servers.
- Nodes discover each other and share state, which simplifies deployment.
- It suits deployments where all engines are equivalent and network conditions between them are good.
- Understand the rebalancing behavior when a node joins or leaves.
- Compare against the directed model before choosing; the trade is simplicity versus explicit control.
PFAA-001.4.02 Configure dedicated state servers in a directed cluster
What to know:- In a directed cluster, specific nodes are designated as state servers holding runtime state for the others.
- Engines are configured with the state servers they use, making the topology explicit.
- This gives predictable placement, which matters across latency boundaries.
- State server failure has a defined impact that must be understood and tested.
- Sizing the state servers is a separate capacity exercise from sizing the engines.
PFAA-001.4.03 Configure sub-clusters in a directed cluster
What to know:- Sub-clusters group nodes, typically by data centre or region, so state is shared within a group rather than globally.
- This limits cross-site chatter and keeps latency-sensitive state local.
- Requests must be steered so a user's session stays within the sub-cluster that holds its state.
- Cross-sub-cluster failover behavior is a design decision with a user-visible consequence: re-authentication.
- Configuration must be consistent across every node or the grouping silently misbehaves.
PFAA-001.4.04 Configure cluster runtime state-management services
What to know:- Runtime state management covers sessions, grants, and other data that must be consistent across nodes.
- Services are configured per state type, so different data can use different strategies.
- Some state can be regenerated (re-authenticate) and some cannot (consent); treat them differently.
- Monitor replication of state, not just node liveness.
- Test node loss deliberately and observe what users experience.
Objective 5: Troubleshooting
PFAA-001.5.01 Interpret the contents of individual log files
What to know:- Key logs: server.log for runtime and errors, transaction and audit logs for per-request detail, admin logs for configuration changes.
- The audit log records the SSO transaction with identity, connection, and result, which is the first place to look for a failed login.
- Correlate across logs using the tracking or transaction identifier.
- Timestamps must be synchronized across cluster nodes or correlation is impossible.
- Know which log answers which question before an incident, not during one.
PFAA-001.5.02 Change logging levels
What to know:- Logging levels are set in log4j2.xml, per logger, and can be changed for a specific component rather than globally.
- DEBUG on the right package is far more useful than DEBUG everywhere, which buries the signal and hurts performance.
- Some changes require a restart while others are picked up on the configured monitor interval.
- Raise the level, reproduce, capture, and lower it again as a disciplined loop.
- Never leave verbose logging on in production; it can log sensitive data.
PFAA-001.5.03 Configure log file rotation using log4j2.xml
What to know:- Rotation is configured with log4j2 appenders using time-based or size-based triggering policies.
- A rollover strategy sets how many archived files are kept.
- Rotation prevents a single unbounded file and makes archival practical.
- Align rotation with your log-shipping cadence so files are complete when collected.
- Confirm disk capacity accounts for the retained set, not just the active file.
PFAA-001.5.04 Configure custom log listeners using log4j2.xml
What to know:- Custom appenders in log4j2.xml can direct specific loggers to their own files or to remote destinations.
- Syslog and socket appenders push logs to central collection without a separate agent.
- Filters let one appender receive only the events that matter, keeping targeted logs small.
- Pattern layouts control the format, which downstream parsers depend on; changing it breaks them.
- Validate the configuration on one node before rolling it across the cluster.
PFAA-001.5.05 Configure database logging
What to know:- Database logging writes audit records to a relational database instead of, or alongside, files.
- It requires a JDBC data store and the schema PingFederate supplies.
- Querying audit data becomes practical, which is why compliance teams ask for it.
- Database availability now affects logging; understand the behavior when the database is unreachable.
- Retention and archival of the audit table is an operational responsibility that files handled implicitly.
Objective 6: Basic Configuration
PFAA-001.6.01 Configure an HTML Form Adapter
What to know:- The HTML Form Adapter authenticates users with a username and password against a password credential validator.
- Configuration covers the validator, session behavior, and which self-service features are exposed.
- The adapter contract defines which attributes it makes available to policies and connections.
- Challenge and lockout behavior come from the validator and the underlying directory, not the adapter alone.
- This is the default interactive adapter and the base for most authentication policies.
PFAA-001.6.02 Customize the HTML Form Adapter
What to know:- Customization means editing the velocity templates and the localization property files.
- Files live in the server template directory and must be identical on every cluster node.
- Separate branding (CSS, images) from logic; logic in templates is hard to maintain across upgrades.
- Keep a record of every customized file, because upgrades ship new defaults that must be merged.
- Test the customized page for accessibility and for correct behavior on error, not just the happy path.
PFAA-001.6.03 Configure an HTTP Basic Adapter
What to know:- The HTTP Basic Adapter authenticates using the browser's basic authentication prompt.
- It is simple and unbranded, which makes it suitable for service or test scenarios rather than user-facing login.
- Credentials are sent on every request, so TLS is mandatory.
- There is no logout mechanism for basic authentication, which is a real limitation.
- It still uses a password credential validator, so the backing directory configuration is the same.
PFAA-001.6.04 Configure a Kerberos Adapter
What to know:- The Kerberos Adapter provides desktop single sign-on for domain-joined machines.
- It requires a service account and keytab in Active Directory, plus a correct service principal name.
- Browsers must be configured to trust the PingFederate hostname for integrated authentication.
- Clock skew between the domain controller and PingFederate breaks Kerberos; time synchronization is mandatory.
- Provide a fallback adapter for machines that cannot use Kerberos, or remote users are locked out.
PFAA-001.6.05 Configure an OpenToken Adapter
What to know:- The OpenToken Adapter exchanges identity with an application using a shared-secret encrypted token.
- It is an agentless integration where the application uses an OpenToken agent library.
- Shared secret, transport (cookie or query parameter), and token lifetime are the key settings.
- Both sides must agree on the cipher suite and the attribute names carried in the token.
- It is a legacy integration pattern; prefer standards-based options where the application supports them.
PFAA-001.6.06 Configure a One-Time Passcode Adapter
What to know:- The One-Time Passcode Adapter delivers a code out of band, typically by email or SMS.
- It is used as a second factor in an authentication policy, after a primary adapter.
- Configure the delivery channel, code length, expiry, and retry limits.
- The user's contact attribute must be retrievable, so the data store mapping is part of the setup.
- Delivery failures are the operational risk; monitor them and provide an alternative factor.
PFAA-001.6.07 Configure a RefID Adapter
What to know:- The RefID Adapter passes a reference identifier rather than the identity itself, which the partner resolves separately.
- It suits integrations where attributes must not travel in the token.
- The reference must be resolvable by the receiving side within its validity window.
- Understand the lifetime and single-use characteristics of the reference.
- This is a privacy-preserving pattern: the token carries a pointer, not the data.
PFAA-001.6.08 Configure an X509 Adapter
What to know:- The X509 Adapter authenticates using a client certificate presented during the TLS handshake.
- The connector must request or require client certificates, and the issuing CA must be trusted.
- Attributes are extracted from the certificate subject or SAN and mapped into the contract.
- Revocation checking should be enabled, or a revoked certificate still authenticates.
- This is strong authentication tied to a device or a smartcard rather than to knowledge.
PFAA-001.6.09 Configure a Composite Adapter
What to know:- The Composite Adapter chains several adapters so multiple factors are collected in one adapter instance.
- Each chained adapter contributes attributes; the composite contract exposes the combination.
- Ordering matters, and the policy of which adapters are required versus optional is part of the configuration.
- Authentication policies can express similar logic; the composite is simpler for a fixed chain.
- Test the failure of each member adapter to confirm the overall behavior is what you intended.
PFAA-001.6.10 Configure attribute mappings from an external data store
What to know:- Data store mapping enriches the identity with attributes fetched at authentication time.
- Configure the data store, the search filter or query, and the mapping into contract attributes.
- The search filter is the critical piece: it must uniquely identify the user, and it must be indexed at the directory.
- Failed lookups and empty results are different failure modes; handle both.
- Every mapped attribute costs a lookup, so retrieve what is needed and no more.
PFAA-001.6.11 Create custom attributes using OGNL
What to know:- OGNL expressions in fulfilment produce values that are not directly present in the source.
- They must be explicitly enabled in configuration before they can be used.
- Common patterns: conditional defaults, string manipulation, and joining values from multiple sources.
- Expressions execute per transaction, so keep them cheap and null-safe.
- Validate against real data, because a null in production will throw where the test data did not.
PFAA-001.6.12 Configure an SP/IdP SAML connection using the POST binding
What to know:- A SAML connection using POST binding sends the assertion in a form auto-submitted by the browser.
- Configuration requires the partner entity ID, ACS URL, signing certificate, and the attribute contract.
- POST binding suits large assertions; redirect binding is size-limited by URL length.
- Assertion signing and optional encryption are configured per connection and must match partner expectations.
- Metadata exchange is the reliable way to get these values right rather than transcribing them.
PFAA-001.6.13 Configure an SP/IdP connection using OpenID Connect (OIDC)
What to know:- An OIDC connection uses OAuth flows with an ID token instead of a SAML assertion.
- The relying party is registered as an OAuth client with redirect URIs and allowed grant types.
- OIDC policies determine what claims land in the ID token.
- Scopes control which claims the client may request, and the policy fulfils them.
- Discovery metadata lets clients configure themselves from the well-known endpoint.
PFAA-001.6.14 Configure an SP/IdP connection utilizing multiple ACS endpoints
What to know:- Multiple ACS endpoints let one connection serve several service-provider environments or indexes.
- The assertion consumer service index or explicit URL in the request selects the endpoint.
- A default endpoint applies when none is specified.
- Each endpoint must be validated to prevent assertions being posted to an unintended location.
- This is how a single connection supports development, test, and production URLs where the partner requires it.
PFAA-001.6.15 Create custom URLs using SSO endpoint variables
What to know:- Endpoint variables in a startSSO URL select the partner, the target resource, and the adapter to use.
- This enables deep linking from a portal into a specific application through the identity provider.
- All target values must satisfy redirect validation.
- Encode parameter values correctly, since unencoded characters are a common cause of failures.
- Publish the canonical URL format to application owners rather than letting each team invent one.
PFAA-001.6.16 Create OAuth clients
What to know:- An OAuth client is defined by client ID, authentication method, allowed grant types, redirect URIs, and scopes.
- Client authentication options include shared secret, mutual TLS, and private key JWT; prefer the stronger options for confidential clients.
- Public clients (SPAs, native apps) must use authorization code with PKCE and cannot hold a secret.
- Redirect URIs must be exact-matched; wildcards here are an open-redirect and token-theft risk.
- Scope restrictions on the client limit what it can ever request, independent of user consent.
PFAA-001.6.17 Configure persistent grant settings
What to know:- Persistent grants store the user's authorization so it need not be re-consented on every request.
- Settings cover grant lifetime, idle timeout, and whether grants are reusable across clients.
- Persistent grants underpin refresh tokens; without them refresh cannot survive a restart.
- Grant storage may be local or in an external database for cluster durability.
- Provide a revocation path, because a persistent grant is standing authorization until removed.
PFAA-001.6.18 Configure common scopes
What to know:- Common scopes are available to any client that requests them, subject to the client's own restrictions.
- They form the shared vocabulary of the authorization server.
- Each scope should map to a meaningful capability, not to an implementation detail.
- Descriptions matter because they appear on the consent screen the user reads.
- Keep the common set small; proliferation makes consent meaningless.
PFAA-001.6.19 Configure exclusive scopes
What to know:- Exclusive scopes are restricted so only explicitly permitted clients may request them.
- Use them for privileged capabilities that must never be granted to a general client.
- The client configuration must list the exclusive scope for the request to succeed.
- This is the mechanism for separating administrative APIs from ordinary ones at the authorization server.
- Audit which clients hold exclusive scopes as a periodic review.
PFAA-001.6.20 Configure internally referenced access tokens
What to know:- Internally referenced access tokens are opaque strings; the resource server calls introspection to learn their meaning.
- Revocation is immediate because every validation consults the authorization server.
- The cost is a network round trip per validation, mitigated by caching at the resource server.
- Token contents never leave the authorization server, which is a privacy advantage.
- Choose this when revocation immediacy outweighs latency.
PFAA-001.6.21 Configure JWT access tokens
What to know:- JWT access tokens are self-contained and validated locally against the signing key.
- The resource server must verify signature, issuer, audience, and expiry, and reject anything failing.
- Revocation is the weakness: a valid JWT remains valid until it expires, so lifetimes should be short.
- Access token management instances define the claims, signing algorithm, and lifetime.
- Publish keys via JWKS so resource servers can rotate without manual coordination.
PFAA-001.6.22 Configure attribute mapping for ROPC grant type
What to know:- The resource owner password credentials grant sends the user's password to the client, which is why it is deprecated.
- Attribute mapping for ROPC has no browser interaction, so attributes come from the validator and data stores directly.
- Where legacy systems still require it, restrict it to specific trusted clients.
- The RFC 9700 security best practice is explicit that ROPC should not be used; document the migration plan.
- Treat any ROPC client as a high-value credential-handling component.
PFAA-001.6.23 Configure attribute mapping for all other grant types
What to know:- Other grant types (authorization code, client credentials, device, token exchange) each have their own attribute-mapping configuration.
- Client credentials has no user, so the mapping draws from the client rather than an authenticated person.
- Authorization code maps from the authentication session and any data stores.
- The mapping determines what the access token carries, which is what the resource server will authorize on.
- Map only what the resource server needs; extra claims are unnecessary exposure and token bloat.
PFAA-001.6.24 Configure refresh tokens
What to know:- Refresh tokens let a client obtain a new access token without user interaction.
- Configuration covers whether refresh tokens are issued, their lifetime, and whether they rotate on use.
- Rotation with reuse detection is the recommended posture for public clients: a replayed token invalidates the chain.
- Refresh tokens depend on persistent grants, so grant storage and lifetime govern them.
- A long-lived refresh token is a long-lived credential and should be protected accordingly.
PFAA-001.6.25 Configure OIDC policies
What to know:- OIDC policies define which attributes become claims in the ID token and at the userinfo endpoint.
- A policy is bound to clients and can differ per client, so different applications receive different claims.
- Attribute sources and OGNL fulfilment work the same way as in SAML connections.
- Include only necessary claims; the ID token is visible to the client and often logged by it.
- The policy is where the identity contract with the application is actually defined.
PFAA-001.6.26 Configure OIDC attribute scopes
What to know:- Attribute scopes bind claims to requested scopes, so a client receives extra claims only when it asks and is permitted.
- This implements data minimization: the profile scope yields profile claims, and nothing more by default.
- The mapping between scope and claim set is configured in the OIDC policy.
- Consent screens should reflect what each scope actually reveals.
- Review the scope-to-claim mapping when adding claims, or data leaks through an existing scope.
PFAA-001.6.27 Configure an external LDAP database
What to know:- An external LDAP data store is configured with connection URLs, bind credentials, and connection pooling settings.
- Use LDAPS or StartTLS; the bind credential travels on every connection.
- The service account should have only the read rights it needs, plus write rights only if self-service requires them.
- Connection pool sizing and timeouts materially affect authentication latency under load.
- Multiple hostnames give failover; test it rather than assuming.
PFAA-001.6.28 Manage certificates
What to know:- Certificate management covers signing certificates, SSL server certificates, and trusted partner certificates.
- Signing certificates appear in metadata and must be rotated with partner coordination.
- SSL server certificates protect the runtime and admin ports and are separate from signing keys.
- Import partner certificates into the correct trust context; a certificate in the wrong store does nothing.
- Track expiry for every certificate in the deployment; expiry is the most common federation outage.
PFAA-001.6.29 Manage certificate authorities (CAs)
What to know:- Certificate authorities in the trust store determine which partner and backend certificates are accepted.
- Importing a CA trusts everything it issues, so the trust store should be curated rather than filled with defaults.
- Separate trust anchors for different purposes where the product allows it.
- Intermediate certificates must be present for chain validation to succeed.
- Review the trust store periodically; an unnecessary CA is unnecessary risk.
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 →