· Guides

AP Subject A 32 — AP1–32 core-map mixed diagnostic: closing the database gaps

AP Subject A diagnostic closing the AP1–32 core map on database gaps: B-tree, hash, bitmap and covering indexes, page-access cost math, GRANT/REVOKE and least privilege, with five original questions.

応用情報技術者試験科目Aデータベースインデックスアクセス制御総合診断

AP Subject A · Installment 32 · An independent study resource for the 2026 exam and Syllabus Ver.7.2. It is not affiliated with IPA and does not guarantee a pass. Open the series hub

Based on the 2026 IPA Applied Information Technology Engineer Examination, Subject A, Syllabus Ver.7.2; checked 2026-10-21. This article neither guarantees success nor claims line-by-line coverage of Ver.7.2. All examples are fictional.

Revision history: 2026-10-28 corrected the closing note. This article closes only the AP1–32 core map; the series continues through the AP33–38 completion plan and ends at AP38.

Study index

  1. Choosing indexes
  2. Performance design and measurement
  3. Access control
  4. Technical, management, and strategy connection
  5. Quick sheet and traps
  6. Five original diagnostic questions
  7. Self-check and sources

Every AP1–32 installment is listed in the public series index; as noted above, the series does not claim line-by-line coverage of Ver.7.2.

1. Choosing indexes

  • A B-tree index (B-treeインデックス) maintains an ordered structure and is commonly suitable for equality and range predicates such as =, <, and BETWEEN.
  • A hash index (ハッシュインデックス) may suit equality lookup, but does not preserve order and should not be chosen as the general answer for range search.
  • A bitmap index (ビットマップインデックス) may help combine low-cardinality columns in read-heavy analytics. Frequent updates can make concurrency and maintenance costs unattractive, depending on the product and implementation.
  • A covering index (カバリングインデックス) supplies every column needed by a query and can reduce table access. Whether access is actually avoided depends on the DBMS, plan, visibility, and cache state.

More indexes may speed reads but consume storage/cache and add maintenance to INSERT, UPDATE, and DELETE. A low-selectivity predicate can read so many rows that the index helps little. Examine predicates, ordering, joins, and the read/write mix, then validate candidates with plans and representative load. No index method has identical features or costs across all DBMSs.

2. Performance design and measurement

Independently checkable simplified calculation

Assume exactly 100 operations: 80 reads and 20 inserts. Cost means logical page accesses; waiting, cache effects, parallelism, and contention are ignored.

State Reads Inserts Total Average per operation
Before 80 × 1000 = 80,000 20 × 2 = 40 80,040 80,040 ÷ 100 = 800.4
Indexed 80 × 4 = 320 20 × 5 = 100 420 420 ÷ 100 = 4.2

In this fictional model, total cost falls from 80,040 to 420 and the average from 800.4 to 4.2, while each insert rises from 2 to 5. This arithmetic is not a latency prediction. A real system requires representative SQL/data and before/after measurements of execution plans, logical/physical I/O, p50/p95/p99 latency, throughput, lock waits, CPU, and cache state.

3. Access control

Least privilege (最小権限) gives a user only what the job needs. A fictional report_reader receives SELECT on orders, but no INSERT, UPDATE, or DELETE. An order_writer receives only necessary write privileges. Review grants periodically and revoke them after role changes or departure.

This is supplemental PostgreSQL syntax, not IPA product endorsement:

GRANT SELECT ON TABLE orders TO report_reader;
GRANT INSERT, UPDATE ON TABLE orders TO order_writer;
REVOKE UPDATE ON TABLE orders FROM order_writer;

Details of GRANT/REVOKE, role inheritance, owner/schema privileges, and DELETE notation vary by DBMS. SELECT does not imply INSERT/UPDATE/DELETE. Combine privilege separation with application-account isolation, audit logging, and secret management.

4. Technical, management, and strategy connection

  • Technical: design index candidates and a privilege matrix; verify plans and load.
  • Management: use change approval, regression testing, monitoring, periodic access review, and audit logs.
  • Strategy: set SLA and business KPIs first, then decide whether read gains justify write/storage costs and security risk. The goal is a design aligned with business objectives and risk tolerance, not merely the fastest single query.

5. Quick sheet and traps

  • Range → consider B-tree; equality → hash may be a candidate; low-cardinality/read-heavy → assess bitmap cautiously.
  • Covering means “contains needed columns,” not guaranteed zero table I/O everywhere.
  • More indexes can increase write, storage, and maintenance cost; low selectivity can reduce benefit.
  • Measure tail latency, throughput, plans, and load—not just an average.
  • SELECT and INSERT/UPDATE/DELETE are separate privileges; distinguish least privilege, GRANT, and REVOKE.
  • Beware absolutes: “always,” “every DBMS,” “more indexes are always better,” or “toy arithmetic equals measurement.”

6. Five original diagnostic questions

These are original questions, not copied or adapted from past examinations.

Q1 — Indexes

A table is often searched with ordered_at BETWEEN ... and results need date ordering. What is the best first candidate?

A. Use only an unordered hash index.

B. Consider a B-tree on ordered_at and confirm with the execution plan.

C. Create bitmap indexes on every column regardless of selectivity.

D. Create as many indexes as possible because writes are free.

Q2 — Performance arithmetic and measurement

Which statement about the 100-operation model is correct?

A. The before total is 80,400.

B. The indexed average is 42.

C. The total falls from 80,040 to 420, but real plans, latency, and load still require measurement.

D. Insert cost also falls from 2 to 1.

Q3 — Access control

A reporting account only needs to read orders. Which choice best follows least privilege?

A. GRANT only SELECT on orders; omit or REVOKE unnecessary write privileges.

B. Treat DELETE as automatically required whenever SELECT is granted.

C. Share administrator access for convenience.

D. Keep privileges forever after a role change.

Q4 — Technical and management integration

What is the best approach to introducing a new production index?

A. Check the mean once and deploy everywhere immediately.

B. Skip write regression because reads improved.

C. Assume every DBMS produces the same plan.

D. Test plans, tail latency, throughput, and write impact under representative load; prepare approval, rollback, and monitoring.

Q5 — Strategy integration

A service has an important read SLA and write spikes. What is the soundest decision method?

A. Maximize the index count as the KPI.

B. Set SLA, business KPIs, and risk tolerance; measure read gains against write, storage, and security costs.

C. Skip privilege review when an index covers a query.

D. End the investment analysis after one fast query.

Answer pattern: 2, 3, 1, 4, 2

7. Self-check and official sources

  • I can state the suitable conditions and limits of B-tree, hash, bitmap, and covering indexes.

  • I can independently recompute 80,040, 800.4, 420, and 4.2.

  • I can explain why plans, latency, throughput, and load must be measured.

  • I distinguish SELECT from three write privileges, GRANT/REVOKE, and least privilege.

  • I can connect technical, management, and strategy decisions in one explanation.

  • IPA AP Syllabus Ver.7.2 — database performance/access control, PDF pp.44–45 (printed pp.40–41)

  • IPA syllabus revision hub

  • PostgreSQL indexes, GRANT, and REVOKE — supplemental vendor documentation; implementations vary.

This closes the AP1–32 core study map, not the whole series. The next installment is AP33 Compilers and language processing; the fixed AP33–38 completion plan (AP33–36 supplements, AP37–38 mixed diagnostics) follows, and the series ends at AP38.

Back to the blog