Identity-and-Access-Management-Architect Free Practice Test

In a typical SSL setup involving a trusted party and trusting party, what consideration should an Architect take into account when using digital certificates?

1. A. Use of self-signed certificate leads to lower maintenance for trusted party because multiple self-signed certs need to be maintained.
2. B. Use of self-signed certificate leads to higher maintenance for trusted party because they have to act as the trusted CA
3. C. Use of self-signed certificate leads to lower maintenance for trusting party because there is no trusted CA cert to maintain.
4. D. Use of self-signed certificate leads to higher maintenance for trusting party because the cert needs to be added to their truststore.

Correct Answer: D
D is correct because using a self-signed certificate leads to higher maintenance for the trusting party, which is the client or browser that connects to the server. The trusting party needs to add the self-signed certificate to their truststore, which is a repository of trusted certificates, in order to establish a secure connection with the server. Otherwise, the trusting party will see a warning message or an error when accessing the server.
A is incorrect because using a self-signed certificate leads to higher maintenance for the trusted party, not lower. The trusted party needs to maintain multiple self-signed certificates from different servers in their truststore.
B is incorrect because using a self-signed certificate does not make the trusted party act as the trusted CA (Certificate Authority). The trusted CA is the entity that issues and validates certificates for servers. The trusted party only needs to trust the CA’s root certificate, which is usually pre-installed in their truststore.
C is incorrect because using a self-signed certificate leads to higher maintenance for the trusting party, not lower. The trusting party still needs to maintain a trusted CA cert in their truststore, which is the self-signed certificate itself.
References: 1: SSL Certificate Installation Instructions & Tutorials - DigiCert 2: How To Install an SSL Certificate from a Commercial … - DigitalOcean 3: Setup SSL CSR Creation and SSL Certificate Installatio
- DigiCert

Universal Containers is using OpenID Connect to enable a connection from their new mobile app to its production Salesforce org.
What should be done to enable the retrieval of the access token status for the OpenID Connect connection?

1. A. Query using OpenID Connect discovery endpoint.
2. B. A Leverage OpenID Connect Token Introspection.
3. C. Create a custom OAuth scope.
4. D. Enable cross-origin resource sharing (CORS) for the /services/oauth2/token endpoint.

Correct Answer: B
According to the Salesforce documentation1, OpenID Connect Token Introspection allows all OAuth connected apps to check the current state of an OAuth 2.0 access or refresh token. The resource server or connected apps send the client app’s client ID and secret to the authorization server, initiating an OAuth authorization flow. As part of this flow, the authorization server validates, or introspects, the client app’s access token. If the access token is current and valid, the client app is granted access.

Which two things should be done to ensure end users can only use single sign-on (SSO) to login in to Salesforce?
Choose 2 answers

1. A. Enable My Domain and select "Prevent login from https://login.salesforce.com".
2. B. Request Salesforce Support to enable delegated authentication.
3. C. Once SSO is enabled, users are only able to login using Salesforce credentials.
4. D. Assign user "is Single Sign-on Enabled" permission via profile or permission set.

Correct Answer: AD
To ensure end users can only use single sign-on (SSO) to log in to Salesforce, two things should be done:
Enable My Domain and select “Prevent login from https://login.salesforce.com”. My Domain is a feature that allows administrators to customize the Salesforce login URL with a unique domain name. By preventing login from the standard login URL, administrators can enforce SSO and restrict users from logging in with their Salesforce credentials.
Assign user “is Single Sign-on Enabled” permission via profile or permission set. This permission allows users to log in to Salesforce using SSO. Users who do not have this permission will not be able to access Salesforce even if they have valid Salesforce credentials. References: My Domain, User Permissions for Single Sign-On

When designing a multi-branded Customer Identity and Access Management solution on the Salesforce Platform, how should an identity architect ensure a specific brand experience in Salesforce is presented?

1. A. The Experience ID, which can be included in OAuth/Open ID flows and Security Assertion Markup Language (SAML) flows as a URL parameter.
2. B. Provide a brand picker that the end user can use to select its sub-brand when they arrive on salesforce.
3. C. Add a custom parameter to the service provider's OAuth/SAML call and implement logic on its login page to apply branding based on the parameters value.
4. D. The Audience ID, which can be set in a shared cookie.

Correct Answer: A
Configuring an authentication provider to delegate authentication to the LDAP directory ensures that users can only log in to Salesforce if they are active in the LDAP directory. This prevents terminated employees from accessing Salesforce with their old credentials. References: Authentication Providers, Delegated Authentication Single Sign-On

A group of users try to access one of Universal Containers' Connected Apps and receive the following error message: " Failed: Not approved for access." What is the most likely cause of this issue?

1. A. The Connected App settings "All users may self-authorize" is enabled.
2. B. The Salesforce Administrators have revoked the OAuth authorization.
3. C. The Users do not have the correct permission set assigned to them.
4. D. The User of High Assurance sessions are required for the Connected App.

Correct Answer: C
The underlying mechanisms that the UC Architect must ensure are part of the product are Just-in-Time (JIT) provisioning and deprovisioning. JIT provisioning is a process that creates or updates user accounts in Salesforce when users log in with SAML single sign-on (SSO)6. JIT deprovisioning is a process that disables or deletes user accounts in Salesforce when users are removed from the identity provider (IdP). Both of these processes enable automated provisioning and deprovisioning of users without requiring manual intervention or synchronization. The other options are not valid mechanisms for provisioning and deprovisioning. SOAP API is an application programming interface that allows developers to create, retrieve, update, or delete records in Salesforce. However, SOAP API does not support JIT provisioning or deprovisioning, and requires custom code to implement. Provisioning API is not a standard term for Salesforce, and there is no such API that supports both provisioning and deprovisioning.
References: Just-in-Time Provisioning for SAML, [Just-in-Time Deprovisioning], [SOAP API Developer