Exam objectives — ASTRA Tech Sales Associate

About the proposed examination

The proposed credential assesses evidence-based first-line decisions in customer-facing technology discussions. 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.6%)

D1.1 Given a scenario, trace the components supporting a customer-facing feature and distinguish their jobs.

Example concepts: application, connector, source system, identity.

D1.2 Given a scenario, trace a user request to its confirmed business result and identify an unverified hand-off.

Example concepts: request, response, persisted result.

D1.3 Given a scenario, interpret the sending and receiving API contracts and identify necessary field or meaning translations.

Example concepts: field types, lookup rules, pagination.

D1.4 Given a scenario, distinguish authentication from permission for a named operation.

Example concepts: identity, scope, denied action.

D1.5 Given a scenario, classify a cloud offer by what its provider and customer actually operate.

Example concepts: SaaS, PaaS, IaaS, separate services.

D1.6 Given a scenario, interpret freshness and response-time evidence without conflating display responsiveness with current data.

Example concepts: snapshot age, update cadence.

D2.0 Cloud and solution economics (14.6%)

D2.1 Given a scenario, compare cloud service boundaries against the customer’s ability to operate them before comparing prices.

Example concepts: operating obligations, staffing dependency.

D2.2 Given a scenario, separate software rights, one-time delivery and recurring service commitments.

Example concepts: entitlement, acceptance, service scope.

D2.3 Given a scenario, derive a billable quantity under the specified usage rule.

Example concepts: meter, unit, rounding.

D2.4 Given a scenario, compare alternative user quantities across an equivalent term.

Example concepts: seat-months, contracted period.

D2.5 Given a scenario, calculate an in-scope first-year cost without omitting or double-counting included work.

Example concepts: fees, internal allocation, cash cost.

D2.6 Given a scenario, interpret commitment thresholds and identify unverified financial assumptions.

Example concepts: minimums, overage, unknown work.

D2.7 Given a scenario, distinguish a spending notification from an enforced limit and sequence the approved response.

Example concepts: billing lag, continuity, approval.

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

D3.1 Given a scenario, translate a described security event into the customer consequence and a testable requirement.

Example concepts: confidentiality, integrity, availability.

D3.2 Given a scenario, evaluate who is included in an identity-control test and identify coverage exceptions.

Example concepts: population, enforcement, exclusions.

D3.3 Given a scenario, trace the actual location and access boundary for each relevant data store or path.

Example concepts: primary, logs, backup, exports.

D3.4 Given a scenario, distinguish service restoration time from the point to which data can be restored.

Example concepts: RTO, RPO, evidence timestamp.

D3.5 Given a scenario, match assurance evidence to the exact control, population, period and claim.

Example concepts: control scope, expiry, test.

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

D4.1 Given a scenario, select a bounded AI use case consistent with approved inputs, reviewer availability and action authority.

Example concepts: drafting, deterministic alternatives, exclusions.

D4.2 Given a scenario, separate retrieved source evidence from model-generated content and unsupported assertions.

Example concepts: grounding, provenance, retention.

D4.3 Given a scenario, choose task-sufficient inputs under the stated data-use contract.

Example concepts: minimisation, identity routing, prohibited fields.

D4.4 Given a scenario, test an AI answer against the cited evidence rather than confidence language.

Example concepts: source support, correction, review.

D4.5 Given a scenario, calculate a measured workflow outcome after human review and rework.

Example concepts: eligible volume, quality denominator, time.

D4.6 Given a scenario, distinguish an instruction embedded in content from valid execution authority.

Example concepts: injection, attempted action, gateway result.

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

D5.1 Given a scenario, construct a bounded integration or data-flow claim from the supplied component evidence.

Example concepts: sender, receiver, data, unknown paths.

D5.2 Given a scenario, identify a test and delivery-scope decision before promising the customer an integrated outcome.

Example concepts: acceptance sequence, included services.

D5.3 Given a scenario, recommend a conditional offer using operating fit, cost and documented gates.

Example concepts: price boundary, open dependencies.

D5.4 Given a scenario, turn a vague customer request into a measurable acceptance criterion.

Example concepts: actor, scope, timing, evidence.

D5.5 Given a scenario, calculate operational effort while separating modeled capacity from realised cash savings.

Example concepts: baseline, mix, exclusion.

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

D6.1 Given a scenario, identify the highest-value unresolved discovery question behind a customer request.

Example concepts: outcome, owner, integration dependency.

D6.2 Given a scenario, identify who can approve each business, technical and commercial decision.

Example concepts: seniority versus authority, gate.

D6.3 Given a scenario, sequence the missing facts and decisions required before committing a proposal.

Example concepts: dependencies, owner, next action.

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

D7.1 Given a scenario, distinguish reseller, referral and separately contracted service responsibilities.

Example concepts: contract, bill, implement, support.

D7.2 Given a scenario, apply permission and approval limits to a partner claim or customer message.

Example concepts: discount, customer choice, exception.

D7.3 Given a scenario, prepare a conditional buyer/partner handover naming evidence, unresolved gates and next owners.

Example concepts: scope, review, hand-off.

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

D8.1 Given a scenario, identify which assurance document can be shared with a recipient under its stated conditions.

Example concepts: approval, named contacts, channel.

D8.2 Given a scenario, sequence the authorised response to a reported incident without inventing impact findings.

Example concepts: observed facts, owner, wording.

D8.3 Given a scenario, classify exact questionnaire claims by support, contradiction or missing evidence.

Example concepts: status, exception, next owner.

D8.4 Given a scenario, apply version-bound human approval to a changed draft or high-impact action.

Example concepts: approval record, changed content, gateway.

D8.5 Given a scenario, convert AI marketing claims into a bounded proposal with evidenced results and open release gates.

Example concepts: quality sample, retention, permitted stage.

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.