Application Development - 2 · Quiz 2 · Jan 2026

**1. Inspect SQL construction:** The backend inserts raw email and password strings directly into an SQL f-string. Input containing SQL syntax can alter the query structure; values should instead be passed as bound parameters. **2. Inspect password verification:** The predicate compares the supplied password directly with a stored password column, with no password-hash verification shown. This exposes plaintext-password storage/comparison in the intended example. **3. Inspect login state:** A successful response contains only a message. No session or authentication token is established, so later requests have no demonstrated proof of the successful login. All three listed issues are present. **Answer: D — All of these..** **Convention note:** This evaluates the security design illustrated by the snippet, not whether an unspecified db.execute result object has correct truthiness or whether screenshot line wrapping forms executable Python. A production handler must also fetch and verify an actual matching user row. A: **Incorrect:** The issue is real, but this single-issue option is incomplete compared with “All of these.” B: **Incorrect:** Direct plaintext comparison is a real issue, but the other two listed issues also apply. C: **Incorrect:** The snippet establishes no reusable authenticated session or token; this is one of several issues. D: **Correct:** It includes SQL injection, plaintext-password handling and the absence of established login state.

**1. Enter the action synchronously:** addTodoAsync is declared async, but it contains no await before commit. Its body immediately commits addTodo, pushing one object into state.todos. **2. Schedule the promise callback:** Returning “done” resolves the action’s promise. The .then callback runs later through the promise/microtask mechanism rather than interrupting the current script. **3. Read the current length:** The next synchronous console.log sees a list that already contains one item, so it prints 1 first. “done” prints afterward. **Answer: C — 1.** A: **Incorrect:** The mutation has already pushed an item before the synchronous length read. B: **Incorrect:** The promise continuation runs after the current synchronous code. C: **Correct:** The synchronous commit makes the length one before the .then callback executes. D: **Incorrect:** The async action and synchronous mutation are valid; no error is required.

**1. Compare initialization:** filteredProducts is computed from allProducts and the current category when read. displayedProducts instead begins as null. **2. Inspect the watcher:** The category watcher updates displayedProducts only when the watched route parameter changes. It has no immediate:true option and no separate initial population call. **3. Trace navigation:** An initial template reading displayedProducts therefore renders no product data. Navigating from electronics to books changes the parameter, triggers the watcher and assigns the filtered book list, after which data appears. **Answer: B — The initial page load would show an empty list, and only after navigation .** **Convention note:** The option says “empty list,” but the literal initial value is null, so interpolation is blank rather than a populated or actual empty-array list. A: **Incorrect:** Computed properties are dependency-cached; their mere existence does not make them universally slower. B: **Correct:** The null initial field stays empty until a later category change runs the non-immediate watcher. C: **Incorrect:** One value is derived immediately when read, while the other waits for the watcher’s first change. D: **Incorrect:** Reactive data is normal in Vue and does not itself cause a crash.

**1. Resolve the first awaited task:** task(7) takes the value>5 branch and resolves with 7+2=9. Thus a becomes nine. **2. Follow the rejection:** task(a−4) is task(5). Since 5>5 is false, it rejects with 5−2=3. await throws that rejection value into the enclosing catch. **3. Return from catch:** catch returns the number three, resolving execute() with three. The outer .then prints 3; the planned return a+b is skipped. **Answer: D — 3.** A: **Incorrect:** The normal addition path does not complete because the second task rejects. B: **Incorrect:** The rejection value is three, not ten. C: **Incorrect:** Five is the second task’s input, not its rejection value. D: **Correct:** The catch returns the rejection reason three, which the final .then prints.

**1. Match API limitations:** A chatty API may require several requests to assemble one screen, giving A→2. The listed REST query limitation concerns clients not specifying an exact custom response shape in one request, giving B→4. **2. Match rendering and architecture:** Hydration attaches client-side behavior to existing rendered HTML, giving C→1. The JAMstack description emphasizes decoupling presentation and services/storage through APIs, giving D→3. **3. Assemble the sequence:** The complete mapping is A→2, B→4, C→1, D→3. The REST statement is a comparison of conventional endpoint design, not a prohibition on implementing filtering or field selection. **Answer: A — A→2, B→4, C→1, D→3.** A: **Correct:** All four matches agree with the supplied descriptions. B: **Incorrect:** It assigns hydration’s description to REST chatiness and misplaces the other concepts. C: **Incorrect:** A and D match, but the query-limitation and hydration descriptions are swapped incorrectly. D: **Incorrect:** It exchanges the two REST limitation descriptions; A concerns multiple calls and B response/query expressiveness.

**1. Apply the mutation payload:** userId=2 selects Bob. His status changes from inactive to active; his role remains user. **2. Re-evaluate active getters:** Alice and Charlie were already active. With Bob added, activeUsers contains all three, so activeUserCount is three. **3. Re-evaluate role filtering:** adminUsers still contains only Alice because the mutation changes status rather than role. At least the active-user getters therefore change. **Answer: A — activeUserCount returns 3.** A: **Correct:** All three users are active after Bob’s update, so the active count is three. B: **Incorrect:** Only Alice has role admin; Bob’s status change does not create a second administrator. C: **Incorrect:** Bob now also satisfies the active filter and cannot be omitted. D: **Incorrect:** Both the active list and its count change as a consequence of the mutation.

**1. Locate beforeDestroy:** Vue 2 calls it immediately before instance teardown, while the instance is still functional. It is an appropriate point to remove external listeners or cancel timers. **2. Locate destroyed:** Vue calls it after teardown of the instance’s directives, listeners and child components. The instance is then destroyed. **3. Interpret normal component removal:** During ordinary conditional or router-driven removal these hooks bracket the component’s teardown. The option with beforeDestroy first and destroyed afterward is the correct ordering. **Answer: B — **beforeDestroy** runs just before the component is torn down and removed .** **Convention note:** Instance destruction and physical DOM removal are distinct. Calling $destroy() directly does not itself guarantee that the root DOM element is removed; the rendering/removal context controls that. B is selected for its correct teardown ordering in the ordinary component-removal scenario. A: **Incorrect:** It reverses the lifecycle order. B: **Correct:** It correctly places beforeDestroy before teardown and destroyed after instance destruction. C: **Incorrect:** Mounting has different hooks; beforeDestroy is not a first-mount hook. D: **Incorrect:** beforeDestroy is called before destruction, not only after it.

**1. Read the data attribute:** btn.dataset.id reads the HTML data-id attribute. The text “42” is returned as a string; DOM dataset access does not infer a numeric type. **2. Read the other attribute:** getAttribute("data-action") returns the string “delete” from the existing attribute. **3. State both values:** id is "42" and action is "delete", both strings. A number would require an explicit conversion such as Number(btn.dataset.id). **Answer: B — id = 42 (string), action = "delete" (string).** A: **Incorrect:** The value exists, but dataset returns it as a string rather than the number 42. B: **Correct:** Both APIs return the corresponding existing attribute values as strings. C: **Incorrect:** Both attributes exist and are read through appropriate accessors. D: **Incorrect:** id is not implicitly numeric, and data-action exists so action is not undefined.

**1. Identify the purpose:** A permalink is intended to be a durable address for a particular page or resource, allowing users to bookmark it or cite it. **2. Distinguish appearance from stability:** A readable URL can be a permalink, but readability alone does not make an address permanent. Session dependence or deliberate short-lived validity conflicts with the intended stable-address role. **Answer: B — A stable URL that uniquely identifies a specific resource and is not expected to .** A: **Incorrect:** A single-session temporary address is not a permanent resource identifier. B: **Correct:** A stable address intended to keep identifying the same resource is the defining idea. C: **Incorrect:** Permalinks are not limited to menu items or defined solely by readable wording. D: **Incorrect:** Dependence on a particular session or device undermines the intended durable shared address.

**1. Map the object references:** alias1 is the same object as weapon. alias2 is a shallow copy, so it has its own top-level object but shares weapon.stats. alias3 separately copies the nested stats object. **2. Apply the mutations:** alias1.name="Shield" changes weapon.name. alias2.stats.damage=99 changes the shared stats object for weapon and alias2. alias3.stats.damage=42 changes only alias3’s independent nested object. **3. Read the logs:** weapon.name is Shield; weapon.stats.damage and alias2.stats.damage are both 99; alias3.stats.damage is 42. These print as four separate console calls. **Answer: A — Lines: Shield; 99; 99; 42.** A: **Correct:** The reference alias changes the name and the shallow copy shares the damage object, while alias3 keeps separate stats. B: **Incorrect:** weapon.stats shares alias2.stats, so its damage cannot remain ten. C: **Incorrect:** alias1 references weapon directly, so changing its name changes weapon.name. D: **Incorrect:** alias3’s damage does not replace alias2’s shared damage value.

**1. Match the whole path:** The nested player route accepts /player/:name followed by an empty path, test or oneday. The extra segment t20 matches none of those complete nested routes. **2. Apply the fallback:** The top-level wildcard route matches the otherwise unmatched path and renders the test component directly in the root router-view. **3. Read the component output:** The test component displays Test Runs: 5000. Because the player route is not the matched parent route here, its Name heading is not rendered. **Answer: B — Test Runs: 5000.** **Convention note:** This uses the Vue Router 3 route table shown, with the wildcard route after the player route. It is a complete-path fallback, not a partial match retaining the player parent. A: **Incorrect:** The default oneday child only applies at the exact parent path, not at the unknown t20 segment. B: **Correct:** The wildcard fallback directly renders the test component and its 5000-run text. C: **Incorrect:** The fallback is a top-level route, so the player component’s heading is not present. D: **Incorrect:** The unknown t20 path is not an oneday route.

**1. Read the route parameter:** At /#/b, the /:alpha route supplies alpha="b". The created hook converts it to lowercase and searches each waterfall’s first letter. **2. Trace the search:** Vajrai starts v, Kunchikal starts k, Dudhsagar starts d and Bahuti starts b. The first three fail and the Rewa entry matches. **3. Read the assigned field:** The code stores the matching entry’s district, not the waterfall name. Thus result becomes “Rewa” and the paragraph renders Rewa. **Answer: C — Rewa.** A: **Incorrect:** Shivamogga’s waterfall begins with k, not b. B: **Incorrect:** South Goa’s waterfall begins with d, not b. C: **Correct:** Bahuti Falls starts with b and belongs to the Rewa entry. D: **Incorrect:** Satara’s waterfall begins with v, not b.

**1. Separate persisted data from authentication state:** localStorage survives ordinary reloads. Reading a stored token does not prove it is valid; the app waits for the validation promise before setting isAuthenticated=true. **2. Follow success and failure:** On success, the callback assigns user and enables authentication. On failure, catch removes userToken and sets the flag false, so that stored token will not trigger another automatic validation next load. **3. Consider navigation:** A client-side route change does not automatically cancel an existing promise or its callbacks. In the shown code, a later successful resolution can still assign data to the captured component instance, even if its route has changed. **Answer: B, C, E — If token validation fails, the token is removed from storage, preventing ; The **isAuthenticated** flag might be false even though a **storedToken** exists, ; If the user navigates to a different route while validation is pending, the .** **Convention note:** E describes continuation if validation resolves successfully; rejection takes the failure branch. Updating an old or destroyed component instance is not the same as updating a newly mounted view. Real applications may add cancellation, stale-request guards or cleanup, none of which is shown. A: **Incorrect:** Ordinary refresh does not clear localStorage. B: **Correct:** The failure callback explicitly removes userToken from persistent storage. C: **Correct:** A saved token can exist while the asynchronous validation is still pending and the initial authentication flag remains false. D: **Incorrect:** Persistence duration is a product/security decision; sessionStorage is not universally required by this example. E: **Correct:** Route navigation alone does not cancel the promise; its callbacks can still execute and assign instance data.

**1. Identify the event flow:** The child’s send method emits an event; the parent must listen using @event and call its updateMessage method to replace message. A prop binding with : is not an event listener. **2. Check A:** The child emits message without a payload, and the parent’s inline handler explicitly calls updateMessage("Hello"). Thus the chosen fixed text reaches the parent. **3. Check B:** The child emits message with payload "Hello". The parent method listener @message="updateMessage" receives that payload as its argument. Both approaches set the same parent data. **Answer: A, B — A and B — fixed inline argument or emitted payload.** A: **Correct:** The matching event triggers an inline handler that explicitly passes Hello, so a child payload is unnecessary. B: **Correct:** The matching method listener receives the Hello event payload and assigns it to message. C: **Incorrect:** The colon binds a prop rather than registering the message event listener. D: **Incorrect:** The parent expression message is not the updateMessage method and does not assign the desired Hello value.

**1. Evaluate the initial condition:** isVisible begins false. v-if omits the Hello paragraph, while v-show keeps the World paragraph but sets it to display:none. Neither text is initially visible. **2. Follow one click:** toggle changes false to true. Vue inserts the v-if paragraph and restores display of the v-show paragraph, so both texts appear after the update. **3. Distinguish the mechanisms:** v-if controls conditional creation/removal; v-show controls CSS display of a retained element. The last two statements swap those mechanisms. **Answer: A, B, C — On initial page load, neither “Hello” nor “World” is visible in the browser.; On initial page load, the element using v-show exists in the DOM but is hidden.; After clicking the Toggle button once, both “Hello” and “World” become visible..** A: **Correct:** With a false initial condition, neither paragraph’s text is visible. B: **Correct:** v-show retains its element and hides it using display:none. C: **Correct:** One toggle sets the shared condition true and shows both paragraphs. D: **Incorrect:** v-if conditionally renders/removes its branch rather than merely applying hiding CSS. E: **Incorrect:** v-show retains the element in the DOM instead of removing it.