Sample questions
Mq Appium Driver ArchitectureDifficulty 1
In Appium 2, what protocol does the Appium server primarily use to communicate with client libraries?
- aA binary protocol compiled separately for each mobile OS, with no relation to any web standard
- bA proprietary Appium-only protocol invented independently of any browser automation standard
- cA GraphQL API that clients query for driver capabilities and session state
- dThe W3C WebDriver protocol, the same HTTP/JSON-based standard used by browser automation tools✓
Explanation:Correct answer is d: the Appium server speaks the W3C WebDriver protocol, an HTTP/JSON-based standard also used by browser automation tools. a is wrong, there is no per-OS compiled binary protocol. b is wrong, the protocol is not an Appium invention, it follows the W3C standard. c is wrong, Appium does not use GraphQL for its core protocol.
Mq Appium Driver ArchitectureDifficulty 1
Which sequence best describes the layers a command passes through in a typical Appium setup?
- aClient library -> Appium server -> platform-specific driver -> device/simulator✓
- bClient library -> device/simulator -> Appium server -> platform-specific driver
- cAppium server -> client library -> device/simulator -> platform-specific driver
- dPlatform-specific driver -> client library -> Appium server -> device/simulator
Explanation:Correct answer is a: a client library sends a command to the Appium server, which hands it to the platform-specific driver (UiAutomator2, XCUITest, etc.), which then acts on the device or simulator. b reverses the client and device order incorrectly. c puts the server before the client, which is backwards. d starts from the driver, skipping the client entirely.
Mq Appium Driver ArchitectureDifficulty 1
What is the core responsibility of the Appium server process itself?
- aReceiving WebDriver HTTP commands and routing them to the session's driver✓
- bCompiling the application under test into an installable package before every session
- cRendering the mobile app's UI so testers can preview it in a desktop browser window
- dStoring historical test run results in a built-in relational database
Explanation:Correct answer is a: the Appium server's core job is to receive W3C WebDriver HTTP commands and route each one to the driver instance tied to that session. b is wrong, Appium does not compile apps. c is wrong, the server does not render UI previews. d is wrong, Appium has no built-in results database.
Mq Appium Driver ArchitectureDifficulty 1
What does a successful newSession (POST /session) request establish?
- aA permanent device registration that survives Appium server restarts
- bA session identified by a session ID that subsequent commands must reference✓
- cA direct socket connection between the client library and the mobile app's source code
- dA cached copy of the app's UI hierarchy that never needs to be re-queried again
Explanation:Correct answer is b: a successful newSession call returns a session ID, and every following command must include it so the server routes the command to the correct driver instance. a is wrong, sessions do not survive a server restart. c is wrong, there is no direct client-to-source-code socket. d is wrong, the UI hierarchy is not permanently cached at session creation.
Mq Appium Driver ArchitectureDifficulty 2
How does a client library normally end an Appium session cleanly?
- aBy closing the laptop's network connection, which the server interprets as a quit signal
- bBy sending a second newSession request with an empty capabilities object
- cBy waiting for the mobile device to reboot, which forces the server to drop the session
- dBy sending a DELETE request to the session endpoint, often called
quit()✓
Explanation:Correct answer is d: ending a session cleanly means issuing a DELETE request against the session endpoint, which most client libraries wrap as a quit() call. a is wrong, dropping the network connection is not a clean quit mechanism. b is wrong, a second newSession call starts a new session rather than closing the current one. c is wrong, a device reboot is not a normal termination path.
Mq Appium Driver ArchitectureDifficulty 1
In Appium 2, how do you make the UiAutomator2 driver available to the server before running Android tests?
- aIt is always bundled with the server, no separate step is needed in any Appium 2 version
- bYou install it explicitly as an extension, for example with
appium driver install uiautomator2✓ - cYou copy a
.driver file manually into the Android SDK's platform-tools folder - dYou set an environment variable named
APPIUM_DEFAULT_DRIVER=uiautomator2 before starting the server
Explanation:Correct answer is b: Appium 2 treats drivers as separate installable extensions, so UiAutomator2 must be added explicitly, e.g. via appium driver install uiautomator2. a is wrong, Appium 2 does not bundle drivers by default. c is wrong, there is no manual .driver file copy step into the SDK folder. d is wrong, no such environment variable governs driver availability.