AP25 — SLA, Incident, Problem, Change, and Release Management
SLA, SLO and SLI, availability and allowed-downtime math, incident vs problem management, and change and release flow for AP Subject A, with an outage case and five original questions.
AP Subject A · Installment 25 · 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
- Revised / sources checked: 2026-10-21
- Exam basis: 2026 IPA Applied Information Technology Engineer Examination Syllabus Ver.7.2. Proposals and review materials for 2027 or later are excluded.
Learning index
PDF pages and printed footer pages use different numbering systems.
- PDF 90 / printed 86: service management, ITIL, SLA/SLO/SLI, availability, reliability, service hours, and response time
- PDF 91 / printed 87: defining, agreeing, documenting, and managing service levels; periodic monitoring, review, and reporting
- PDF 92 / printed 88: change policy; RFC recording, classification, priority, assessment, approval, build, test, rollback, CAB, and PIR
- PDF 93 / printed 89: service design/transition, release/deployment, and incident recording, classification, priority, escalation, resolution, closure, and major incidents
- PDF 94 / printed 90: problem trends, root cause, prevention, known errors, workarounds, availability requirements/targets/monitoring/investigation, and MTBF/MTTR
Shared terminology table
| English | 한국어 | 日本語 |
|---|---|---|
| service-level agreement (SLA) | 서비스 수준 협약(SLA) | サービスレベル合意書（SLA） |
| service-level objective (SLO) | 서비스 수준 목표(SLO) | サービスレベル目標（SLO） |
| service-level indicator (SLI) | 서비스 수준 지표(SLI) | サービスレベル指標（SLI） |
| service-level management (SLM) | 서비스 수준 관리(SLM) | サービスレベル管理（SLM） |
| availability | 가용성 | 可用性 |
| incident | 인시던트 | インシデント |
| problem | 문제 | 問題 |
| known error | 알려진 오류 | 既知の誤り |
| workaround | 우회책 | 回避策 |
| request for change (RFC) | 변경 요청(RFC) | 変更要求（RFC） |
| change advisory board (CAB) | 변경 자문 위원회(CAB) | 変更諮問委員会（CAB） |
| post-implementation review (PIR) | 구현 후 검토(PIR) | 実施後レビュー（PIR） |
| release and deployment | 릴리스 및 배포 | リリース及び展開 |
| mean time between failures (MTBF) | 평균 고장 간격(MTBF) | 平均故障間隔（MTBF） |
| mean time to repair (MTTR) | 평균 수리 시간(MTTR) | 平均修復時間（MTTR） |
1. SLA and recurring SLM
An SLA is the agreement document identifying the service and agreed performance. An SLO is a target within it, while an SLI is a measurement of actual service. For example, “99.9% monthly availability” can be an SLO and observed monthly availability an SLI. SLM is not just a document: it is the recurring activity of defining, agreeing, documenting, and managing service levels, then periodically monitoring, reviewing, and reporting performance against targets.
2. Availability formula and worked calculation
This article explicitly uses the following measurement convention:
Availability = (agreed service time - counted downtime) / agreed service time × 100
For 30 days of 24×7 service, agreed service time is 30×24=720 hours. With three hours of counted unplanned downtime, uptime is 720-3=717 hours, and actual availability is 717/720×100=99.5833...%, or 99.58% to two decimal places.
A 99.9% SLO permits 720×(1-0.999)=0.72 hours=43.2 minutes of downtime. Actual downtime is 180 minutes, exceeding the allowance by 180-43.2=136.8 minutes. Thus 99.58% misses the 99.9% target. Treatment of planned or excluded time in the numerator and denominator must follow the SLA and remain consistent across reporting periods.
3. Incident and problem
Incident management aims to restore normal service quickly and limit business impact. Record and classify the incident; prioritize it using both impact and urgency; escalate when needed; resolve or work around it; confirm recovery; and close it. Restoration may precede proof of root cause.
Problem management analyzes incident trends and root causes to prevent occurrence or recurrence. Until a cause can be removed, it may document a known error and workaround. A permanent fix that requires a change follows change policy. Incident restoration and problem prevention are linked, but they are not the same activity.
4. Change, release, and deployment
Change management records and classifies an RFC, sets its priority, and assesses risk, business benefit, feasibility, and financial impact. The defined authority or CAB approves it; build and testing follow, together with a rollback plan and rollback testing. Where the organization’s process defines it, a PIR checks outcomes and improvements.
Release/deployment management packages and plans approved, tested changes, places them in the live environment, monitors and reviews success or failure, and shares release information. Approval is not deployment.
5. Concrete case: checkout API outage
Suppose a fictional store’s checkout API stops. Because customer impact is broad and lost sales are immediate, the incident team rates both impact and urgency high, assigns high priority, and escalates. It fails over to a standby, restores service, and records and communicates actions and status.
The problem investigation then identifies connection-pool exhaustion as the root cause and documents a known error and the temporary workaround “cycle an instance before the threshold.” An RFC proposes configuration and code changes. Change management assesses risk, benefit, feasibility, and cost and obtains authorization, then builds and tests the change and prepares and tests a rollback procedure. The release team deploys the approved, tested change, monitors indicators, and reviews and shares the result. The case contains no real personal data.
6. Original four-choice questions
Q1
Under the convention above, what is correct when counted downtime is three of 720 hours and the SLO is 99.9%?
- ア Availability is 99.90%, the target is met, and allowed downtime is 180 minutes.
- イ Availability is 99.58%, the target is missed, and allowed downtime is 43.2 minutes.
- ウ Availability is 99.42%, the target is missed, and allowed downtime is 72 minutes.
- エ Availability is 99.58%, the target is met, and allowed downtime is 136.8 minutes.
Answer: イ (2). ア confuses the observed value with the allowance. イ correctly calculates 717/720 and 720×0.001. ウ gets both availability and allowance wrong. エ has the observed value but gets the result wrong and mistakes the 136.8-minute excess for the allowance.
Q2
What is the most appropriate action immediately after the checkout API fails?
- ア Delay restoration until the root cause is proven.
- イ Immediately deploy an unapproved permanent code change to production.
- ウ Restore by failover/workaround under incident management, then open a problem record and perform RCA.
- エ Close the incident and do not investigate the cause.
Answer: ウ (3). ア conflicts with rapid restoration. イ bypasses change control. ウ has the correct order of restoration and later root-cause analysis. エ discards the opportunity to prevent recurrence.
Q3
How should priority be determined when a broad checkout outage causes immediate business loss?
- ア Assess both impact and urgency, assigning high priority and escalation.
- イ Use arrival order only.
- ウ Assess impact only after the root cause is known.
- エ Give every incident the same priority.
Answer: ア (1). ア reflects both broad impact and immediate loss. イ ignores business impact. ウ incorrectly requires completed RCA before recovery prioritization. エ prevents differentiated response.
Q4
Which sequence from change to deployment is correct?
- ア Deploy first and record an RFC only if it fails.
- イ Once the RFC is approved, deploy immediately without testing.
- ウ Build, skip assessment and approval, and release.
- エ Assess and authorize the RFC, build/test and prepare rollback, then release/deploy and monitor/review.
Answer: エ (4). ア postpones recording, assessment, and approval. イ confuses approval with testing and deployment. ウ omits risk, benefit, feasibility, financial assessment, and approval. エ preserves the boundary between controlled change and release.
Q5
Which statement correctly relates SLA and SLM?
- ア SLA is a measurement and SLM is a target.
- イ SLA is the agreement document; SLM is the ongoing activity of agreement, monitoring, review, and reporting.
- ウ Both SLA and SLM are one-time deployment approvals.
- エ SLM is root-cause analysis performed only during outages.
Answer: イ (2). ア also confuses SLI and SLO. イ correctly distinguishes the document from recurring management. ウ confuses service-level management with change/release. エ incorrectly reduces SLM to problem management.
All questions are original. No IPA past-exam question was used, translated, or adapted.
Boundary, official sources, and disclaimer
Security incident response, audit, and internal control belong to AP26 and are distinct from this service-management incident workflow.
- IPA, Applied Information Technology Engineer Examination (Level 3) Syllabus Ver.7.2 — checked 2026-10-21
- IPA, examination guidelines and syllabus overview — checked 2026-10-21
- IPA, examination guidelines and syllabus changes — checked 2026-10-21
This material is not affiliated with or endorsed by IPA. It does not guarantee learning, passing, or any examination result.