1: パッケージ・ソフトウェアがバージョンアップされたのでテストした後にリリースしました。その後、ユーザが使用するPCにそのクライアント・ソフトウェアをインストールすると、既存のアプリケーションが正しく動作しないことがわかりました。根本原因を調査するのは、どのITILプロセスでしょうか？
1-1: 変更管理
1-2: リリース管理
1-3: 問題管理
1-4: 構成管理
2: 可用性マネージャがレポートすることは、以下のどれですか？
2-1: 変更によって起きたインシデント数
2-2: アプリケーションの応答時間
2-3: インパクト分析レポート
2-4: 特定のタイプの故障の前兆
3: 構成管理データベース(CMDB)のどの属性が、“あるITコンポーネントと対応づく設計書がどれか”を識別するのに役立つでしょうか？
3-1: カテゴリ
3-2: 受入日
3-3: ステータス
3-4: 関係
4: キャパシティマネージャが行うべき活動は次のうちどれでしょう？
4-1: インシデントと問題のうちパフォーマンスに関連するものに対して、その解決策を提言すること
4-2: 顧客への課金の手順を明確化すること
4-3: ITサービスプロバイダとOLAの交渉をし、合意すること
4-4: 危機が発生したときに、適切な復旧設備の利用を発動すること
5: 顧客とSLAの合意を結ぶ際、ITサービスを提供する側を何と呼ぶか？
5-1: サプライヤ
5-2: ITサービスプロバイダ
5-3: ユーザ
5-4: システムインテグレータ
6: インシデントによって、あるITサービスが停止し顧客の事業活動が行えなった場合に、回復に費やせる時間を検討する上での尺度を指す用語として、以下のどの用語が最も適当ですか？
6-1: インパクト
6-2: 緊急度
6-3: 優先度
6-4: 技術的重大度
7: あなたはどこですべてのITサービスの概要を見つけることができますか?
7-1: サービスウィンドウ
7-2: サービスカタログ
7-3: OLA
7-4: SLA
8: サポート時間についての顧客との交渉は、どのITILプロセスで行われるでしょうか？
8-1: ITサービス継続性管理
8-2: サービスデスク
8-3: インシデント管理
8-4: サービスレベル管理
9: ユーザのクライアント・ソフトウェアがフリーズしました。数日前に彼の同僚にも起きています。ユーザはサービスデスクに報告しました。ここで起きているのは、次のどれですか？
9-1: インシデント
9-2: 問題
9-3: 既知のエラー
9-4: 根本原因
10: アップタイムを表すのに最も適当な単位は以下のどれでしょうか？
10-1: 平均故障間隔(MTBF)
10-2: 平均修理時間(MTTR)
10-3: 変更システムインシデント間隔(MTBSI)
10-4: サポート時間
11: 新しいアプリケーションを開発し、ユーザが使用するPCにそのクライアント・ソフトウェアをインストールしたことにより、既存のアプリケーションが正しく動作しなくなっていないか監視するのは、どのITILプロセスでしょうか？
11-1: 変更管理
11-2: リリース管理
11-3: 問題管理
11-4: 構成管理
12: 変更管理が承認しなければならないものはどれか？
12-1: ユーザからの問い合わせのエスカレーション
12-2: インシデントの記録
12-3: 追跡ユーザからの障害連絡の受け付け
12-4: 異なるフロアへのプリンタの移設
13: インシデントではないものはどれか？
13-1: ディスクの障害
13-2: アプリケーションプログラムの不良
13-3: サービス利用の申請
13-4: マニュアルの改善要望
14: セキュリティ管理の完全性という用語の説明はどれですか？
14-1: 不正なアクセスからデータが保護されること
14-2: データが許可無く変更されないよう保護されること
14-3: 正当なユーザが必要な時にアクセスできること
14-4: データを暗号化すること
15: インシデントによって、ITサービスを回復するのに必要と予想される技術的な複雑さ、技術リソースへの影響などを指す用語として、以下のどの用語が最も適当ですか？
15-1: インパクト
15-2: 緊急度
15-3: 優先度
15-4: 技術的重大度
16: どのITILの過程がデータへの不正アクセスを防ぐ際に責任を持っていますか?
16-1: ITサービス継続性管理
16-2: 有用性管理
16-3: リリース管理
16-4: セキュリティ管理
17: エンド・ユーザから連絡のあった障害の調査やサービスの復旧を行うのは、どのITILプロセスまたは機能でしょうか？
17-1: 問題管理
17-2: インシデント管理
17-3: 構成管理
17-4: リリース管理
18: Known Errorは何ですか?
18-1: 原因が知られていて、ワークアラウンドが特定された問題
18-2: 決議されている問題
18-3: 頻出する大問題
18-4: 合わせることができない問題
19: 問題の優先度を決定するのは、以下のどの活動ですか？
19-1: 問題コントロール・プロセスの問題の識別と記録
19-2: 問題コントロール・プロセスの問題の分類
19-3: エラー・コントロール・プロセスのエラーの識別と記録
19-4: エラー・コントロール・プロセスのエラーの評価
20: キャパシティ管理において、現在の構成が個々のコンポーネント障害にいかに影響されやすいかを表す用語はどれか？
20-1: 需要管理
20-2: 復旧オプション
20-3: リスク管理
20-4: 対障害弾力性
21: ITインフラストラクチャのサービス性に関する能力を把握し、必要な改善措置を行うのは、どのITILプロセスまたは機能でしょうか？
21-1: 可用性管理
21-2: サービスレベル管理
21-3: リリース管理
21-4: ITサービス継続性管理
22: キャパシティマネージャが行うべき活動は次のうちどれでしょう？
22-1: 新しい技術の妥当性を、パフォーマンスとコストの観点で評価すること
22-2: IT部門の予算を管理すること
22-3: 提供している既存サービスのカタログを作成すること
22-4: 要求されたITサービスの可用性レベルのコストが正当であることを確認する
23: 変更諮問委員会(CCB)は、インパクトの大きな変更要求(RFC)に関係するすべてのITコンポーネントはどれかを知りたいと思いました。どこからその情報を入手できますか？
23-1: キャパシティ管理データベース(CDB/CMD)
23-2: 構成管理データベース(CMDB)
23-3: 可用性管理データベース(AMDB)
23-4: 既知のエラー・データベース
24: 資産の価値、資産に対する脅威、脅威に対する資産の脆弱性を分析する活動はどれでしょう？
24-1: 需要管理
24-2: リスク分析
24-3: チューニング
24-4: アプリケーション・サイジング
25: 構成管理のコントロールの例はどれですか？
25-1: 構成アイテム(CI)であるソフトウェアのライセンスを管理すること
25-2: RFCの変更が実装されたソフトウェアやハードウェアをリリースすること
25-3: RFCの変更による事業やITパフォーマンスに対するインパクトを評価すること
25-4: リリースするソフトウェアを保管すること
26: 請負契約(UC)の説明として適切なものはどれか？
26-1: SLAを実現するための内部のIT部門との契約
26-2: SLAを実現するための外部サプライヤとの契約
26-3: ITサービスプロバイダと顧客の間の文章化された合意であり、重要なサービス目標値と両当事者の責任を定義したもの
26-4: サポート時間と延長に関する取り決め
27: サービス時間についての顧客との交渉は、どのITILプロセスで行われるでしょうか？
27-1: サービスレベル管理
27-2: 可用性管理
27-3: キャパシティ管理
27-4: ITサービス継続性管理
28: 変更管理プロセスで、どの役割が結局、全過程に原因となりますか?
28-1: 変化諮問委員
28-2: ITマネージャ
28-3: 変化マネージャ
28-4: 変化コーディネータ
29: サービスデスクは設置場所によっていくつかのモデルに分解できます。ユーザ内あるいはユーザに比較的近いところで業務を行うサービスデスク機能を提供するのはどれか？
29-1: ローカルサービスデスク
29-2: 中央サービスデスク
29-3: バーチャルサービスデスク
29-4: リモートサービスデスク
30: セキュリティ管理の機密性という用語の説明はどれですか？
30-1: 不正なアクセスからデータが保護されること
30-2: データが許可無く変更されないよう保護されること
30-3: 正当なユーザが必要な時にアクセスできること
30-4: データを暗号化すること
31: 開発中のITサービスのレスポンスがSLAに記載された達成基準に達していないので、達成できるように改善することにしました。この活動を何と呼ぶでしょう？
31-1: 需要管理
31-2: リスク分析
31-3: チューニング
31-4: アプリケーション・サイジング
32: 構成ベースラインの説明として適切なものはどれか？
32-1: 日々の構成管理データベースのバックアップ
32-2: 運用開始前の構成管理データベースのバックアップ
32-3: 特定の時点におけるＣＩのスナップショット
32-4: ＩＴサービス運用開始前の構成管理データベースのステータス
33: ITサービスの利用料についての顧客との交渉は、どのITILプロセスで行われるでしょうか？
33-1: サービスレベル管理
33-2: ITサービス継続性管理
33-3: サービスデスク
33-4: ITサービス財務管理
34: 問題コントロール・プロセスからエラー・コントロール・プロセスへ引き継がれないケースは以下のどれですか？
34-1: ユーザへのトレーニング不足
34-2: ソフトウェア・コンポーネントの誤った出力
34-3: ハードウェアの異常な振る舞い
34-4: ネットワークの異常輻輳
35: 問題のカテゴリを決定するのは、以下のどの活動ですか？
35-1: 問題コントロール・プロセスの問題の識別と記録
35-2: 問題コントロール・プロセスの問題の分類
35-3: エラー・コントロール・プロセスのエラーの識別と記録
35-4: エラー・コントロール・プロセスのエラーの評価
36: サービスデスクの業務の例と適切なものはどれか？
36-1: プリンタトナーなどの消耗品の要求を受け付ける
36-2: インシデントの調査と診断をする
36-3: インシデントの未知の根本原因を明らかにする
36-4: 変更要求を承認する
37: ダウンタイムを表すのに最も適当な単位は以下のどれでしょうか？
37-1: 平均故障間隔(MTBF)
37-2: 平均修理時間(MTTR)
37-3: 変更システムインシデント間隔(MTBSI)
37-4: サポート時間
38: 一般的に混乱しやすく、失敗しがちなことが多いため、適用回数は最小限にとどめることが推奨される変更は何か？
38-1: 緊急変更
38-2: 標準変更
38-3: 軽微な変更
38-4: 深刻な変更
39: 構成管理データベース(CMDB)のどの属性が、“あるITコンポーネントが稼働するサーバ(ハードウェア)がどれか”を識別するのに役立つでしょうか？
39-1: カテゴリ
39-2: 受入日
39-3: ステータス
39-4: 関係
40: 変更要求(RFC)を出すことのできないITILプロセスはどれか？
40-1: 問題管理
40-2: 構成管理
40-3: ITサービス継続性管理
40-4: サービスレベル管理