Exam objectives — ASTRA Tech Sales Advisor

About the proposed examination

The proposed credential assesses integrated recommendations under competing technical, commercial and governance constraints. It does not attest engineering ability, security-auditor status, achievement in a specific job or external accreditation.

Domain weights

Percentages describe the proposed allocation of scored questions by primary domain. Example concepts illustrate scope; examination questions may use different products, facts and fictional organisations. This document contains no answer keys, cases or confidential questions.

Assessable objectives

D1.0 Solution architecture, integration and operating boundaries (14.3%)

D1.1 Given a scenario, frame a scoped technical-commercial pilot from the required outcome and unknown interface capabilities.

Example concepts: pilot scope, required outcome, undocumented capability, exclusion.

D1.2 Given a scenario, trace the producer, consumer, integrator and business approver through a proposed flow.

Example concepts: producer, consumer, integrator, business approver.

D1.3 Given a scenario, choose an integration pattern that meets timing, replay and duplicate constraints.

Example concepts: webhook, batch, idempotency key, replay window.

D1.4 Given a scenario, interpret reliability test measures without hiding retries or failed records.

Example concepts: first-attempt success, retries, dead-letter queue, percentile.

D1.5 Given a scenario, resolve identifier, status, timestamp and version semantics in a two-party data contract.

Example concepts: identifier ownership, status mapping, version, time zone.

D1.6 Given a scenario, trace technical and approval boundaries across a candidate workflow.

Example concepts: workflow boundary, permitted action, approval point.

D2.0 Cloud and solution economics (12.5%)

D2.1 Given a scenario, identify the cost meter, period, usage owner and forecast exposure behind a quote.

Example concepts: meter, billing period, usage owner, forecast exposure.

D2.2 Given a scenario, interpret entitlements, rights and commitment terms under changing demand.

Example concepts: entitlement, commitment term, shortfall, overage.

D2.3 Given a scenario, reconcile a usage record to a defined billing line and find a mismatch.

Example concepts: usage record, invoice line, included allowance, mismatch.

D2.4 Given a scenario, calculate stepped or tiered charges and the cost of unused commitment.

Example concepts: tiered rate, stepped charge, unused commitment.

D2.5 Given a scenario, compare scenarios without treating demand assumptions as confirmed savings.

Example concepts: demand assumption, scenario, modelled saving.

D2.6 Given a scenario, calculate commercial economics without merging subscription and partner-service revenue.

Example concepts: subscription revenue, partner services, margin.

D2.7 Given a scenario, calculate released operational capacity while separating model from realised return.

Example concepts: released hours, modelled capacity, realised saving.

D2.8 Given a scenario, calculate the full effort model and bound the resulting commercial claim.

Example concepts: effort model, scope boundary, bounded claim.

D3.0 Security, assurance and operational trust (12.5%)

D3.1 Given a scenario, identify supported least-privilege and diagnostic controls, and what remains unproven.

Example concepts: least privilege, diagnostic access, unproven control.

D3.2 Given a scenario, translate a scoped security questionnaire into claim-specific evidence requests.

Example concepts: claim, evidence request, scope of question.

D3.3 Given a scenario, assign control operation, disclosure and customer-exception decisions to their authorised owners.

Example concepts: control operation, disclosure, customer exception.

D3.4 Given a scenario, interpret an assurance report within its period, tested services and exceptions.

Example concepts: period examined, tested services, exceptions.

D3.5 Given a scenario, sequence remediation, retest, customer acceptance and approved messaging.

Example concepts: remediation, retest, acceptance, approved messaging.

D3.6 Given a scenario, calculate incident reporting time using the specified clock trigger and authorisation.

Example concepts: clock trigger, confirmation, authorisation, deadline.

D3.7 Given a scenario, respond to an assurance objection without extending supplier evidence to a customer tenant.

Example concepts: supplier evidence, customer tenant, boundary of claim.

D3.8 Given a scenario, reconcile supplier assurance with tenant controls and executed customer terms.

Example concepts: supplier assurance, tenant control, executed terms.

D4.0 AI value, quality and safe-use decisions (14.3%)

D4.1 Given a scenario, frame an AI-supported workflow by decision consequence, source and permitted action.

Example concepts: decision consequence, source, permitted action.

D4.2 Given a scenario, evaluate a measured model result for the intended population and operating threshold.

Example concepts: intended population, operating threshold, agreement rate.

D4.3 Given a scenario, define allowed data, processing purpose, retention and deletion evidence.

Example concepts: allowed data, purpose, retention, deletion evidence.

D4.4 Given a scenario, interpret intervention metrics and choose the owner-led response to drift.

Example concepts: intervention rate, baseline, drift trigger, owner.

D4.5 Given a scenario, distinguish model intent, tool execution and reviewer authority in an AI control event.

Example concepts: model intent, tool execution, reviewer authority.

D5.0 Technical-commercial translation and defensible recommendations (12.5%)

D5.1 Given a scenario, deliver a bounded architecture recommendation with explicit exit criteria.

Example concepts: bounded recommendation, exit criteria, scope.

D5.2 Given a scenario, compare options under complete first-year costs and nonfinancial gates.

Example concepts: first-year cost, nonfinancial gate, comparison.

D5.3 Given a scenario, give a conditional purchasing decision with named triggers and accountable owners.

Example concepts: conditional decision, trigger, accountable owner.

D5.4 Given a scenario, assemble a conditional offer from cost, capability and customer acceptance evidence.

Example concepts: cost evidence, capability evidence, customer acceptance.

D5.5 Given a scenario, deliver a governed customer/partner handover with review and exit conditions.

Example concepts: handover, review point, exit condition.

D5.6 Given a scenario, sequence reversible pilot gates and the earliest evidence-backed next action.

Example concepts: reversible gate, earliest evidence, next action.

D5.7 Given a scenario, deliver an integrated recommendation distinguishing observed, modeled and unknown outcomes.

Example concepts: observed, modelled, unknown outcome.

D6.0 Discovery, stakeholders and decision sequencing (12.5%)

D6.1 Given a scenario, calculate and order dependent testing, security and acceptance activities.

Example concepts: dependency, testing, security review, acceptance.

D6.2 Given a scenario, prepare a conditional deployment handover with monitoring and reversal gates.

Example concepts: deployment handover, monitoring, reversal gate.

D6.3 Given a scenario, calculate eligible weighted pipeline without counting booked or unqualified opportunities.

Example concepts: eligible opportunity, stage weight, booked revenue.

D6.4 Given a scenario, frame a customer decision with technical, financial and governance constraints.

Example concepts: technical constraint, financial constraint, governance constraint.

D6.5 Given a scenario, target discovery questions to the owner and the gate each answer changes.

Example concepts: discovery question, owner, gate affected.

D6.6 Given a scenario, calculate the dependency path for reversible expansion and acceptance.

Example concepts: dependency path, reversible expansion, acceptance.

D6.7 Given a scenario, frame a multi-party, multi-domain decision into a bounded customer recommendation.

Example concepts: multi-party decision, bounded recommendation.

D7.0 Partner, channel and contracting boundaries (10.7%)

D7.1 Given a scenario, define a partner motion while preserving the customer and supplier boundaries.

Example concepts: partner motion, customer boundary, supplier boundary.

D7.2 Given a scenario, apply deal-registration and conflict evidence before allocating attribution.

Example concepts: deal registration, conflict evidence, attribution.

D7.3 Given a scenario, distinguish sourced, influenced and disputed co-sell evidence.

Example concepts: sourced, influenced, disputed.

D7.4 Given a scenario, apply capability and performance evidence to reversible enhanced-term gates.

Example concepts: capability evidence, performance evidence, reversible term.

D7.5 Given a scenario, protect customer continuity, renewal ownership and exit responsibilities.

Example concepts: customer continuity, renewal ownership, exit duty.

D7.6 Given a scenario, prepare a governed channel handover with economics, owners, gaps and expiry.

Example concepts: channel handover, economics, gap, expiry.

D7.7 Given a scenario, resolve vendor, partner and customer authority in a proposed transaction.

Example concepts: vendor authority, partner authority, customer choice.

D8.0 Evidence governance, approvals and responsible claims (10.7%)

D8.1 Given a scenario, link budget, admission and approval controls to cost and service continuity.

Example concepts: budget alert, spend limit, approval, continuity.

D8.2 Given a scenario, evaluate retention and subprocessor evidence across the actual data lifecycle.

Example concepts: retention period, subprocessor, data lifecycle.

D8.3 Given a scenario, distinguish AI assurance evidence from claims it does not establish.

Example concepts: AI assurance evidence, unestablished claim.

D8.4 Given a scenario, assemble a conditional response across evidence, missing controls and owner actions.

Example concepts: evidence status, missing control, owner action.

D8.5 Given a scenario, assign business, data, model and execution approval decisions to the correct owners.

Example concepts: business approval, data approval, model approval, execution approval.

D8.6 Given a scenario, sequence the review, version binding and release checks for a consequential action.

Example concepts: review, version binding, release check.

D8.7 Given a scenario, decide which provider or model changes require retest before deployment.

Example concepts: provider change, model change, retest requirement.

D8.8 Given a scenario, classify observed, modeled and unestablished outcomes within one commercial claim.

Example concepts: observed result, modelled result, unestablished claim.

Important candidate notes

• A programme learning-completion record is not the assessed credential. Completion of ASTRA Ready lessons is not required for assessment-only entry where eligibility conditions are met.

• Practice assessments, module exercises, formative simulations and planned mocks are disclosed learning activities; their results do not award a credential or predict a pass.

• The final blueprint, examination time, availability and pass standard require pilot evidence, ASTRA Ready review, founder approval, examination-engine tests and confirmation of the issuing legal entity.

• Assessment examples are fictional and judge decisions within supplied contracts and artefacts; they do not substitute for laws, vendor attestations or live system validation.