Free Practice Questions for IT Specialist INF-306 Exam

Determine requirements → Develop code → Test the app

↓

Monitor performance ← Deploy the app

The correct application lifecycle sequence begins with Determine requirements because the team must first define what the app must accomplish, who will use it, and which functional and technical expectations must be satisfied. Since the question states that the design is already provided, the next implementation step is Develop code, where the HTML, CSS, JavaScript, assets, APIs, and app logic are created according to the approved design and requirements. After development, the app must be validated through Test the app. Testing confirms that the app works correctly, meets requirements, handles user input properly, and does not contain functional defects that would block release. Once testing is complete, the app can be released through Deploy the app, which publishes it to the target environment or makes it available to users. The final operational stage is Monitor performance, where the released app is observed, maintained, updated, and improved based on performance, reliability, defects, and user behavior. References/topics: application lifecycle management, requirements, development, testing, deployment, maintenance.

First box: minlength

Second box: maxlength

Third box: required

The correct validation attributes are minlength, maxlength, and required. The input must accept a category abbreviation that is either two or three characters long. The minlength= " 2 " attribute enforces the lower boundary by preventing submission when the entered text contains fewer than two characters. The maxlength= " 3 " attribute enforces the upper boundary by preventing the user from entering more than three characters into the field. Since the question states that the input is mandatory, the required attribute must also be included. required is a Boolean validation attribute, so it does not need a value; its presence alone makes the field required before the form can be submitted. Together, these attributes configure basic HTML5 constraint validation directly in markup without requiring JavaScript. The completed input therefore requires a value, rejects values shorter than two characters, and limits the value to no more than three characters. References/topics: HTML5 form validation, minlength, maxlength, required, text input constraints, mandatory form fields.

Club Points indicator → < meter >

Order Status group title → < legend >

Choose delivery frequency options → < datalist >

Shipping Information group box → < fieldset >

Displayed shipping information → < output >

The correct semantic elements are selected according to the role each visible form component performs. The Club Points visual indicator represents a scalar measurement within a known range, so it corresponds to < meter > . The bordered Order Status section is a grouped form region, and the caption displayed on the border is a < legend > , which labels a fieldset-style group. The delivery frequency control shows an editable input with selectable predefined values, which is the purpose of < datalist > : it supplies suggested options for an associated input without forcing the user to choose only from the list. The Shipping Information section is visually and semantically a grouped set of related form information, so the surrounding grouping element is < fieldset > . The displayed shipping address is generated or presented as result-style information rather than typed directly in that location, which matches < output > . fieldset groups related controls, legend labels that group, meter displays a bounded measurement, datalist provides input suggestions, and output displays calculated or resulting information.

The correct segment is D because named grid-region layouts are defined with grid-template-areas. This CSS Grid property specifies named grid areas, establishes the cells in the grid, and assigns names to those cells. The syntax requires each row of the grid template to be written as a quoted string, with repeated names indicating that the named area spans multiple columns or rows. In the shown layout, heading spans the entire top row, menu occupies the left column across lower rows, content spans the central area, right occupies the right-side area, and contact spans the bottom content region. Options B and C are incorrect because named grid-area strings do not belong in grid-template-rows or grid-template-columns; those properties define track sizing, not named layout regions. Option A defines explicit column and row sizes but does not define the semantic named areas shown in the mockup. References/topics: CSS Grid, grid containers, named grid areas, grid-template-areas, responsive page layout.

First drop-down: flex boxes

Second drop-down: background-size

Third drop-down: cover

The correct layout mechanism is responsive flex boxes because the content changes from a vertical mobile arrangement to a wider multi-column layout as space becomes available. Flexbox supports this behavior naturally through flexible item sizing and wrapping, often without needing explicit media queries for every screen size. The header image must fill its visible header region on both mobile and desktop. The correct CSS property for controlling how a background image scales inside its container is background-size. The correct value is cover, because background-size: cover scales the image so that the entire container is covered while preserving the image’s aspect ratio. This prevents distortion, although some cropping can occur when the image and container have different aspect ratios. contain would preserve the full image but may leave empty space. auto would use the image’s intrinsic size and would not reliably fill the header area. background-attachment, background-clip, and background-repeat do not control image scaling.

First drop-down: datalist

Second drop-down: vehicles

Third drop-down: < /datalist >

The correct element is < datalist > because the interface requires a text input that provides selectable suggestions while still allowing the user to type. The < input > element uses list= " vehicles " , so it must be connected to a < datalist > element whose id is exactly vehicles. The id cannot be vehicle, because vehicle is already the input element’s own identifier and does not match the value used by the list attribute. The < option > elements inside the datalist define the suggested values: Motorcycle, Truck, Boat, Car, and Bicycle. ul, ol, and li are list-markup elements and do not create input suggestions. select would create a fixed dropdown list, but it would not match the editable input-with-suggestions behavior shown. The closing tag must match the opening datalist element, so the final selection is < /datalist > .

The correct features are saving temporary authentication tokens and passing form data to a confirmation page. sessionStorage provides a storage area scoped to the current origin and browser tab, and its data is retained only for the duration of the page session. That makes it appropriate for short-lived application state that must survive page reloads or navigation within the same workflow, but should not remain permanently available after the session ends. Passing form data from an entry page to a confirmation page is a classic session-scoped use case because the data is needed briefly during a multi-page transaction. Temporary authentication tokens can also fit the session-storage model when the token should be tied to the active browser session rather than persisted across future visits. Customized UI/UX settings usually need to persist across sessions, so localStorage or server-side user preferences are more appropriate. Game progress saved for future use is also persistent state, not session-only state. Passing data to a function is ordinary JavaScript memory usage and does not require Web Storage. References/topics: application state management, Web Storage API, sessionStorage, temporary workflow data, session-scoped tokens.

==========

The correct markup uses the HTML5 < datalist > element because the interface shows a text input with a drop-down list of suggested values. The < input > element has list= " vehicles " , which means it must be connected to a < datalist > whose id value is exactly vehicles. This relationship is essential: the list attribute on the input references the id of the datalist that supplies the available options. Each < option > element inside the datalist defines one suggested value: Motorcycle, Truck, Boat, Car, and Bicycle. Unlike a traditional < select > element, a datalist does not restrict the user only to the listed choices; the user can either select an option with the mouse or type directly into the input field. That behavior matches the displayed interface, where the control appears as an editable text box with suggestions. The final closing tag must be < /datalist > because the option elements belong to the datalist container. References/topics: HTML5 forms, < input list > , < datalist > , option elements, selectable typed input.

The correct markup is option D. The type= " tel " input type is appropriate for telephone-number entry, but it does not automatically validate a specific telephone-number format because phone formats vary internationally. MDN notes that tel inputs allow telephone entry but are not automatically validated to a particular format. Therefore, a pattern attribute is required to enforce the exact structure. The regular expression [0-9]{3}-[0-9] {3}-[0-9]{4} requires three digits, a hyphen, three digits, another hyphen, and four digits, matching the requested format such as 111-444-7777. MDN defines the pattern attribute as a regular expression the input value must match for constraint validation. The required attribute is also necessary because the field must not be empty; MDN states that required indicates the user must specify a value before the form can be submitted. Option A only limits length. Option B lacks hyphen validation and required. Option C hard-codes only specific digits. References/topics: HTML5 validation, tel, pattern, required, regular expressions.

==========

The correct methods are setItem(), removeItem(), and clear(). The HTML5 Web Storage API exposes localStorage as a persistent key-value storage object for the current origin. Data stored in localStorage remains available after page reloads and browser restarts unless it is explicitly removed or cleared. setItem(key, value) stores a value under a named key or updates the value if the key already exists. removeItem(key) deletes one specific key-value pair from storage. clear() removes all key-value pairs from the storage object for that origin. These methods are part of the standard Storage interface used by both localStorage and sessionStorage. write is not a Web Storage method; it is associated with document-writing behavior, not application state storage. cookie is also incorrect because cookies are a separate browser storage mechanism accessed through document.cookie, not a method of localStorage. References/topics: Web Storage API, localStorage, Storage interface, application state, persistent key-value data.

==========