Qorionix Certified Multi-Tenant Engineer — exam blueprint

Sample items

Published with their answers and their rationale, which is unusual and deliberate: the samples are how a candidate or an employer judges whether the blueprint is honest. Every item here is held to one rule — if it could be answered by somebody who had memorised the navigation, it is a screenshot rather than a question, and it has been rewritten.

1. Item 1Diagnostics

   A customer's technical contact reports that a detection rule she needs for her insurer's questionnaire will not turn on — the platform refuses to set it active. She has the module, her role has every relevant permission, and two other rules she enabled the same morning worked. She wants you to escalate it to the vendor as a bug. What do you establish first, and what are the three possible outcomes?

   Model answer

   Establish which fields that rule depends on and whether her tenant's ingested events populate them; the platform refuses to mark a rule active when its required fields are unpopulated, which is correct behaviour rather than a defect. Three outcomes: a log source she has not enabled, which you fix; a licence limitation preventing the source from emitting the field, which is a purchasing decision; or a field that nothing in the platform currently writes as an event, which no configuration can resolve and which belongs in her coverage register.

   Why, and what the wrong answers get wrong

   The stem eliminates the two causes a technician reaches for first — entitlement and permission — and the detail that two other rules enabled fine eliminates a general fault. What is left is rule-specific, and the rule-specific gate is field population. The third outcome is the one that distinguishes a certified technician: recognising the category that cannot be fixed, saying so immediately, and converting it into a documented gap rather than an open ticket. Escalating this to us is the failing answer and it is what will happen without this lesson.

   The judgement being assessed

   Whether the candidate reasons from what the stem excludes, and whether they can tell a customer that the correct outcome is a documented limitation rather than a fix.

2. Item 2Portfolio operations

   Monday review across twenty-two tenants. Twenty-one look normal. Tenant 14 has produced no alerts for nine days, where its previous average was four a day. Its sensors all report healthy, its posture score is unchanged, and the customer has not called. Rank the three most likely causes and say which you check first.

   Model answer

   Most likely: ingestion stopped for one or more sources while the sensors continued to report healthy — the same shape as a source accepted-and-discarded, or a credential expiry on a pulled source. Second: something changed in the tenant's configuration, most plausibly a tuning change or a suppression somebody applied nine days ago. Third, and least likely, genuinely nothing happened. Check ingestion first, by searching for any event from each source in the last twenty-four hours; nine days of silence following a four-a-day average is a data-availability signal, not a security signal.

   Why, and what the wrong answers get wrong

   Healthy sensors and an unchanged posture score are both consistent with total telemetry loss, which is exactly why they are in the stem. The customer not calling is a distractor: a customer would not notice fewer alerts and would experience silence as an improvement. The candidate must also get the ordering right — a configuration change is worth checking but it is cheaper and faster to establish whether data is arriving at all, and the audit trail will answer the configuration question afterwards. Answering 'a quiet nine days' fails; so does escalating without establishing whether data arrived.

   The judgement being assessed

   Whether the candidate treats an absence of alerts as a hypothesis to disprove rather than a result, and whether they order diagnostics by cost.

3. Item 3The tenancy model

   Your practice is about to take on its twenty-fourth customer. A senior engineer proposes creating one shared 'MSP operations' identity in every customer tenant, so that any of your six technicians can work in any tenant without managing twenty-four sets of credentials each. It solves a real problem. Give your answer and the alternative.

   Model answer

   No. It destroys actor attribution in the audit trail, which is the thing the customer is paying for and the first thing an auditor asks about — every action in twenty-four tenants would be attributed to a role rather than to a person, and after an incident you could not establish who did what. The alternative is per-technician accounts per tenant with a naming convention and a credential manager, which is genuinely more work and is the cost of the constraint that a user in more than one organisation receives no organisation claim and is refused on parts of the platform.

   Why, and what the wrong answers get wrong

   The proposal is attractive because the underlying constraint is real and unresolved, and a candidate who does not know the constraint may not understand why the obvious solution is not available. The failing answers are approving it, and rejecting it on vague security grounds without naming attribution. The item also expects the candidate to acknowledge the cost honestly rather than pretending the correct answer is free — a certified engineer who cannot say 'this is more work and here is why we do it anyway' will lose the argument inside their own practice.

   The judgement being assessed

   Whether the candidate can refuse an operationally attractive shortcut on a specific, articulable ground, and whether they can price the correct alternative rather than merely assert it.