skip to content

For a rented browser session, how do you decide what your benefits-claim suite may carry into it, and who signs that off?

level: principalimportance: must knowfreq 46%

answer

  1. you cannot inspect the far side
  2. decide what you hand over instead
  3. classes, not a long gradation
  4. unclassified must fail, not pass
  5. the data owner signs the residual

basics

~20 s

Decide it as an admission rule on your own side, because the far side cannot be inspected: for each thing a session would carry, say whether it may run rented, and have the harness enforce it rather than documentation.

solid answer

~50 s

Because a tenant can observe its own side and none of the provider's, the decision that is genuinely yours is not *are they trustworthy* but **what will we hand over**. So write an admission rule over the payload classes a rented session actually carries — the identity that signs in, the live token the login issues, the record content rendered, and whether the session may reach names that resolve only inside — and mark each as admitted, admitted with a condition, or local only. Make the harness enforce it: every suite declares its class, an unclassified suite fails rather than defaulting to admitted, and the check runs before any remote session exists. The sign-off belongs to whoever owns the claimant data, and what they are signing is that knowledge of the far side is contractual rather than observed. Review it when your own side changes.

code

kotlin · 22 lines
kotlin
enum class Offsite { ADMITTED, CONDITIONAL, LOCAL_ONLY }

@Target(AnnotationTarget.CLASS)
annotation class Payload(val offsite: Offsite)

// Registered ahead of whatever opens the browser, so refusal precedes the session.
class RemoteAdmissionGate : BeforeEachCallback {
    override fun beforeEach(ctx: ExtensionContext) {
        val name = ctx.requiredTestClass.simpleName
        val declared = ctx.requiredTestClass.getAnnotation(Payload::class.java)
            ?: error("$name declares no payload class; refusing to run")
        if (!RunTarget.isRented()) return
        when (declared.offsite) {
            Offsite.LOCAL_ONLY -> throw TestAbortedException("$name is LOCAL_ONLY, this run is rented")
            Offsite.CONDITIONAL -> check(RunTarget.conditionsMet(name)) { "$name: conditions unmet" }
            Offsite.ADMITTED -> Unit
        }
    }
}

@Payload(offsite = Offsite.LOCAL_ONLY)
class RealClaimantReplayTest

go deeper

for a junior

You will not own this decision yet, but know that a rule exists about what your suite may carry offsite and where it is written down. Ask which class your suite falls into before you point it at a rented target.

for a middle

Be ready to name the payload classes a rented session carries and to say which of them your own suite produces. That inventory is what a classification decision is actually made from, and getting it wrong makes the rest theatre.

for a senior

Be ready to describe the enforcement, not just the policy: where the declaration lives, what happens to an unclassified suite, and at which point in the run the refusal fires relative to session creation.

for a principal

Be ready to say who accepts the residual risk, what sentence they are actually accepting, and what triggers a review. Expect to be pushed on the cost of the local-only class and on how you stop the rule eroding.

## Why this is a decision rather than a verification The instinct is to answer this by evaluating the provider: read the attestations, ask the questionnaire, decide whether they are trustworthy. That work is real, and it belongs to supplier selection. It is not an answer to *this* question, because no amount of it changes what a tenant can see. From a tenant login you can observe your own side of every interaction and nothing of theirs. So the decision that is actually yours to make is not *are they safe* but **what will we hand over**, and that one you can both decide and enforce. Framing it that way degrades gracefully. If the vendor turns out worse than believed, an estate that bounded its payload has a bounded problem; one that reasoned only from trust has whatever it sent. ## The admission rule The workable shape is a rule with a small, fixed set of payload classes, decided once and applied per suite rather than per test. For a benefits-claim estate the classes fall out of the inventory of what a rented session carries: - **Identity** — which account signs in, and whether a person's own login is ever in scope. - **Live session material** — the token the portal issues and whatever the logged-in session can reach with it. - **Record content** — whether the records rendered are manufactured, transformed, or extracted. - **Reachability** — whether the session may reach names that only resolve inside, and which. For each class the rule says one of: admitted to rented execution, admitted with a named condition, or local only. It does not need more resolution than that. A rule with many gradations is a rule nobody applies correctly at half past six on a release evening. ## Who signs it, and what they are signing The signature is not on *the provider is safe*. It is on a sentence of this form: *we accept that a session carrying this payload runs on hardware we do not operate, and that our knowledge of the far side's handling is contractual rather than observed.* Whoever owns the claimant data owns that acceptance — in most organisations the data owner or the risk function, advised by engineering, never engineering alone. Two failure modes are worth naming because both are common: 1. **Nobody signs, so the first suite sets the precedent.** The payload that crossed on day one becomes the norm, and every later suite is compared to it rather than to the rule. 2. **Somebody signs once, for one suite, and the acceptance is quietly inherited.** A year later a different team points a different suite at the same account and nobody re-reads what was accepted. ## Making it enforceable rather than documentary A rule that lives in a document is a rule that is obeyed by whoever has read the document. The version that survives is one the harness enforces. The accompanying snippet shows the minimum: every suite declares its payload class, and a gate refuses to run a locally-classified suite against a rented target. The details that make it work are unglamorous: - **Declaration is mandatory.** A suite with no declaration fails rather than defaulting to admitted; the default is the whole game. - **The check runs before a session is created**, which means ordering it ahead of whatever opens the browser; a refusal after the browser exists has already done the thing it was refusing. - **The classification lives with the suite**, so it travels with the code and shows up in review when somebody changes it. - **Refusal is loud and specific**, naming the suite and the reason, so the outcome is a conversation rather than a quiet skip. ## What the rule costs you Be honest about the price, because an interviewer will probe it. A local-only class means those cases need somewhere to run that you do operate, and that is capacity, images and maintenance you were trying to avoid by renting. The cases most likely to land in that class are often the ones most worth running broadly. So the rule is not free, and a team that classifies everything as local-only has decided not to rent, which is a legitimate decision but should be made deliberately rather than arrived at by accumulation. | what the rule buys | what it costs | |---|---| | a bounded loss if the vendor assumption is wrong | a second place to run the excluded cases | | a reviewable decision instead of an accumulated one | classification work on every new suite | | an argument you can make to a regulator or auditor | pressure to reclassify under deadline | ## Keeping it alive Treat it as a standing decision with a review trigger rather than a one-off sign-off. The triggers that matter are changes on your side, because they are the ones you can detect: a suite starts using a different account, a fixture source changes from manufactured to extracted, reachability is switched on for a new name, a new team adopts the estate. Each of those changes the payload without changing the vendor, and each is visible in your own repository if somebody is looking. The strongest version of this answer refuses the framing of trust and replaces it with admission: *we could not verify them, so we decided what we were willing to hand over, wrote it down, made the harness enforce it, and named who accepted the rest.*

  • Where do the cases you classify as local-only actually run?
    On capacity you operate, which is the cost of the rule and should be stated as such. That usually means a smaller estate kept alive for a narrow set of suites, with its own images and upkeep. The honest trade is that renting bought you out of operating a fleet, and a local-only class buys part of that obligation back for the cases that earn it.
  • How do you stop the rule being reclassified away under deadline pressure?
    Make reclassification visible rather than impossible. The declaration lives with the suite, so changing it is a code change that shows up in review, and the reviewer set for that file includes whoever accepted the original residual. Nobody needs a veto; they need to see it happen while it is happening.
  • A team wants an exception for one release. What do you ask for?
    An expiry and a named acceptor, in the same change that grants it. An exception with a date attached is a decision; one without is a permanent reclassification wearing a temporary label. Ask also what the exception changes about the payload specifically, because often it turns out only the identity class needed to move.

saying these in an interview costs you the question

  • Answers by evaluating the vendor instead of bounding the payload
  • Lets an unclassified suite default to running remotely
  • Treats an attestation as evidence of what actually happens
  • Puts the rule in a document with no enforcement
  • Ignores that local-only cases need capacity somebody operates
  • Has engineering alone accept the residual on claimant data