I85PREP
⌘ K
CAP Glacier Fabricant study materials
CAP Glacier Fabricant study resources

CAP Glacier Fabricant practice questions

One question at a time. Build your CAP Glacier Fabricant understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Automation Fundamentals and Project Justification

A client wants to justify automating a manual data-entry workflow before committing budget. Which document should the CAP candidate produce first to establish the baseline the business case will be measured against?

  1. A current-state process map that quantifies volumes, cycle times, and error rates Correct answer.
  2. A vendor license quotation covering the automation platform
  3. A training plan for the operators who will run the workflow
  4. A disaster recovery runbook for the new automation servers

Explanation

Justifying automation requires a quantified baseline of the existing process so that savings and error reduction can be measured later. Volumes, cycle times, and error rates are the metrics a business case compares against post-automation results. License costs, training, and recovery planning are downstream artifacts that depend on the baseline.

Question 2Automation Fundamentals and Project Justification

In a UiPath-style automation project, which element is the reusable component that encapsulates a business activity and can be invoked by multiple processes?

  1. A credential asset
  2. A queue
  3. A library Correct answer.
  4. A trigger

Explanation

A library packages reusable workflows so that several processes can invoke the same business activity without duplication. Queues hold transactional data, triggers start jobs, and credential assets store secrets. Only the library is the reuse mechanism for logic.

Question 3Automation Fundamentals and Project Justification

A process owner asks why a candidate process was scored low on automation potential despite being highly repetitive. Which factor most plausibly explains the low score?

  1. The process runs at high volume every business day
  2. The process has stable, structured digital inputs
  3. The process requires frequent subjective judgment on ambiguous exception cases Correct answer.
  4. The process is performed by a large team of operators

Explanation

Repetition and volume raise automation potential, but frequent subjective judgment on ambiguous cases raises complexity and risk. Automation suitability scoring weighs rule-based determinism alongside volume. Stable structured inputs and large operator pools generally increase, not decrease, attractiveness.

Question 4Automation Fundamentals and Project Justification

During a feasibility assessment, the team finds the target application exposes a documented REST API with authentication. What is the recommended automation approach?

  1. Use manual intervention because APIs require human approval
  2. Use the API integration because it is more stable than screen-level interaction Correct answer.
  3. Use UI automation because APIs cannot be called from an automation tool
  4. Use OCR on screenshots because the API returns JSON

Explanation

When a supported API exists, integrating at the API layer avoids fragile UI dependencies and is generally faster and more reliable. UI automation is a fallback when no programmatic interface is available. OCR and manual steps add cost without benefit here.

Question 5Automation Fundamentals and Project Justification

A candidate process handles 40,000 transactions per month with an average handling time of 6 minutes and an error rate of 4 percent requiring rework. Which additional piece of information is most needed to estimate annual labor savings?

  1. The fully loaded hourly cost of the operators performing the work Correct answer.
  2. The number of screens in the target application
  3. The programming language used by the automation tool
  4. The version of the operating system on the bot machines

Explanation

Volume and handling time already give total effort, and the error rate indicates rework effort. Converting that effort into money requires the fully loaded labor cost per hour. Screen counts, tool language, and OS version affect implementation, not the monetary saving.

Question 6Automation Fundamentals and Project Justification

Which statement best describes the role of a Center of Excellence in an enterprise automation program?

  1. It replaces the business owners in approving process changes
  2. It sets standards, governs the pipeline, and shares reusable assets across delivery teams Correct answer.
  3. It personally builds every automation in the organization
  4. It procures hardware for the data center

Explanation

A Center of Excellence provides standards, governance, reusable components, and enablement so that many teams deliver consistently. It does not build every automation itself, nor does it take over business ownership decisions. Hardware procurement is outside its remit.

Question 7Automation Fundamentals and Project Justification

A development team proposes automating a process whose exception rate is 35 percent and whose rules are undocumented. What is the most defensible recommendation?

  1. Defer automation until the rules are documented and exceptions are reduced or modeled Correct answer.
  2. Proceed immediately and let the bot handle exceptions with free-text reasoning
  3. Abandon automation permanently because exceptions never disappear
  4. Proceed immediately because high exception rates prove the process is valuable

Explanation

Undocumented rules combined with a high exception rate make deterministic automation risky and expensive to maintain. Documenting rules and reducing or explicitly modeling exceptions improves feasibility. Deferral is not permanent abandonment, and unstructured exception handling is not a sound design.

Question 8Automation Fundamentals and Project Justification

In the automation pipeline, what distinguishes a 'quick win' from a strategic initiative?

  1. A quick win has no measurable benefit but high visibility
  2. A quick win delivers visible value within a short cycle with low technical complexity Correct answer.
  3. A quick win always requires replacing the core system of record
  4. A quick win is selected only after all strategic projects complete

Explanation

Quick wins are chosen for short delivery cycles, low complexity, and fast visible benefit that builds momentum. They still require measurable value. They do not involve core system replacement and are not sequenced after every strategic project.

Question 9Automation Fundamentals and Project Justification

A process is performed only twice a year but each instance takes three days of manual effort. How should this be weighed in prioritization?

  1. Low frequency limits annual savings, so priority is likely lower than a high-volume process Correct answer.
  2. High effort per instance guarantees top priority regardless of frequency
  3. Frequency is irrelevant because only complexity matters
  4. The process should be automated first because it is rare and therefore simple

Explanation

Annual benefit is a function of both effort per instance and frequency. Two instances per year yield roughly six person-days of saving, which is modest compared with high-volume work. Effort alone does not determine priority, and rarity says nothing about simplicity.

Question 10Automation Fundamentals and Project Justification

What is the primary purpose of a process design document in an automation project?

  1. To capture the agreed to-be process steps, business rules, and exception handling before build Correct answer.
  2. To list the salaries of the project team members
  3. To serve as the production incident log after go-live
  4. To record the source code of the automation workflows

Explanation

The process design document records the agreed future-state process, its rules, inputs, outputs, and exception paths so developers build to a shared specification. Source code, salary data, and incident logs are different artifacts with different owners.

Question 11Automation Fundamentals and Project Justification

A stakeholder insists on automating a step that involves negotiating with customers on pricing. What is the soundest response from an automation analyst?

  1. Automate the step by recording a fixed script for all negotiations
  2. Keep that step human and automate the surrounding data gathering and documentation Correct answer.
  3. Remove the negotiation step from the process entirely
  4. Automate the negotiation using a chatbot with no human oversight

Explanation

Negotiation involves judgment, context, and relationship management that deterministic automation cannot safely replace. The sound pattern is to automate the surrounding deterministic work while retaining human ownership of judgment steps. Fixed scripts and unsupervised chatbots cannot handle negotiation variability.

Question 12Automation Fundamentals and Project Justification

Which metric best demonstrates that an automation program is scaling sustainably rather than through one-off heroics?

  1. The number of processes delivered per quarter using shared reusable components Correct answer.
  2. The total lines of code written across all projects
  3. The number of hours worked by the most experienced developer
  4. The count of meetings held by the program office

Explanation

Sustainable scaling shows throughput achieved through reuse and standard components rather than individual effort. Counting hours of a key developer or lines of code measures activity, not scalable capability. Meeting counts are not delivery outcomes.

Question 13Automation Fundamentals and Project Justification

What is the main risk of automating a process before standardizing it?

  1. Standardization becomes unnecessary once a bot exists
  2. The bot will refuse to run on non-standard processes
  3. The automation encodes existing inefficiencies and must be rebuilt after redesign Correct answer.
  4. Licensing costs decrease because the process is non-standard

Explanation

Automating a non-standard process locks in current waste and rework, forcing expensive rebuilds when the process is later improved. Bots do not refuse to run on non-standard processes, and automation does not remove the need for standardization. Licensing is unaffected by process standardization.

Question 14Automation Fundamentals and Project Justification

A business case shows payback in 9 months, but the target application is scheduled for replacement in 12 months. What is the most appropriate conclusion?

  1. Proceed unchanged because payback occurs before replacement
  2. Extend the payback period artificially to match the replacement date
  3. Cancel all automation permanently because applications change
  4. The benefit window may be too short to justify build cost, so reassess scope and lifetime Correct answer.

Explanation

A payback that barely precedes a system replacement leaves little time to realize sustained benefit relative to build and maintenance cost. The analyst should reassess scope, target a stable system, or plan for migration. Proceeding unchanged ignores the short benefit window, and permanent cancellation is an overreaction.

Question 15Automation Fundamentals and Project Justification

Which combination best represents the total cost of ownership for an automation over three years?

  1. Only the infrastructure hardware cost
  2. Only the initial developer salaries
  3. Only the platform license fee
  4. Build effort, platform licenses, infrastructure, maintenance, and change support Correct answer.

Explanation

Total cost of ownership spans the full lifecycle: initial build, ongoing licensing, infrastructure, maintenance of workflows as applications change, and support. Any single cost category understates the true cost. Maintenance in particular is often the largest long-run component.

Question 16Automation Fundamentals and Project Justification

An analyst must choose between two candidate processes with equal savings. Process A is rule-based with structured inputs; Process B requires reading handwritten forms. Which choice is better supported and why?

  1. Process A, because deterministic structured inputs reduce build risk and maintenance cost Correct answer.
  2. Process A, because structured inputs eliminate the need for testing
  3. Process B, because handwriting recognition is always more accurate than rule engines
  4. Process B, because unstructured input guarantees higher business value

Explanation

With equal savings, the lower-risk option is preferable, and structured deterministic inputs reduce implementation and maintenance risk. Handwriting recognition introduces variability and error. Structured inputs reduce but do not eliminate testing needs.

Question 17Automation Fundamentals and Project Justification

What does a 'bot operating model' primarily define for an enterprise?

  1. The physical layout of office workstations
  2. How bots are deployed, monitored, supported, and governed in production Correct answer.
  3. The personal career path of each developer
  4. The marketing strategy for automation services

Explanation

An operating model defines the production operating arrangements: deployment, orchestration, monitoring, incident support, change control, and governance roles. It is not a marketing plan, an individual career framework, or a facilities layout.

Question 18Automation Fundamentals and Project Justification

A process has a stable happy path but 20 percent of cases require contacting a third party whose responses vary widely. Which design approach is most appropriate?

  1. Automate only the third-party contact and leave the happy path manual
  2. Automate all cases with a single fixed script
  3. Reject the process because any exception exists
  4. Automate the happy path and route variable cases to a human work queue Correct answer.

Explanation

Automating the deterministic majority captures most of the benefit while routing genuinely variable cases to humans preserves quality. A single fixed script cannot absorb wide response variability. Rejecting the process ignores the value in the stable 80 percent, and inverting the split forfeits the easy gains.

Question 19Automation Fundamentals and Project Justification

Which statement correctly describes how a business analyst should document the 'as-is' versus 'to-be' process for an automation project?

  1. The as-is and to-be must be identical for automation to succeed
  2. The to-be is written only after production deployment
  3. The as-is is optional because only the future state matters
  4. The as-is captures current reality including waste; the to-be captures the agreed optimized and automated flow Correct answer.

Explanation

The as-is documents current reality so waste and pain points are visible, while the to-be defines the optimized, automated target. They are intentionally different because automation projects remove or streamline steps. Writing the to-be after deployment defeats its purpose as a build specification.

Question 20Automation Fundamentals and Project Justification

An automation program reports high delivery volume but low business satisfaction. Which diagnostic is most useful?

  1. Add more meetings to the governance calendar
  2. Reduce testing effort to speed up delivery further
  3. Increase the number of developers on the team
  4. Compare delivered processes against the original value hypotheses and benefit tracking Correct answer.

Explanation

When volume is high but satisfaction is low, the likely gap is between what was delivered and the value the business expected. Tracing each delivery back to its value hypothesis and benefit tracking reveals whether the pipeline targets the wrong processes. Adding staff, cutting testing, or adding meetings does not address value alignment.

Question 21Requirements, Specification, and Design

In a Salesforce project using Glacier for requirements and design, which artifact is the appropriate place to capture a non-functional performance target such as 'search results must render within two seconds'?

  1. A test script step in the regression suite that measures page load time
  2. A user story acceptance criterion attached to the search feature backlog item
  3. A design pattern entry in the technical architecture document describing caching layers
  4. A non-functional requirement recorded in the requirements specification with a measurable acceptance threshold Correct answer.

Explanation

Non-functional requirements belong in the requirements specification and must be stated with measurable thresholds so they can later be verified. Design documents describe how the target will be met, and tests verify it, but the requirement itself is owned by the requirements artifact.

Question 22Requirements, Specification, and Design

A business stakeholder asks for 'a dashboard that shows everything about customers.' Which action best applies requirements elicitation discipline before any design work begins?

  1. Select a charting library and sketch the dashboard layout to show the stakeholder quickly
  2. Add the request to the design document as a future enhancement for later review
  3. Log the request as-is and estimate it during the next sprint planning session
  4. Decompose the request into specific questions the dashboard must answer and the decisions it supports Correct answer.

Explanation

Vague requests must be decomposed into the decisions and questions the artifact must support before design choices are made. This keeps the requirement testable and prevents premature solutioning. Selecting tools or estimating an undefined request skips elicitation entirely.

Question 23Requirements, Specification, and Design

Which statement correctly distinguishes a functional requirement from a non-functional requirement in a Glacier specification?

  1. A functional requirement is written by the business; a non-functional requirement is written only by architects
  2. A functional requirement describes the UI; a non-functional requirement describes the data model
  3. A functional requirement states a behavior or capability; a non-functional requirement states a quality or constraint on that behavior Correct answer.
  4. A functional requirement is mandatory; a non-functional requirement is optional and may be deferred

Explanation

The core distinction is behavior versus quality attribute or constraint. Functional requirements describe what the system does, while non-functional requirements constrain how well or under what conditions it does it. Ownership and UI-versus-data distinctions are not valid dividing lines.

Question 24Requirements, Specification, and Design

A team is drafting a user story for a Glacier build. Which element makes the story ready for design and estimation?

  1. A named developer, a target sprint, and an estimated story point value
  2. A wireframe, a database schema, and a deployment diagram
  3. A role, a goal, a business value statement, and agreed acceptance criteria Correct answer.
  4. A priority ranking, a risk rating, and a linked defect record

Explanation

A well-formed story captures who wants the capability, what they want, why it matters, and the conditions that confirm completion. Those acceptance criteria are what let design and estimation proceed with shared understanding. Assignments, schemas, and priority metadata are supplementary rather than defining.

Question 25Requirements, Specification, and Design

During specification review, a requirement reads: 'The system shall be user-friendly.' What is the primary defect?

  1. It is too long and should be split into multiple requirements
  2. It is not verifiable because no measurable criterion defines user-friendly Correct answer.
  3. It lacks a named stakeholder owner in the metadata
  4. It describes a design decision rather than a requirement

Explanation

A requirement must be verifiable so that testing can determine whether it has been satisfied. 'User-friendly' has no measurable criterion, so no test can pass or fail it objectively. Length, ownership metadata, and design-versus-requirement framing are secondary to the missing measurable threshold.

Question 26Requirements, Specification, and Design

Which document is the correct home for a decision to use a layered service architecture with a dedicated integration layer?

  1. The business requirements specification
  2. The solution design or architecture document Correct answer.
  3. The product backlog as a single story
  4. The test plan as a verification approach

Explanation

Architectural and structural decisions belong in the design or architecture document, which records how requirements will be realized. Requirements documents state needs, not structures. Backlogs and test plans reference the decision but do not own it.

Question 27Requirements, Specification, and Design

A specification uses the phrase 'as appropriate' in three requirements. Why does this weaken the specification?

  1. It makes the requirements too long to read in a single review session
  2. It leaves the decision to the implementer, producing inconsistent and untestable behavior Correct answer.
  3. It duplicates content that should appear in the design document
  4. It introduces technical jargon that business stakeholders cannot follow

Explanation

Vague qualifiers delegate judgment to whoever builds the feature, so different implementers produce different outcomes and no test can confirm compliance. Requirements should state the specific condition that determines the expected behavior. Length, duplication, and jargon are separate quality concerns.

Question 28Requirements, Specification, and Design

What is the purpose of a traceability matrix in a Glacier requirements and design effort?

  1. To link each requirement to its design elements and verifying tests so coverage gaps are visible Correct answer.
  2. To estimate the effort needed to build each requirement
  3. To rank requirements by business value for sprint prioritization
  4. To record the meeting minutes where requirements were elicited

Explanation

Traceability connects requirements forward to design and tests and backward to their source, exposing requirements with no design or no test. Prioritization, meeting records, and effort estimation are separate activities supported by other artifacts.

Question 29Requirements, Specification, and Design

A stakeholder insists that a reporting feature must support exports in three specific formats. Where should this constraint appear, and how should it be phrased?

  1. As a test case asserting that at least one export format works
  2. As a requirement listing the three named formats as mandatory supported outputs Correct answer.
  3. As a backlog comment recording the stakeholder's personal preference
  4. As a design note suggesting the team consider common export formats

Explanation

When a stakeholder imposes a specific constraint, the requirement should name the exact formats so compliance is unambiguous and testable. Design notes and comments do not bind the build, and a test asserting only one format fails to capture the stated obligation.

Question 30Requirements, Specification, and Design

A requirement states: 'The order total shall equal the sum of line item prices multiplied by quantity, plus applicable tax.' Which quality attribute does this requirement best demonstrate?

  1. Correctness of a business rule expressed as a precise, testable calculation Correct answer.
  2. Usability through clear presentation of the total
  3. Availability through redundant calculation services
  4. Modifiability through a pluggable tax calculation strategy

Explanation

The statement defines an exact business calculation whose result can be checked against known inputs and expected outputs. That is a precise, verifiable business rule. The other attributes concern changeability, ease of use, and uptime rather than the arithmetic definition.

Question 31Requirements, Specification, and Design

A design review finds that a component depends directly on three external vendor APIs, each with its own data model. Which design principle is most directly violated?

  1. Separation of test data from production data
  2. Version control of configuration files
  3. Encapsulation of external integrations behind a stable internal interface Correct answer.
  4. Single sign-on across vendor portals

Explanation

Direct dependence on multiple vendor models couples the core component to volatile external contracts. Wrapping those integrations behind a stable internal interface isolates change and is the principle at stake. The other options concern identity, data segregation, and configuration management, which are unrelated to this coupling.

Question 32Requirements, Specification, and Design

In a use case specification, what is the role of an alternate flow?

  1. It describes the actor's organizational reporting structure
  2. It records an error that should never occur in production
  3. It lists the non-functional requirements attached to the use case
  4. It documents a valid path taken when a condition in the main flow differs from the expected case Correct answer.

Explanation

Alternate flows capture legitimate variations, such as a payment being declined and the customer choosing another method, so the specification covers realistic behavior. They are not reserved for impossible errors, quality attributes, or organizational context.

Question 33Requirements, Specification, and Design

A team writes acceptance criteria as 'The system should be fast and reliable.' How should this be corrected?

  1. Split the criteria into two separate stories about speed and reliability
  2. Add the phrase 'to the stakeholder's satisfaction' to clarify intent
  3. Move the criteria into the design document as quality goals
  4. Replace with measurable thresholds such as response time percentiles and allowed downtime per month Correct answer.

Explanation

Acceptance criteria must be objectively checkable, which requires concrete thresholds like a response-time percentile and a monthly downtime allowance. Adding subjective language or relocating the statement does not make it verifiable, and splitting the story leaves both halves unmeasurable.

Question 34Requirements, Specification, and Design

Which practice best keeps a design specification aligned with requirements as both evolve during a long project?

  1. Store design decisions only in team chat history for speed
  2. Assign stable identifiers to requirements and reference them from design sections and tests Correct answer.
  3. Freeze the requirements baseline at kickoff and reject all later changes
  4. Rebuild the design document from scratch at each release

Explanation

Stable identifiers create durable links so that when a requirement changes, the affected design sections and tests can be found and updated. Freezing requirements ignores legitimate change, chat history is not a controlled record, and full rewrites invite drift and lost rationale.

Question 35Requirements, Specification, and Design

A specification defines a data field as 'customer status' without listing allowed values. Why is this a specification defect?

  1. The valid value domain is undefined, so implementations and tests may disagree on acceptable values Correct answer.
  2. The specification omits the database column type for the field
  3. The field name is too short to be meaningful to developers
  4. The field should have been described in the design document instead

Explanation

A field specification must define its domain of valid values, otherwise different implementers choose different sets and tests cannot assert correct behavior. Physical storage type is a design concern, and name length or document placement are not the underlying defect.

Question 36Requirements, Specification, and Design

A requirement reads: 'The portal shall allow a customer to reset a password using a verified email link that expires after 30 minutes.' Which pair of properties does this statement best illustrate?

  1. A non-functional availability target combined with a security policy
  2. A business goal combined with a prioritization ranking
  3. A design pattern combined with a deployment topology
  4. A functional capability combined with a specific, testable constraint Correct answer.

Explanation

The statement names a capability the system must provide and attaches a concrete time limit that can be tested precisely. Combining behavior with a measurable constraint is exactly how such requirements should be written. It does not specify availability targets, structural patterns, or priority.

Question 37Requirements, Specification, and Design

When specifying an interface between two systems, which set of details belongs in the interface specification?

  1. The sprint in which each system will be built
  2. The names of the developers who own each system
  3. The internal class hierarchy of each system
  4. Message formats, field semantics, error responses, and timing expectations Correct answer.

Explanation

An interface specification defines the contract the two sides must honor: data shapes, meaning of fields, failure behavior, and timing. Internal structure, scheduling, and personnel are implementation and planning details that the other system neither needs nor should depend on.

Question 38Requirements, Specification, and Design

A design proposes storing a computed total in three separate tables to speed reads. What is the primary design risk that review should raise?

  1. The computed total should be calculated only in the presentation layer
  2. The duplicated values can diverge, so consistency rules and update paths must be specified Correct answer.
  3. The design violates the requirement to use a relational database
  4. The tables will consume more storage than the project budget allows

Explanation

Duplicating derived data trades consistency risk for read performance, so the design must define how all copies stay synchronized and what happens on partial failure. Storage cost, database paradigm, and presentation-layer calculation are separate concerns that do not capture the core risk.

Question 39Requirements, Specification, and Design

A requirements workshop produces conflicting statements from sales and finance about who may approve a discount. What is the most appropriate next step in the specification process?

  1. Write both rules into the specification and let developers decide at build time
  2. Choose the sales position because sales owns the customer relationship
  3. Defer the entire discount feature until a later release
  4. Record both positions, identify the decision authority, and resolve the conflict into a single specified rule Correct answer.

Explanation

Conflicting requirements must be surfaced and resolved by the appropriate decision authority so the specification contains one unambiguous rule. Letting one department win by default or pushing ambiguity to developers produces inconsistent behavior, and deferral avoids rather than resolves the conflict.

Question 40Requirements, Specification, and Design

Which statement best explains why a design document should record rejected alternatives alongside the chosen approach?

  1. It satisfies a documentation checklist required for project closure
  2. It preserves the reasoning and constraints behind the decision so future changes can be evaluated without repeating analysis Correct answer.
  3. It allows developers to implement any alternative they prefer
  4. It replaces the need for a requirements specification

Explanation

Recording rejected options captures the constraints and trade-offs that drove the decision, so later teams can judge whether a change in circumstances justifies revisiting it. It is not mere compliance, does not authorize arbitrary implementation choices, and never substitutes for requirements.

Question 41Requirements, Specification, and Design

A team is defining acceptance criteria for a feature that must handle concurrent edits to the same record. Which criterion is best formed?

  1. When two users save the same record, the later save is rejected with a conflict notice and the first user's data is preserved Correct answer.
  2. The system handles concurrent edits gracefully and without data loss
  3. Concurrent editing should work well under normal load conditions
  4. The feature supports multiple users editing records at the same time

Explanation

A testable criterion names the trigger, the observable behavior, and the outcome for each party, which this option does. The others use qualitative words like gracefully, well, and supports without defining observable results, so no test can confirm compliance.

Question 42Requirements, Specification, and Design

A specification requires that a nightly batch reconcile 500,000 records within a four-hour window on current infrastructure. Which analysis should design perform first to determine feasibility?

  1. Confirm that the batch language supports scheduled execution
  2. Ask the vendor whether four hours is a typical window
  3. Estimate per-record processing cost and parallelism needed to meet the window, then identify the bottleneck Correct answer.
  4. Move the reconciliation to a real-time stream to avoid the window

Explanation

Feasibility depends on the arithmetic of throughput: records divided by available time gives the required rate, which must be compared with achievable per-record cost and parallelism. That analysis exposes the bottleneck. Language capability, vendor norms, and redesign all presuppose the quantitative result.

Question 43Requirements, Specification, and Design

Two requirements conflict: one mandates that all customer data remain in a specific region, and another requires a global search index for sub-second queries. Which approach best resolves the design tension?

  1. Store all data globally and rely on contractual terms to satisfy the residency requirement
  2. Duplicate the full dataset in every region to guarantee both goals
  3. Abandon the latency target because residency always outranks performance
  4. Determine which data the search index must contain and whether a region-local index can satisfy the latency target Correct answer.

Explanation

The conflict may dissolve once the actual data needed in the index and the real latency distribution are examined; a region-local index might meet both goals. Contractual terms do not change technical data location, residency does not automatically outrank performance, and full duplication in every region likely worsens the residency problem.

Question 44Requirements, Specification, and Design

A design review notes that a service's public API exposes internal database identifiers as its primary keys. Why is this a significant design concern?

  1. It makes the API responses larger than necessary in all cases
  2. It couples external consumers to internal storage details, making later schema changes breaking changes Correct answer.
  3. It prevents the service from using a relational database at all
  4. It violates the requirement that APIs use JSON encoding

Explanation

Exposing internal identifiers turns a storage decision into a public contract, so any future change to key generation or schema becomes an externally visible breaking change. Response size, database paradigm, and encoding format are separate matters that do not capture the coupling risk.

Question 45Requirements, Specification, and Design

A regulated client requires evidence that every mandatory control in a security standard is implemented and tested. Which combination of artifacts best provides that evidence?

  1. A statement in the project charter that security is a priority
  2. A test report showing that penetration testing was performed once before launch
  3. A design document listing security patterns with no reference to individual controls
  4. A requirement per control, each traced to its implementing design element and its verifying test result Correct answer.

Explanation

Auditable evidence requires bidirectional linkage: each control stated as a requirement, mapped to the design element that implements it, and mapped to a test that demonstrates it works. Pattern lists, one-time testing, and charter statements do not show per-control implementation and verification.

Question 46Requirements, Specification, and Design

In a Glacier Fabricant requirements specification, which characteristic distinguishes a functional requirement from a non-functional requirement?

  1. A functional requirement applies only to user-facing screens, while a non-functional requirement applies only to back-end batch processes.
  2. A functional requirement must be testable, while a non-functional requirement is descriptive guidance that is exempt from verification.
  3. A functional requirement describes a behavior the solution must perform, while a non-functional requirement constrains qualities such as performance, security, or availability. Correct answer.
  4. A functional requirement is always written by the business sponsor, while a non-functional requirement is always written by the technical architect.

Explanation

Functional requirements state what the system must do, expressed as behaviors, inputs, and outputs. Non-functional requirements constrain how well it must do them, covering quality attributes such as response time, uptime, and access control. Both types must be verifiable, so testability is not a distinguishing factor.

Question 47Requirements, Specification, and Design

A requirements analyst is drafting a specification for a Glacier Fabricant delivery. Which practice produces the most verifiable requirement statements?

  1. Describe each requirement as a goal the team should aim to achieve where feasible.
  2. Leave thresholds open so implementers can choose values during construction.
  3. Phrase each requirement with a single measurable criterion and a defined condition of satisfaction. Correct answer.
  4. Combine related behaviors into one compound statement so the document stays short.

Explanation

Verifiability depends on a requirement having one clear, measurable condition that a tester can confirm. Compound statements hide multiple obligations and make pass or fail ambiguous. Goals and open thresholds cannot be objectively tested, so they belong in vision or guidance material rather than the specification.

Question 48Requirements, Specification, and Design

During design of a Glacier Fabricant solution, the architect must decide how the system will authenticate users across several internal applications. Which artifact is the most appropriate place to record that decision and its rationale?

  1. The project risk register, listing authentication as an open risk pending resolution.
  2. The user acceptance test plan, describing the login scenarios that will be executed.
  3. The requirements traceability matrix, mapping authentication requirements to test cases.
  4. The architecture decision record, capturing the chosen authentication approach, the context, and the alternatives considered. Correct answer.

Explanation

An architecture decision record is the standard home for a significant design choice together with its context, rationale, and rejected alternatives. It preserves the reasoning so future maintainers understand why the approach was chosen. The other artifacts reference or test the decision but do not capture the decision itself.

Question 49Requirements, Specification, and Design

A design document for a Glacier Fabricant module specifies a service that receives an order event, enriches it with customer data, and forwards it to a fulfillment system. Which design element most directly addresses how the service behaves when the fulfillment system is unavailable?

  1. A deployment diagram showing the physical servers hosting the service.
  2. A class model listing the attributes of the order and customer entities.
  3. A defined failure mode with a retry policy, a dead-letter destination, and an alert threshold. Correct answer.
  4. A data flow diagram showing the enrichment step between the two systems.

Explanation

Resilience to a downstream outage is a behavioral design concern, so the design must state the failure mode and how it is handled. A retry policy, dead-letter destination, and alert threshold make the failure handling explicit and testable. Structural diagrams show components and data but do not specify outage behavior.

Question 50Requirements, Specification, and Design

A Glacier Fabricant team is decomposing a large solution into design components. Two candidate decompositions are proposed: one organized around business capabilities and one organized around technical layers. Which criterion most strongly supports choosing the capability-oriented decomposition?

  1. It removes the need for non-functional requirements in the specification.
  2. It eliminates the need for interface specifications between components.
  3. It aligns component boundaries with changes in business rules, so a change to one capability affects fewer components. Correct answer.
  4. It guarantees lower infrastructure cost because fewer servers are required.

Explanation

Decomposition quality is judged largely by how well boundaries localize change. Capability-oriented components tend to confine changes in business rules to a single component, reducing ripple effects across the design. Cost, interface definition, and non-functional requirements remain relevant regardless of how components are organized.