access

one property each. Required = Yes means no record can be saved without a name — it's a save-time check, not a typing-time restriction, so Access blocks the save action itself rather than preventing you from leaving the field empty while editing. Reducing Field Size may warn about possible data loss if a name is longer than 40, which you accept, because Field Size is a hard character limit: Access checks existing data against the new, smaller limit and flags anything that would be truncated, but the warning doesn't stop you from applying the change — it's informational, confirming you understand the risk.

each element is a mark: an input mask is a character-by-character template, so each symbol in it independently controls one position of the typed value, which is exactly why a five-character mask like >LLL\-0000 is worth five marks rather than one. L not ? because L makes a letter compulsory — a required mask character blocks the record from being saved if that position is left blank, where an optional one (?) would silently allow it. 0 not 9 or # because those make digits optional, so "exactly four" would fail: with an optional digit character, a user could type only two or three digits and the save would still succeed, defeating the "exactly four" requirement. The dash is escaped with a backslash because Annexure A shows - is a separator that depends on regional settings, and \ forces the true character — without escaping it, Access might substitute whatever the system's actual separator character is, which isn't guaranteed to be a plain dash on every machine. Using > enforces uppercase by converting every character typed after it, rather than merely validating that uppercase was used.

marks for lookup/combo box type, correct source table, correct column. A Lookup field doesn't just restrict typing to a list — it replaces free-text entry with a controlled, consistent set of values pulled live from another table, which is the whole reason it's used here instead of a plain Short Text field with a validation rule. If tblSectors has an ID and a name and Sector stores the name, bind to the name column, otherwise Sector would be filled with numbers: a lookup's underlying stored value is whichever column you bind it to, so binding to the ID column by mistake would store meaningless numeric codes in a field meant to hold readable sector names, even though the dropdown itself might still display the names correctly.

marks for lower limit, upper limit, joining them with And (not Or, which accepts everything), and a clear message — each boundary of the range is an independently checkable condition. Joining two bounds with Or rather than And is a classic logic trap: "value >= 5000 Or value <= 50000" is true for almost any number (every number is either above 5000 or below 50000, or both), so the rule would accept values it was supposed to reject. Type numbers without spaces in the rule — Access parses the Validation Rule as an expression, and an unexpected space can break how it's tokenised. Between 5000 And 50000 is also correct, since it's Access's built-in shorthand for exactly the same two-sided range check. The message must tell the user what is wrong, so "Error" is not meaningful: Validation Text exists specifically to explain which rule was broken and what's expected instead, which a generic word doesn't do.

new field with sensible name (1), Calculated type (1), correct expression hours × rate (1) — three separately checkable parts of setting up one calculated field. Total cost = quantity × price per unit is the general-purpose formula behind this specific case (hours mentored × rate per hour), the same multiplication pattern used anywhere a total is quantity times unit price. A calculated field stores the formula, not a frozen result, so it updates whenever hours or rate changes, which is the "standardising the cost model" idea in the scenario: every start-up's mentorship cost is computed by the same rule, consistently, rather than by separately typed numbers that could drift out of sync with the real hours/rate data. Square brackets around field names are essential, because Access uses them to distinguish "a reference to this field" from plain text that happens to share the field's name.

the form's own Picture property is the background, not a picture control inserted on top — these are two different mechanisms that can look identical once finished but are fundamentally different objects: a background Picture is a property of the form itself (always behind every control, resizing with the form), while an inserted picture control is a separate object sitting at a specific position, which could end up covering other controls. Marks: selecting the form (so the property is for the form and not a control) and correct picture. Picture Type Embedded is fine, since embedding simply stores a copy of the image data inside the database file rather than linking to an external file path, which is the more reliable default for a file that needs to work on any machine.

a label holds static text — unlike a text box (which is normally bound to a field and shows data that changes per record), a label's content is fixed, which is exactly the right control for something that should read the same on every view of the form, like your own name. It must be in the Form Footer, not the Detail or Header, to earn the mark, because a form's sections each repeat (or don't) differently: Detail repeats once per record, Form Header/Footer each appear exactly once — placing a label in Detail would make it look like it's repeating per record, when the instruction specifically asks for the bottom of the form.

the label and text box are different control types, so each needs its own matching — Format Painter copies a bundle of formatting from whichever control type you copied from to whichever you paste it onto, and a label's properties (its own font, size, colour, border) are tracked completely separately from its paired text box's properties, even though visually they sit right next to each other. Marks: label matches, text box matches, and overall consistency. If the odd one has a different font or size, comparing property sheets side by side finds the difference quickly, since the Property Sheet lists every formatting value explicitly rather than relying on judging it by eye.

criteria on the same row are joined by AND; separate rows are OR — this is the single rule that makes or breaks every multi-condition Access query, and the one this particular question is built to test directly. The question needs Female AND (FinTech OR EdTech) AND after 2021: a condition with an AND/OR mix like this can't be expressed with only one row, since a single row only ever produces an AND of everything on it. If you split FinTech and EdTech over two rows you must repeat the other two criteria on both rows, otherwise the OR row would accept non-female or older start-ups — leaving gender or year blank on the second row doesn't mean "same as the row above," it means "no restriction at all" for that row, silently widening the results. "After 2021" is >2021, not >=, because "after" a year explicitly excludes that year itself — >=2021 would wrongly include start-ups founded in exactly 2021. Marks: gender criterion, sector OR, year criterion, sort, save — five separately checkable pieces of one query.

grouping by Township gives one row per township, and Sum adds the grants in each group — the Totals row turns the query from a plain list of individual records into an aggregated summary, where Group By collapses every matching record into one output row and any Sum/Count/Avg column recalculates within that collapsed group rather than across the whole table. Remove other fields that would break the grouping into smaller pieces: an extra field left in the query (say, StartupName) would force Access to group by the combination of Township and that extra field, producing one row per unique pair instead of the single row per township the question actually asks for.

marks for the field name Eligible followed by a colon, IIf, the test [PitchScore]>=75, "Yes" for true and blank "" for false — each syntax element is independently checkable, the same way an Excel formula's pieces are marked individually. IIf is Access's IF with three parts (test, true result, false result): the exact query-grid equivalent of Excel's IF(test, value_if_true, value_if_false), just under a different name because Access reserves the bare word "If" as a programming keyword elsewhere in the application. Do not write "No" or "False" because the question asks for blank — an empty string "" and the word "No" are different values entirely; a check comparing the field's contents for genuinely blank would fail against either literal word.

marks: grouping changed to Sector, a count function, placed in the group footer — three distinct report-design changes. A footer-level function calculates per group; the same expression in the report footer would count every mentor in total, because a group footer's scope is exactly the records inside that one group (it resets as each new group begins), while the report footer's scope is the entire report from start to finish — identical expression, completely different result, purely because of which section it's placed in. =Count([MentorName]) is equally valid: Count(*) counts every record in the group regardless of content, while Count([FieldName]) counts only records where that specific field isn't blank — for a group of mentor records where the name field is always filled in, both give the same answer.