Identity And Access Management Architecture practice questions

Encryption algorithm mismatch

Why it fails: This would lead to a failure to decrypt the assertion, preventing the process from reaching the 403 stage.

Expired metadata

Why it fails: Expired metadata prevents the initial establishment of trust between the Identity Provider and the Service Provider, causing a failure during the handshake or discovery phase rather than the assertion consumption phase. While administrators often check metadata validity when troubleshooting federation connectivity, this error typically manifests as a failure to retrieve the signing certificate or endpoint URLs. If the assertion consumption phase is reached, the trust relationship is already active, meaning the issue lies within the assertion content itself, such as an invalid audience restriction or nameID format.

Assertion Consumer Service (ACS) URL mismatch

Why it fails: This typically results in a 400 Bad Request or a failure to post the assertion.

Zscaler Client Connector

Why it fails: Zscaler Client Connector resides on the endpoint and acts as the initial forwarding agent that captures traffic, but it does not perform the actual brokering or interception of the connection between the user and the application. This component is tempting because it is the mandatory software required to initiate the ZTNA tunnel from the device. It would be the correct answer if the question asked which component establishes the secure tunnel from the user’s machine to the Zscaler cloud.

Zscaler Cloud Broker

Why it fails: The broker facilitates the handshake between the user session and the app connector.

Zscaler Central Authority

Why it fails: The Zscaler Central Authority functions as the management plane, orchestrating policy distribution and configuration updates across the architecture rather than handling data plane traffic. It serves as the control hub for authenticating administrative changes and synchronising security policies globally. While it is essential for initialising the environment, it does not participate in the actual interception or brokering of application-layer sessions. That specific data plane responsibility belongs exclusively to the App Connector and the Zscaler Private Service Edge.

Clients authenticate to the DB via Vault using LDAP delegation.

Why it fails: LDAP delegation merely facilitates identity propagation rather than generating ephemeral credentials, failing to provide the time-limited, unique database roles required for a dynamic secrets architecture. This approach is typically utilised for centralised authentication when integrating legacy applications with Microsoft Entra ID or traditional directory services. It serves as a valid mechanism for managing user access control and single sign-on workflows, but it does not perform the automated credential lifecycle management or just-in-time privilege escalation inherent to Vault’s dynamic secrets engine.

Vault retrieves static credentials from a PKI backend and rotates them.

Why it fails: PKI backends manage X.509 certificates rather than database credentials, meaning they lack the logic required to execute `CREATE USER` or `GRANT` statements on a database engine. While this approach effectively automates the lifecycle of digital identities for mutual TLS authentication, it fails to provide the just-in-time, ephemeral database access requested. Developers often confuse these mechanisms because both involve automated rotation; however, PKI is designed for identity verification and encryption, whereas the Database Secrets Engine specifically handles the generation of unique, time-limited SQL user accounts.

Vault hashes existing database passwords and stores them in transit.

Why it fails: Vault does not act as a password vault for existing static credentials in this architecture.

RADIUS

Why it fails: Remote Authentication Dial-In User Service is a network access protocol designed to handle AAA (Authentication, Authorisation, and Accounting) functions for dial-up, virtual private network, and 802.1X switch connections, meaning it fails to broker SAML or OIDC assertions for web-based federation between an Identity Provider and a cloud Service Provider. It would be the correct choice when network administrators need to centrally manage dial-in or switch-port access credentials through an enterprise directory, but it lacks the capability to exchange rich user identity and attribute claims over HTTP/HTTPS for modern web applications.

SCIM

Why it fails: System for Cross-domain Identity Management (SCIM) satisfies the standardisation constraint of the stem by providing a RESTful protocol designed specifically to automate provisioning and update workflows for user identities between an Identity Provider and a Service Provider. Unlike authentication frameworks that merely verify credentials, SCIM utilises JSON-formatted HTTP requests to manage the complete lifecycle of user and group data across disparate cloud domains, ensuring interoperability without relying on proprietary vendor APIs.

LDAP

Why it fails: Directory services rely on the Lightweight Directory Access Protocol primarily for querying and managing hierarchical user records within a private domain, failing to provide the federated web-based token exchange required across separate security domains. It is tempting because administrators frequently deploy it as a central repository for user credentials and directory attributes, making it the correct choice for internal directory lookups and intranet authentication within a traditional enterprise network.

It requires the client secret to be stored on the client side.

Why it fails: The Implicit Grant flow is specifically designed to function without a client secret, as it targets public clients like browser-based applications that cannot securely store credentials. Requiring a client secret is a feature of the Authorisation Code flow, which is intended for confidential clients capable of protecting sensitive data on a server. Therefore, the Implicit Grant does not involve storing secrets on the client side, making this statement technically inaccurate regarding the fundamental design of the protocol flow described in the scenario.

It relies on symmetric encryption for all token exchanges.

Why it fails: Symmetric encryption is not the mechanism used in the Implicit Grant flow, which relies on URI fragment transmission rather than cryptographic key exchange. This option is tempting because symmetric encryption is a standard method for securing data at rest or protecting internal service-to-service communication within a private network. In architectures where two trusted endpoints share a pre-established secret, symmetric encryption provides efficient confidentiality, but it does not address the specific browser-based redirection vulnerabilities inherent in the Implicit Grant flow.

It does not support refresh tokens, limiting usability.

Why it fails: While the lack of refresh tokens represents a functional limitation, it is not the primary security vulnerability defining the Implicit Grant flow. Developers often favour this flow for single-page applications because it avoids cross-origin resource sharing complexities by returning tokens directly in the URI. However, this design choice exposes access tokens to browser history and referer headers, creating a significant risk of interception. Microsoft Entra ID and other modern identity providers now mandate the Authorization Code flow with PKCE to mitigate these specific exfiltration vectors.

Effect: Deny

Why it fails: Using a deny effect for this IP restriction would block the user entirely because explicit denies override all allows in AWS Identity and Access Management evaluation logic, preventing access regardless of source. This option appears tempting because deny rules are routinely used to enforce security perimeters and boundary controls. It would be the correct choice if the objective were to explicitly prohibit access from untrusted external networks while allowing access from everywhere else, rather than conditionally granting access based on a specific source IP range.

Resource: *

Why it fails: Restricting access to list S3 buckets globally across the entire AWS partition requires setting the resource to `*` because the `ListAllMyBuckets` API action cannot be scoped to an individual bucket ARN. Therefore, while this wildcard element is actually necessary to satisfy the API's global structural requirements for the listing operation, it fails to address the condition logic on its own. It is tempting because administrators frequently rely on it when troubleshooting broad service-level permissions, but it lacks the contextual source IP evaluation needed to enforce the network perimeter specified in the prompt.

Action: s3:ListBucket

Why it fails: Granting the `s3:ListBucket` action is necessary for retrieving bucket metadata at the regional level, but it fails to address the conditional source IP constraint specified in the prompt. This permission is tempting because listing objects and buckets is the foundational prerequisite for any Amazon S3 enumeration task, and it would be the correct choice if the objective were solely to authorise read-only bucket discovery without evaluating network location parameters. Restricting access by IP address requires a `Condition` block utilising the `aws:SourceIp` key rather than merely declaring the action.

Incompatible authentication protocols.

Why it fails: Privileged Access Management vaults focus on credential obfuscation and session isolation rather than protocol translation. While this option addresses interoperability challenges, it pertains to identity federation or gateway services such as Microsoft Entra ID Application Proxy, which facilitate communication between legacy systems and modern authentication standards. A vault secures existing credentials against unauthorised exposure or lateral movement, whereas protocol incompatibility requires an intermediary service to perform token transformation or translation between disparate authentication frameworks.

Network latency during authentication.

Why it fails: Introducing a Privileged Access Management vault introduces an intermediary cryptographic and authorisation check that typically increases, rather than decreases, network latency during authentication. System administrators often find this distractor tempting because vaults handle high-volume credential retrieval and session brokering, leading to the misconception that centralising authentication traffic inherently accelerates network paths. Such a mechanism would be the correct choice in a scenario specifically focused on mitigating credential theft or enforcing session recording, but it fails here because it exacerbates rather than resolves latency bottlenecks.

Lack of granular auditing of privileged actions.

Why it fails: A Privileged Access Management vault actively enforces session recording, keystroke logging, and command-line restriction capabilities that directly deliver granular auditing of privileged actions. This makes the distractor tempting because vault solutions natively capture detailed telemetry regarding who accessed a resource and what commands they executed. Therefore, it would be the correct choice if the scenario specifically targeted comprehensive activity monitoring and forensic accountability for administrative tasks, rather than addressing the credential management and session isolation risks highlighted in the correct answers.

The requirement for the same OS on all servers.

Why it fails: Federated identity relies on trust relationships and protocols like SAML or OIDC to authenticate users across distinct security domains without sharing credentials, rendering underlying server operating systems completely irrelevant to the standard. Administrators often conflate cross-domain trust architectures with platform standardisation requirements needed for centralised domain controllers like Microsoft Active Directory. Such homogenous platform mandates would apply if an enterprise enforced a single operating system to simplify local group policy administration or uniform patch management within a single forest, rather than establishing identity federation across heterogeneous systems.

The use of a shared local database on each server.

Why it fails: Synchronising local account databases across independent servers creates isolated credential silos rather than achieving cross-domain single sign-on, which violates the architectural goal of centralising authentication across separate security domains. This approach would be tempting for legacy workgroups requiring simple peer-to-peer access control, where independent Windows servers rely on locally managed Security Accounts Manager databases to authenticate administrators locally without requiring an external directory service.

Public IP address matching.

Why it fails: Public IP address matching operates at the network layer to restrict access based on geographic location or specific network perimeters, failing to achieve Federated Identity because it cannot securely propagate user authentication assertions and identity attributes across disparate trust domains. It often appears attractive because perimeter defences frequently rely on source IP verification to control enterprise resource access, which would be the correct choice when attempting to enforce static network-level boundary restrictions rather than single sign-on across independent security domains.

Storing the code in a public client's local storage.

Why it fails: Storing an authorisation code in browser local storage exposes sensitive credentials to cross-site scripting attacks, as any malicious script running on the page can access the data. While developers often utilise local storage to persist user session state or non-sensitive application settings across page refreshes, it lacks the isolation required for OAuth 2.0 tokens. In environments where an application must maintain state for legitimate client-side operations, such as caching UI preferences or non-authenticated user data, local storage provides a functional mechanism for persistent data retrieval.

Sending the code in the URL fragment of a redirect.

Why it fails: Transmitting the authorisation code via a URL fragment violates the OAuth 2.0 specification, as fragments are processed strictly by the user agent and are never sent to the server, preventing the client from exchanging the code for an access token. This approach is intended for the OAuth 2.0 Implicit Flow, where the access token itself is returned directly in the fragment to avoid server-side handling. While this mechanism facilitates client-side token retrieval in legacy browser-based applications, it fails to support the secure code-exchange process required here.

Set a short expiration time for the client_secret

Why it fails: Confusing client secrets with authorization code security fails because public mobile apps cannot securely store secrets, making secret longevity irrelevant to interception risks; instead, administrators use short expiration times to mitigate the impact of credential leakage and limit the window of exposure for compromised confidential client credentials in backend-to-backend communication.

Require signed JWTs for the request object

Why it fails: Signed JWTs for request objects secure the integrity and authenticity of the authorisation request itself, preventing parameter tampering during the initial redirect. While this enhances overall message security, it does not mitigate authorisation code injection, which requires PKCE to bind the code to the specific client instance. This configuration is instead the correct choice when an architect needs to enforce non-repudiation and prevent request object manipulation in high-assurance environments, such as those integrated with Microsoft Entra ID for OpenID Connect flows.

Implement Mutual TLS (mTLS) for the token endpoint

Why it fails: Implementing Mutual TLS (mTLS) for the token endpoint secures credential transmission by binding the client certificate to the TLS layer, which effectively prevents token theft and replay attacks at the transport boundary. This countermeasure is tempting because it hardens the token exchange against interception. However, it is designed for sender-constrained token validation rather than client registration controls, failing to prevent authorization code injection where a malicious app intercepts and replays the code during the front-channel redirect.

To manage user identities in the directory.

Why it fails: Managing user identities falls under the remit of a Policy Administrator or identity provider such as Microsoft Entra ID, where directory services authenticate users and provision credentials. This option is tempting because authentication is a foundational prerequisite for any access control framework, making directory management a central component of overall security operations. However, this administrative function handles lifecycle management rather than evaluating contextual trust signals and access criteria in real-time, which is the distinct operational responsibility of the Policy Decision Point.

To log all access attempts for compliance.

Why it fails: A PDP evaluates access requests against policy and returns permit or deny decisions; logging is the Policy Enforcement Point's or a separate audit function's job. Logging alone cannot authorise or block anything. A PDP is the correct component when the requirement is centralised, dynamic authorisation decisions.

To intercept and inspect network packets.

Why it fails: Packet inspection is a function performed by a Policy Enforcement Point (PEP) or a Next-Generation Firewall rather than a Policy Decision Point (PDP). Intercepting and inspecting network traffic is tempting because firewalls actively police network perimeters in traditional security models. Such a mechanism WOULD be the correct choice for a PEP, which acts upon the authorisation verdict rendered by the PDP to permit or deny data flows, but it misidentifies the centralised logical brain responsible for evaluating access policies.

CyberArk AIM (Application Identity Manager)

Why it fails: CyberArk AIM facilitates programmatic credential retrieval for non-human identities, such as scripts or applications, rather than providing remote session isolation for human end-users. While it effectively secures hardcoded passwords within automated workflows, it lacks the session proxy capabilities required to intercept and mask credentials from a human operator's workstation. This feature is the standard solution when developers must eliminate embedded credentials from source code or configuration files, but it does not address the requirement for secure human access to administrative interfaces.

CyberArk EPM (Endpoint Privilege Manager)

Why it fails: CyberArk EPM focuses on local privilege elevation and application control on endpoints rather than the secure brokering of remote credentials. It is a common distractor because administrators often deploy it to restrict local administrative rights, which is a related component of a broader privileged access strategy. However, EPM does not provide the credential vaulting or transparent session proxying required to prevent the exposure of privileged credentials to the workstation, which is the specific functional requirement defined in the question stem.

CyberArk Vault Agent

Why it fails: CyberArk Vault Agent operates as a local service to synchronise password policies or manage local accounts on endpoints, but it does not proxy sessions or mask credentials from the end-user. It is a valid component when you need to enforce local password rotation or manage offline access on managed workstations. However, it fails the requirement to prevent credential exposure because it does not provide the transparent session brokering or credential injection capabilities inherent to the Privileged Session Manager.

IAM User Inline Policies

Why it fails: IAM User inline policies rely on long-term credentials tied to individual IAM users rather than the federated, short-lived session tokens generated by AWS IAM Identity Center. While these policies offer precise permission boundaries for legacy workloads requiring static access keys, they bypass the centralised identity lifecycle management mandated by the prompt. They remain useful for standalone accounts where programmatic access requires specific, non-reusable permissions that do not integrate with external identity providers like Microsoft Entra ID.

Cross-account IAM Roles

Why it fails: Relying on traditional cross-account IAM roles bypasses the centralised permission sets managed within AWS IAM Identity Center, leading to fragmented credential management and an inability to enforce federated session policies uniformly across accounts. While this method is tempting because it represents the legacy architectural standard for granting temporary cross-account privileges, it belongs in scenarios where workloads lack an Identity Center integration or require programmatic assumption via long-lived trust policies rather than ephemeral, human-centric SSO workflows.

IAM User Access Keys

Why it fails: Long-lived IAM user access keys are static credentials tied to an IAM user, not temporary elevated access scoped to one account. Permission sets with session duration and assignment provide that granularity. Access keys suit programmatic workloads needing persistent credentials, not short-term developer elevation.

iss

Why it fails: The `iss` claim identifies the issuer of the ID Token and verifies the trust relationship between the client and the identity provider, such as Microsoft Entra ID. While validating this claim is essential for ensuring the token originated from a trusted source, it does not contain unique, time-bound data to detect or prevent the reuse of captured tokens. Developers often include this check to establish initial authenticity, yet it remains insufficient for mitigating replay attacks, which require nonce or timestamp validation.

iat

Why it fails: iat records when the ID Token was issued and is not checked against a stored nonce, so a captured token remains replayable within its lifetime. It is tempting because it bounds token age, but replay prevention requires validating the nonce claim against the value bound to the user's session.

sub

Why it fails: The `sub` claim provides a unique, immutable identifier for the user within the issuer's domain, but it remains static across different sessions and does not contain temporal data to detect replayed requests. Developers often gravitate toward this claim when they need to verify user identity or map accounts within a database. While essential for establishing session context or user authorisation in Microsoft Entra ID, it lacks the cryptographic freshness required to mitigate replay attacks, which necessitates validating claims like `nonce` or `iat`.

Require password change

Why it fails: Requiring a password change addresses credential compromise rather than device state, failing to verify the device's compliance or management status as mandated by the policy requirements. This setting is tempting because it serves as a security control for identity protection, specifically when Microsoft Entra ID detects leaked credentials or suspicious sign-in activity. In such scenarios, forcing a password reset mitigates the risk of unauthorised access by compromised accounts, but it provides no mechanism to validate the hardware or software integrity of the endpoint.

Require approved client app

Why it fails: Requiring an approved client app validates that the user is accessing Microsoft Entra ID resources through specific, managed applications like Outlook or Teams, rather than verifying the device's compliance state with Intune. This setting is intended for scenarios where organisations implement Mobile Application Management (MAM) to protect corporate data within applications on personal devices. It fails to satisfy the requirement for device compliance, which specifically necessitates the "Require device to be marked as compliant" grant control to enforce hardware-level security posture.

Require hybrid Microsoft Entra ID joined device

Why it fails: Requiring a hybrid Microsoft Entra ID joined device confirms domain membership rather than validating the current security posture or health state of the endpoint. While this control effectively enforces corporate ownership for legacy on-premises synchronised environments, it fails to verify device compliance status as defined by Microsoft Intune policies. This option is tempting because it restricts access to managed hardware, yet it lacks the specific integration with device health attestation required to ensure the system meets the organisation's security configuration standards.

PKCE (Proof Key for Code Exchange)

Why it fails: Proof Key for Code Exchange fails to mitigate token theft because it secures the authorisation code exchange phase against interception rather than binding an issued access token to a specific client instance at the transport layer. It is tempting because it prevents authorization code injection attacks, making it the correct choice for public clients such as single-page applications or mobile apps where the client secret cannot be securely stored during the initial OAuth 2.0 grant flow.

Refresh Token Rotation

Why it fails: Refresh token rotation issues a new refresh token on each use and invalidates the old one, detecting replay but not binding a token to a device. Token binding cryptographically ties the token to a client instance, which is the actual requirement here.

MFA step-up

Why it fails: Multi-factor authentication step-up is tempting because it verifies user identity during high-risk sessions and is typically employed to challenge users when anomalous behaviour is detected. However, it fails in this scenario because it validates the user rather than cryptographically binding an issued security token to a specific client instance, leaving bearer tokens vulnerable to replay attacks if intercepted.

In the Identity Provider's database.

Why it fails: Storing private keys centrally within an Identity Provider's database violates the core decentralized architecture of FIDO2 and WebAuthn, which mandates that cryptographic key pairs are generated and held exclusively on the user's authenticator hardware. Centralised storage would recreate the vulnerability of traditional password repositories, exposing millions of credentials to a single server-side compromise. This centralised approach is tempting because it mirrors traditional credential management models, such as standard directory services or legacy federated identity databases like Microsoft Entra ID, where administrative control and password hashes reside server-side for centralised recovery and auditing.

In the browser's encrypted cache.

Why it fails: FIDO2 private keys are bound to dedicated cryptographic hardware modules—such as a Trusted Platform Module (TPM) or security key—rather than transient browser storage, ensuring the credential cannot be extracted or synchronised via web cache mechanisms. This is tempting because modern web browsers frequently cache encrypted session data, cookies, and tokens to persist user authentication states across sessions. In scenarios involving standard cookie-based session management or credential autofill features, storing encrypted authentication artefacts within the browser cache is the correct operational mechanism for maintaining continuous web application access without requiring repeated logins.

In the server-side hardware security module (HSM).

Why it fails: Storing the private key on a server-side hardware security module violates the core decentralized architecture of FIDO2 and WebAuthn, which requires the private credential to remain exclusively on the user's authenticator device to prevent remote server compromise. Server-side HSMs are actually designed for centralized enterprise key management, cryptographic signing, and public-key infrastructure operations, and they would be the correct choice when protecting private keys for server-side TLS termination, certificate authorities, or centralized enterprise identity provider tokens.

All users should have read access to the root directory.

Why it fails: Granting all users read access to the root directory directly violates the Principle of Least Privilege by exposing sensitive system configurations and unrelated data to identities that require no such visibility to perform their designated tasks. This broad access model is typically employed in public knowledge bases, open-source repositories, or shared staging environments where frictionless information retrieval for all participants is the primary operational requirement.

Administrators should have full control over all cloud resources.

Why it fails: Granting administrators full control over all cloud resources directly violates the Principle of Least Privilege by assigning excessive permissions far beyond what operational tasks require, thereby unnecessarily expanding the potential blast radius if credentials are compromised. This approach mirrors the traditional broad-scope permissions typically configured for root or break-glass accounts, which are necessary solely for initial provisioning, disaster recovery, or emergency platform administration, but it fails when applied as a standard operational policy for daily administrative duties.

Roles should be static and never changed to ensure stability.

Why it fails: Static IAM roles fail to satisfy the Principle of Least Privilege because cloud environments require dynamic, time-bound permission adjustments to accommodate automated workloads and changing business needs. Conversely, this approach is tempting because freezing configurations eliminates drift and accidental privilege escalation, making it the correct choice for legacy, monolithic enterprise applications where operational stability outweighs dynamic security adaptation and access patterns remain strictly immutable over years.

To eliminate the need for an identity provider.

Why it fails: Just-in-Time (JIT) access grants elevated privileges strictly on-demand and for a time-limited duration to enforce the principle of least privilege, meaning it relies entirely on an existing identity provider to authenticate users before granting temporary permissions. Eliminating an identity provider would destroy centralized authentication and lifecycle management altogether. This distractor appears plausible because JIT mechanisms heavily automate user provisioning workflows, which can superficially resemble the decoupled deployment models used when adopting lightweight directory services or migrating away from legacy, on-premises directory infrastructure.

To increase user productivity by removing MFA requirements.

Why it fails: Removing multi-factor authentication creates a dangerous security vulnerability that completely undermines zero trust architecture, regardless of how short-lived the resulting session might be. Such an approach would be tempting if the primary design goal were to streamline user workflows by reducing authentication friction during daily operations, which is a common objective when deploying passwordless authentication methods or single sign-on solutions in low-risk environments. However, Just-in-Time access specifically targets privilege elevation rather than authentication strength, functioning by granting temporary administrative rights only upon explicit request, which mandates robust identity verification such as multi-factor authentication to ensure the requester is legitimately authorised before elevation occurs.

To automate user provisioning and deprovisioning.

Why it fails: Automated user provisioning and deprovisioning targets the complete lifecycle management of digital identities—such as synchronising user accounts and access rights across disparate systems via protocols like SCIM—whereas Just-in-Time access specifically controls the temporary elevation of privileges. This option is tempting because both concepts automate identity workflows to minimise standing permissions; however, provisioning handles persistent account creation and role assignment over time, rather than enforcing dynamic, time-bound privilege elevation for specific administrative tasks.

The SP must utilize LDAP over SSL for the assertion.

Why it fails: LDAP over SSL facilitates direct directory service queries, whereas IdP-initiated SSO relies on the exchange of SAML assertions via the user agent. This option is misleading because LDAP is frequently utilised for internal user authentication or synchronisation tasks within an enterprise environment, such as connecting an on-premises application to Microsoft Entra ID Domain Services. However, it lacks the capability to process the browser-based redirection and token validation required for a federated SSO flow, which necessitates an assertion consumer service endpoint.

The SP must redirect the user to the IdP login page.

Why it fails: Redirecting the user to the IdP login page describes a Service Provider-initiated flow, where the SP detects an unauthenticated session and triggers the authentication request. In an IdP-initiated flow, the SP must instead be configured to consume a pre-generated SAML assertion delivered via an HTTP POST binding from the IdP. This option is tempting because it accurately reflects the standard redirection mechanism used by Microsoft Entra ID when a user accesses a protected application directly without an existing session token.

The SP must poll the IdP for a login event.

Why it fails: Polling mechanisms violate the fundamental push-based nature of IdP-initiated SSO, where the IdP proactively transmits a SAML assertion directly to the Service Provider’s Assertion Consumer Service endpoint. While polling is a valid architectural pattern for asynchronous back-channel synchronisation or SCIM-based provisioning tasks within environments like Microsoft Entra ID, it introduces unnecessary latency and overhead for authentication flows. Relying on a pull-based request for a login event fails to process the unsolicited assertion required to establish a session immediately upon the user's arrival.