AP Subject A 37 — Cross-domain technical diagnostic: performance, DB, networks, security, availability and retries

Based on the 2026 IPA Applied Information Technology Engineer Examination (AP), Subject A, Syllabus Ver.7.2; checked 2026-10-22. This is independent study material from Motitory: it is not affiliated with, reviewed or endorsed by IPA. All five questions below are unofficial Motitory originals; no IPA past question is used or adapted. The numbers in the scenarios are fictional inputs chosen for practice, not official reference values.

Study index

1. How to use this diagnostic and its limits
2. Coverage map
3. Worked example units and dependency boundaries
4. Q1 Cache and page faults
5. Q2 Search comparisons and index IO
6. Q3 CIDR TLS authentication and authorisation
7. Q4 End-to-end availability and shared power
8. Q5 Retry transactions and idempotency
9. Cross-question error patterns
10. Self-check and review plan
11. Official sources and revision history
12. Place within AP33–38

1. How to use this diagnostic and its limits

This article teaches no new concepts. It mixes two or three domains from already published installments into each question, to expose the mistakes that happen at domain boundaries: unit conversion, confusing cost units, confusing trust boundaries, shared dependencies, and retries versus atomicity. It does not summarise AP1–36 either. If a concept feels shaky, follow the links in each choice’s rationale.

Five questions do not predict a pass. A five-item sample cannot tell you whether you will pass, whether you are ready for the exam, or whether you have mastered the whole of Ver.7.2. Getting all five right does not mean “ready”, and getting some wrong does not mean “failing level”. Use the result only to choose which installments to revisit.

Suggested use:

1. Work each question through to the end on paper without looking at the reasoning (no target time is set).
2. Write one line on why you chose your answer. If the answer is right but the reason is wrong, record it as wrong.
3. In the rationale, check why the choices you did not pick are wrong too.
4. Mark your mistakes in the error-pattern table in section 9 and review the linked installments following the plan in section 10.

2. Coverage map

Each row lists the syllabus items a question touches; the five questions do not exhaust these items.

Question	IPA Syllabus Ver.7.2 hierarchy	Linked installments
Q1	大分類2：コンピュータシステム／中分類3：コンピュータ構成要素／2. メモリ／（5）メモリの容量と性能, 大分類2：コンピュータシステム／中分類5：ソフトウェア／1. オペレーティングシステム／（7）記憶管理	AP7, AP9
Q2	大分類1：基礎理論／中分類2：アルゴリズムとプログラミング／2. アルゴリズム／（2）代表的なアルゴリズム／①整列・併合・探索のアルゴリズム, 大分類3：技術要素／中分類9：データベース／4. トランザクション処理／（4）データベースの性能向上	AP5, AP6, AP13, AP14, AP32
Q3	大分類3：技術要素／中分類10：ネットワーク／3. 通信プロトコル／（1）プロトコルとインタフェース／③ ネットワーク層のプロトコル, 大分類3：技術要素／中分類11：セキュリティ／1. 情報セキュリティ／（8）情報セキュリティに関する技術／③ 利用者認証・⑤ 公開鍵基盤	AP16, AP17, AP18, AP19, AP20, AP21
Q4	大分類2：コンピュータシステム／中分類4：システム構成要素／2. システムの評価指標／（2）システムの信頼性特性と評価／②信頼性指標と信頼性計算, 大分類6：サービスマネジメント／中分類15：サービスマネジメント／5. ファシリティマネジメント／（1）ファシリティマネジメント	AP8, AP10, AP25, AP35, AP36
Q5	大分類3：技術要素／中分類9：データベース／4. トランザクション処理／（1）同時実行制御（排他制御）・（3）トランザクション管理, 大分類4：開発技術／中分類12：システム開発技術	AP10, AP15, AP22, AP23, AP35

Exam terms that come up: 実効アクセス時間 (effective access time), ページフォールト (page fault), 二分探索 (binary search), B木インデックス (B-tree index), サブネットマスク (subnet mask), サーバ証明書 (server certificate), 認証と認可 (authentication and authorisation), 稼働率 (availability), 単一障害点 (single point of failure), 冪等性 (idempotency), 一意性制約 (unique constraint), トランザクション (transaction).

3. Worked example units and dependency boundaries

Before the questions, here are the two habits mixed questions need, shown once with numbers that differ from the questions.

Habit 1 — put everything in one unit first. Suppose we want the mean processing time of one fictional API request. Assumptions (for this example only): application CPU work 0.4 ms, 3 DB round trips × 250 μs, and only 5% of requests call an external service for 0.02 s. Simplify by adding each term as an independent mean.

1. Pick μs as the common unit. 1 ms = 1,000 μs; 1 s = 1,000,000 μs.
2. CPU: 0.4 ms = 400 μs
3. DB: 3 × 250 μs = 750 μs
4. External call: 0.02 s = 20,000 μs; expected value 0.05 × 20,000 = 1,000 μs
5. Total: 400 + 750 + 1,000 = 2,150 μs = 2.15 ms

Adding bare numbers such as 0.4 + 750 + 0.02 without converting gives a meaningless value. And the intuition “it only happens 5% of the time, so ignore it” cannot be trusted until you multiply by the size: here the 5% term is almost half of the total.

Habit 2 — draw the dependency boundary. Fictional setup: two application servers behind one load balancer, both using the same single DB. List what must all be up for a request to succeed.

[load balancer] → ( [app server 1] or [app server 2] ) → [DB]
   required           either one is enough            required

• In series (required): load balancer, DB
• In parallel (one is enough): the two app servers
• Look for hidden shared dependencies: if both app servers share the same rack power, the same switch, or the same configuration rollout, the “parallel” part merges back into one at that point.

With this picture you can see, without any numbers, that “we added app servers, so the whole system became that much more robust” may be wrong. No availability is computed here; you will do that yourself in Q4.

4. Q1 Cache and page faults

Scenario (fictional). A program makes 1,000 memory references. Assume the following simplified additive model:

• 90% of references hit the cache and take 2 ns.
• The other 10% miss the cache and take 80 ns (including the main-memory access).
• Independently of that, 0.1% of all references incur an additional page-fault penalty of 8 ms.

Under this model, which statement about the mean access time per reference, and its interpretation, is correct?

A. 9.8 ns. Page faults are rare at 0.1%, so they hardly affect the mean.

B. 8,009.8 ns. Under these assumptions the rare page-fault term makes up most of the mean. The conclusion holds only within the stated additive model.

C. 17.8 ns. Even with page faults added, the mean stays below the cache-miss time.

D. 8,000,009.8 ns, because the 8 ms page fault is added to the mean as is.

Reasoning

1. Convert to ns. 8 ms = 8 × 1,000,000 ns = 8,000,000 ns.
2. Cache-hit term: 0.9 × 2 = 1.8 ns
3. Cache-miss term: 0.1 × 80 = 8 ns
4. Page-fault term: 0.001 × 8,000,000 = 8,000 ns
5. Sum: 1.8 + 8 + 8,000 = 8,009.8 ns
6. Check with counts: of 1,000 references, 900 hits × 2 = 1,800 ns, 100 misses × 80 = 8,000 ns, 1 page fault × 8,000,000 = 8,000,000 ns. Total 8,009,800 ns ÷ 1,000 = 8,009.8 ns.
7. Interpretation: the 8,000 ns page-fault term is about 99.88% of the mean. That share comes from the question’s assumptions (a simple independent additive model with a fixed rate); it is not a general statement about real page-fault costs or frequencies.

Answer: B

• A: Wrong. It drops the page-fault term and computes only 1.8 + 8 = 9.8 ns. A small rate can still dominate the mean when the size is a million times larger. Review: AP7 (effective access time), AP9 (virtual memory and page faults).
• B: Correct. It converts units, adds the three terms as a weighted mean, and limits the interpretation to the stated assumptions.
• C: Wrong. It converts 8 ms to 8,000 ns (= 8 μs) and adds 0.001 × 8,000 = 8 ns: a unit error confusing ms with μs. Review: AP7.
• D: Wrong. It does not multiply the 8,000,000 ns page fault by its 0.001 rate, as if every reference faulted. Review: AP9, AP7.

5. Q2 Search comparisons and index IO

Scenario (fictional). Compare two lookups.

• (i) A sorted in-memory array holds 1,048,576 (= 2^20) keys. In this question the worst-case comparison count of binary search (二分探索) is counted as “the number of halvings needed to narrow 2^20 candidates down to 1”, log₂(2^20) = 20 (some conventions add one more for the final equality check; that convention is not used here).
• (ii) A B-tree index on a disk-resident table is exactly four levels deep (four page levels including root and leaf). Assume none of the relevant pages are cached and that an exact-key lookup reads one page per level.

Which statement is correct?

A. (i) needs at most 1,048,576 comparisons; (ii) needs 4 page reads.

B. (i) needs at most 20 comparisons, and since a B-tree works like binary search, (ii) also needs 20 page reads.

C. (i) needs at most 20 comparisons; (ii) needs 4 page reads. Comparisons and page I/Os are different cost units, so the numbers 20 and 4 alone do not decide which is faster.

D. (ii) at 4 is smaller than (i) at 20, so a B-tree index lookup is faster than in-memory binary search in every environment.

Reasoning

1. (i): each comparison halves the candidates. 2^20 → 2^19 → … → 2^0 = 1 takes 20 halvings. Under the question’s convention, at most 20 comparisons.
2. (ii): four levels, with the given assumptions of no cache and one page per level, gives root 1 + inner 2 + leaf 1 = 4 page reads. Comparisons to find the key inside each page also happen, but the cost unit for (ii) in this question is page reads.
3. Check the units: (i) counts “in-memory key comparisons”; (ii) counts “page I/Os”. Their per-unit costs can differ greatly, so 20 and 4 are not compared directly.
4. Check the assumptions: if upper pages are cached, actual disk reads can be fewer than 4; if the table row must be read separately, there can be more. It is not “four levels = always four I/Os”; it is four under this question’s assumptions.

Answer: C

• A: Wrong. 1,048,576 is the worst case of a linear scan from the start. Binary search over a sorted array is on the order of log₂ n. Review: AP5 (search), AP6 (complexity).
• B: Wrong. A B-tree packs many keys into one page to reduce the number of levels. The level count (4) is the page-read count; carrying binary search’s comparison count over as a page count confuses the cost units. Review: AP32 (indexes and page-access counts), AP13 (keys).
• C: Correct. It derives each value under its own assumptions and units, and says the units differ.
• D: Wrong. It compares numbers in different units by size alone and draws a universal conclusion. The result depends on cache state, storage medium and how rows are accessed. Review: AP32, AP14 (SQL queries), AP6.

6. Q3 CIDR TLS authentication and authorisation

Scenario (fictional). An internal web application server has the address 192.0.2.130/26 (192.0.2.0/24 is a block reserved for documentation and examples; it is not routed on the public Internet). Users reach the application’s business screens in a browser over HTTPS. Follow the ordinary subnet-exercise convention (not a special case such as /31 or /32).

Which statement correctly combines the network judgement with the security design?

A. A /26 block has size 64, and the host address .130 starts the network, so the network address is .130 and the broadcast is .193. In TLS, validate the server certificate and hostname, and keep user authentication and authorisation separate.

B. Network address .128, broadcast .191, usable range .129–.190, and .130 is inside it. Because TLS encrypts the traffic, separate user authentication is unnecessary.

C. Network address .128, broadcast .191, usable range .129–.190, and .130 is inside it. Validate the server certificate and authenticate users with MFA; a user who passes MFA is then automatically allowed every function.

D. Network address .128, broadcast .191, usable range .129–.190, and .130 is inside it. In TLS, validate the server certificate and hostname to confirm the server; confirm the user with separate authentication (MFA where needed); then decide per-function permissions separately through authorisation.

Reasoning

1. /26 → host part 32 − 26 = 6 bits → block size 2^6 = 64.
2. Block boundaries in the last octet: 0, 64, 128, 192. Since 128 ≤ 130 < 192, the block is 128–191.
3. Network address = .128, broadcast = .191, usable hosts = .129–.190 (64 − 2 = 62). .130 is inside the usable range.
4. Separate the trust boundaries.
   • TLS server certificate: when validation succeeds (a chain to a trusted certification authority, validity period, hostname match), it confirms that the peer is that server and protects the traffic. It does not confirm who the user is.
   • User authentication (including MFA): confirms who this user is.
   • Authorisation: decides what the authenticated user may do. MFA is a means of authentication, not a grant of permissions.

Answer: D

• A: Wrong. It mistakes the host address for the network address. Block boundaries start at multiples of 64 (.128). The security part is right but the network judgement is wrong. Review: AP17 (subnets and CIDR), AP16 (network layer).
• B: Wrong. TLS provides server confirmation and channel protection; it does not authenticate application users. Anyone can reach the login screen through an encrypted channel. Review: AP18 (TLS), AP19 (PKI and server certificates), AP20 (user authentication).
• C: Wrong. It confuses authentication (who) with authorisation (what is allowed). Even after MFA, per-function permissions must be granted separately under least privilege. Review: AP20 (authentication and authorisation), AP21 (layered defence).
• D: Correct. The address arithmetic is right, and it keeps the three boundaries (server confirmation, user authentication, authorisation) apart. To practise the same boundary split for wireless access authentication (802.1X and so on), see AP34; it does not replace the links above.

7. Q4 End-to-end availability and shared power

Scenario (fictional). The service needs both a compute subsystem and the power path that feeds it. For this exercise assume:

• Availability of one compute node: 0.999
• Availability of the shared power path: 0.998
• Failures of the elements are independent (an exercise assumption).

The compute tier is made into two identical nodes in parallel (one surviving node is enough), but the two nodes share the same power path. Which statement is correct?

A. With two compute nodes in parallel, 1 − (1 − 0.999)^2 = 0.999999, so end-to-end availability becomes about 99.9999%.

B. The single-node end-to-end availability is 0.999 × 0.998 = 0.997002 (99.7002%); with two nodes in parallel it is 0.999999 × 0.998 = 0.997999002 (about 99.7999002%). Because the shared power stays in series, compute redundancy cannot push end-to-end availability above 0.998.

C. Both nodes are needed, so 0.999 × 0.999 × 0.998 = 0.996004998; parallelising actually lowers availability.

D. Having two nodes means the power path can also be treated as duplicated, so (1 − 0.001^2) × (1 − 0.002^2) = 0.999995000004, about 99.9995%.

Reasoning

1. Draw the dependency boundary: ( [node 1] or [node 2] ) → [shared power]. Compute is in parallel; power is in series.
2. Single node: in series, so multiply. 0.999 × 0.998 = 0.997002 = 99.7002%.
3. Compute parallel part: probability both are down (1 − 0.999)^2 = 0.001^2 = 0.000001 → parallel availability 1 − 0.000001 = 0.999999.
4. Two-node end-to-end: 0.999999 × 0.998 = 0.998 − 0.998 × 0.000001 = 0.998 − 0.000000998 = 0.997999002 ≈ 99.7999002%.
5. Compare: unavailability falls from 0.002998 to 0.002000998, but 0.002 of it belongs to the shared power and remains. The upper bound on end-to-end availability is the shared power’s 0.998.
6. Check the assumptions: independence is an exercise assumption. In reality, nodes sharing the same power, rack or deployment can fail together (common-cause failure), so even the parallel part’s 0.999999 may be optimistic.

Answer: B

• A: Wrong. It computes only the parallel part and forgets to multiply by the shared power’s 0.998, which stays in series. Review: AP8 (series and parallel availability), AP36 (facility redundancy and common causes), AP25 (what an SLA actually measures).
• B: Correct. It splits series and parallel correctly, notes that the shared dependency sets the upper bound, and states the limit of the independence assumption.
• C: Wrong. It treats a parallel tier (“one surviving node is enough”) as series (“both required”). Review: AP8.
• D: Wrong. Adding nodes does not duplicate the power path they share. There is only one power path, so the parallel formula does not apply. Review: AP36 (power paths and single points of failure), AP10 (distributed configurations), AP35 (replication and failure domains).

8. Q5 Retry transactions and idempotency

Scenario (fictional). There is an order-creation API. The client waits for a response and, on timeout, sends the same request again. Sometimes the server commits the order to the DB and sends a response, but the response is lost in the network and the client times out. When an order is created, an “order created” event must also reach the shipping system.

Which design is most appropriate for preventing duplicate orders?

A. If the client lengthens the retry interval with exponential backoff, no duplicate orders occur, even without server changes.

B. Before inserting the order, the server runs a SELECT to see whether the same request exists, and INSERTs if not. No unique constraint is defined, for performance.

C. The client sends a stable idempotency key with each request, and the DB has a unique constraint on that key. The order row and the outbox event row are committed together in one transaction; on a duplicate key, the existing order result is returned. The receiver of the event also handles duplicate delivery of the same event idempotently.

D. After committing the order, the server publishes the event to a message broker in a separate step. With a broker in place, the whole flow is guaranteed to be processed exactly once.

Reasoning (tracing choice C)

1. First request (idempotency key K1): begin transaction → INSERT order row (K1) → INSERT outbox row (event ID E1) → commit succeeds.
2. Response lost: the client times out without knowing the outcome. The DB holds one order and one event.
3. Retry (same K1): the order INSERT fails on K1’s unique constraint, or is handled as a conflict → no second order is created.
4. The server looks up the existing order by K1 and returns the same result as the first time. (Add a rule that rejects a different payload under the same key, too.)
5. The outbox relay publishes E1. If the publish acknowledgement is lost, it may send E1 again (at-least-once delivery).
6. The consumer records processed event IDs and applies E1’s effect only once if it arrives again. This does not guarantee “exactly-once delivery” end to end; it processes messages so that duplicates have the same result as a single application.

Required test matrix

Scenario	Injected condition	Expected result
Retry after lost response	Drop the response after commit, resend with the same key	1 order, 1 outbox row, both responses carry the same order result
Concurrent same-key calls	Send two K1 requests at the same time	1 order; one caller gets the existing result, possibly after waiting; no server error leaks out
Rollback before commit	Inject a failure after the order INSERT and before the outbox INSERT	Neither order nor event exists; a retry creates exactly one
Outbox redelivery	The relay publishes E1 twice	The consumer’s effect is applied once

Answer: C

• A: Wrong. Retrying is the cause of duplicates, not the fix. Backoff only reduces load; it does not stop a resend for an order already committed. Review: AP10 (distributed processing), AP22 (idempotency as a non-functional requirement).
• B: Wrong. With check-then-insert, two same-key requests can both pass the SELECT at the same time and both INSERT. Uniqueness must be enforced by a DB constraint to get one row under concurrency. Review: AP15 (concurrency control), AP13 (keys and uniqueness).
• C: Correct. It has the unique constraint, the atomic commit, the return of the existing result and idempotent consumer handling, and the test matrix above can verify it. Review: AP23 (test design including fault injection).
• D: Wrong. If the order commit and the event publish happen separately, a failure between them leaves an order with no event. A broker does not by itself guarantee end-to-end exactly-once. Review: AP15 (transaction atomicity), AP35 (distributed transactions and two-phase commit).

Answer key: Q1 B / Q2 C / Q3 D / Q4 B / Q5 C

9. Cross-question error patterns

Error pattern	What it looks like	Questions	Checking habit	Review
Unit conversion	Adding ms, μs and ns together; not multiplying by the rate	Q1 (C, D), worked example	Write the common unit before calculating; write each term as “probability × size”	AP7, AP9
Cost-unit confusion	Comparing comparisons and page I/Os as one number	Q2 (B, D)	Attach a unit (“comparisons”, “page reads”) to every number	AP5, AP32
Trust-boundary confusion	Server certificate = user authentication; MFA = authorisation	Q3 (B, C)	For each boundary, write “who is confirmed / what is allowed”	AP19, AP20
Boundary-value slip	Treating the host address as the network address	Q3 (A)	Write the block boundaries as multiples of the block size first	AP17
Missed shared dependency	Computing only the parallel part; treating a shared path as parallel	Q4 (A, D), worked example	Draw the dependency boundary and mark series and parallel first	AP8, AP36
Series/parallel misclassification	Treating a parallel tier (“one surviving node is enough”) as series (“both required”)	Q4 (C)	Before multiplying, label each block “one is enough” or “all are required”	AP8
Retry versus atomicity	Retry alone; check-then-insert; separate commits	Q5 (A, B, D)	Trace lost response, concurrent calls and mid-way failure one at a time	AP15, AP23

10. Self-check and review plan

This check is not a score or a readiness verdict. Do not estimate your chance of passing from the number of correct answers.

• I can recompute Q1’s 8,009.8 ns two ways: as a weighted mean and as a total over 1,000 references.
• I do not confuse 8 ms = 8,000,000 ns with 8 μs = 8,000 ns.
• I can say what the units of Q2’s 20 and 4 are, and under which assumptions the 4 I/Os hold.
• I can derive the network, broadcast and usable range of 192.0.2.130/26 from a blank page.
• I can say in one sentence each what a server certificate, user authentication (MFA) and authorisation confirm.
• I can recompute Q4’s 0.997002 and 0.997999002 and explain why the upper bound is 0.998.
• I can trace Q5’s lost-response scenario step by step and write the four rows of the test matrix from memory.

Targeted review plan (separate from the publishing schedule):

1. Same day: for each question you got wrong, or got right for the wrong reason, pick one installment linked in its choice rationales and redo that installment’s examples.
2. After 1 day: look only at the “checking habit” of the error patterns you marked in section 9 and redo the same questions with changed numbers (for example, Q1 with a 0.01% page-fault rate, Q4 with power availability 0.9995).
3. After 3 days: apply the two habits from the worked example (one unit, dependency boundary) to a different scenario.
4. After 7 days: redo all five questions from scratch, this time writing why each choice is wrong before checking the rationale.

11. Official sources and revision history

The scope is based on the IPA material below. The scenarios, numbers and reasoning steps in this article are Motitory’s study examples, not wording or official reference values from the IPA syllabus.

• IPA exam guidelines and syllabus overview — the IPA page publishing each exam’s syllabus as learning guidance (last updated 2026-07-10). Confirmed that 応用情報技術者試験（レベル3）シラバス（Ver.7.2） is listed. Checked 2026-10-22.
• IPA Applied Information Technology Engineer Examination Syllabus Ver.7.2 (PDF) — the basis of the coverage map in section 2. Checked against the relevant middle categories of major categories 1–4 and 6 (for example, database from printed p.37, transaction processing p.40, requirements definition p.58 and integration and testing p.68 under system development technology, facility management p.92). Checked 2026-10-22.
• IPA syllabus change information — the page for syllabus revision history and changes. Checked 2026-10-22.
• IPA 2026 exam information — the 令和8年度 (2026) exam administration page, used for exam administration details, not for scope. Checked 2026-10-22.

Revision history:

• 2026-10-22: First published. The official sources above were checked the same day.
• 2026-10-28: In the section 9 cross-question error-pattern table, Q4 C was moved out of “Missed shared dependency” and reclassified as “Series/parallel misclassification”. Q4’s question, options, answer (B) and per-option rationales are unchanged.

12. Place within AP33–38

This is the fifth installment (AP37, a diagnostic) of the fixed AP33–38 completion plan. The last installment of the series is AP38, the management and strategy diagnostic; no installments will be added after AP38. Every installment is listed in the series hub.