AZ104 問題1

あなたは、Azure AD Premium にサインアップした上で、Azure AD ドメインに参加するすべてのコンピューターのローカル管理者グループに admin1@contoso.com というユーザーを自動的に追加する予定です。 何を構成すべきですか? A.[デバイス]ブレードの[デバイスの設定] B. [MFAサーバー]ブレードの[プロバイダ] C.[ユーザー]ブレードの[ユーザー設定] D.【グループ]ブレードの[一般設定] 解説 Azure AD Premium には、Azure AD ドメインに参加するデバイスについて、ローカル管理者グループのメンバーシップを更新するオプションが用意されています。このオプションを使用するには、Azure ADの[デバイス]ブレードの[デバイスの設定]から[Azure AD 参加済みデバイスの追加のローカル管理者]を構成します。よって、Aが正解です。    

Active directory domain services

Azure AD Connectは、オンプレミスの Windows Serverにインストール可能な無償のアプリです。このアプリを実行すれば、オンプレミスの AD DSのユーザーとグループを Azure ADへ定期的にコビーできます。ユーザーのコピーは、パスワードも含めて行うことが可能です。これにより、ユーザーは AD DSとAzure ADで同じユーザー名とパスワードを利用でき、AD DSとAzure ADのそれぞれにサインインする場合、覚えるアカウントが1つで済むので利便性が向上します。   Azure AD Connectは、AD DSから Azure ADへの一方向の同期のみ可能。 Azure ADからAD DSへ同期することはできない。 AD DSユーザーのユーザー名や属性で使用できる文字の種類は、A2ure AD ユーザーで使用できる文字と比べると、かなり柔軟です。たとえば、AD DSでは「y%shida」など「%」を含むユーザー名を作成できますが、Azure ADではエラーとなります。そのため、Azure AD Connect でAD DSとAzure ADを同期するとき、AD DSのユーザー名によっては、Azure AD の厳しい文字制限によりエラーになるおそれがあります。 このようなエラーを避けるために、マイクロソフト社は Office 365 IdFix ツールを無償で提供しています。Ofice 365 IdFix ツールはWindows ベースのアプリで、AD DS のユーザーやグループをスキャンして、Azure AD と同期する際に問題となる文字を検出します。また、問題となる文字は、このツールで修正することができます。AD DSとAzure AD を連携する前に、一度、Ofice 365 […]

PMP

変更要求が発生した場合の基本手順は以下の通り。 1. インパクト調査 2. 変更マネジメント計画書に従う 「変更によるスケジュール・コスト・品質面でのインパクトを調べる」「他に問題は発生しないかの確認」をまず実施することが正解。 任意依存関係(ソフト・ロジック)とはプロジェクト・チームの意思で、任意に順序を設定できる作業の関連付けのことをいう。 また物理的な制約条件から決まってしまい、選択の余地の無い絶対的な作業の関連付けは強制依存関係(ハード・ロジック)という。 アジャイル型は、1週間~1ヶ月というような短期間で成果物を作り上げ、それを何度か反復することで最終の成果物に近づけていく手法。予測型はプロジェクト・スコープを可能な限り初期に決めて、フェーズを直列に実施するもの。反復型、漸進型はその中間的な形態。 「品質は検査ではなくプロセスで作りこむ」という基本原理を理解しているかを問う問題。「より本質」の原則の適用例。不良を発生している原因がプロセスにあるならば、プロセスを改善しない限り本質的な解決にはならない。 その作業に対する説明責任者が誰かを知る必要がある。それが書かれているのはRACIチャート(A:説明責任)。資源マネジメント計画書は資源に対する要求事項をどう満たすかの記述、リスク登録簿はリスクと対応策の記述であるから、この場合はあてはまらない。 複数フェーズのプロジェクトでは、ビジネス上の便益を確実に実現できるよう、各フェーズの初期段階でビジネス・ケースをレビューする。しかし選択肢にないので、ビジネス・ケースの構成要素の一つである費用便益分析が最も近い答となる。 プロジェクトにおけるさまざまな変更は「変更マネジメント計画書」に沿って実行する必要がある。また、どの情報をどのステークホルダーに伝えるべきかは、「コミュニケーション・マネジメント計画書」に書かれている。これらを包含する「プロジェクトマネジメント計画書」が正解となる。 「JAD(共同アプリケーション設計・開発)」は、ファシリテーション(ファシリテーション型ワークショップ)の一種で、キーとなるステークホルダーを交えて、真の要求事項を収集する手法。ユーザー側と開発側が一緒に設計・開発に取り組む試みで、問題の上司指摘ポイントへの対策になる。「インタビュー」も間違いではないが、信頼関係の構築、コミュニケーションの改善を意図するJADがより適切。 「フォーカス・グループ」は関係者を一同に集めてヒアリングする方法、「ノミナル・グループ技法」はブレーン・ストーミング+投票で、いずれも優先度は低い。 「検査より予防」という基本原理を理解しているかを問う問題。予防に適切にコストを掛けることによって全体のコストを最適化すること、すなわち品質コストの計画が必要。 プロジェクトの終結では事務終了として教訓の文書化が必要。特にパフォーマンスが悪い等の問題や課題があった場合は、今後へのフィードバックのためその重要度は大きい。 プロジェクトメンバーが許容できる行動について、明確な期待を定めた「行動規範」の不徹底が原因。なお、「行動規範」はチーム憲章に関連する。「トレーニング不足」も誤りではないが、「より具体的」の原則により「行動規範の徹底不足」を優先する。 苦情対応に対して、顧客と適切なコミュニケーションを取らなかったために、顧客は不満を解消できず、上司に連絡をしたと考えることが妥当。 プロジェクト・マネジャーの意見を主張しているので、ここはコンフリクト・マネジメントの「強制」が正解。   プロジェクトへのリスクは、不十分なリソースによってもたらされたと判断できる。追加のリソースを採用することで、リスクを回避した状況。 契約することで拘束力が出てくるため脅威を排除することが可能。契約がなく、単なるリソースの追加投入であれば軽減が優先。 「リソース不足で複雑なアプリケーションを作成できなくなる」ことがリスク。リスク対応戦略によりこのリスクはなくなったと考えるのが妥当。なお、「転嫁」はリスクそのものは全く変わらず、影響を受ける主体が第三者に変わるだけなので、あてはまらない。   協力/問題解決が正解。異なる視点からの複数の視点と洞察を考慮すると、通常、コンセンサスとコミットメントにつながる協力的な態度とオープンな対話が必要。このアプローチは、お互いに有利な状況(win-win)をもたらすことができる。 文中「優先順位」や「ビデオ会議」がキー。最も望ましい問題解決手法を問うている問題。面と向き合ってとことん議論し、お互いの合意を得る手法が有効。 クリティカル・パス上の作業を重点管理することは必要であるが、「クリティカル・パス上の作業のみ」と、限定はできない。例えば準クリティカル・パスも重要である。 スケジュールのコントロールは計画より進んでいても、遅れていても原因を調査することが肝要。選択肢中では「早い・遅いにこだわらず、計画から逸脱している作業」が最適。 各種ベースラインに限らず、プロジェクトマネジメント計画書は「変更要求が承認されたときに更新される」が原則。 最もスコープに注意を払わなくてはならない契約スタイルはFFP(完全定額契約)。理由は、スコープに曖昧さがあってコストが嵩んだ場合、請負者(受注者)が増加コスト分をすべて負担しなければならない、すなわち受注者にとってのリスクが最も高いからである。 「チーム形成活動」では、Storming(動乱期)に該当するとしている。 建設予定地を変更するということは、プロジェクト計画を変更して、リスクを取らずに避ける方法。これは回避 (Avoidance)にあたる。 転嫁は、脅威によるマイナスの影響を責任とともに第三者へ移転する方法(例:保険加入や契約書を結ぶこと)のため、問題文には該当しない。 受容は、積極的であれ消極的であれ、「プロジェクトマネジメント計画書を変更しないと決めること」であるので、これも該当しない。 積極的受容は「コンティンジェンシー計画」を準備しての受容、消極的受容は何も準備しないで受容すること。   「品質とは計画、設計、作り込みによって達成されるものであり、検査によってではない」との考え方が基本理念。品質は、検査よりも作り込み、計画重視の考え方に基づいている。