【2024年度最新版】 Salesforce認定Development Lifecycle and Deployment アーキテクト100問（問題＋解説集）
Salesforce認定Development Lifecycle and Deployment アーキテクトで過去出題された問題より100問を抜粋して丁寧な解説と合わせて紹介します。
Salesforce認定Development Lifecycle and Deployment アーキテクト資格取得を目指す方に向けに、実践的な問題を抜粋していますので、効率的な学習のサポートを提供しています。
問題と解答だけでよい方は、こちらを参照してください。
ここから問題と解答になります。
1.Universal Containers には、複雑な展開が迫っています。デプロイには、重要な構成を保持するカスタム設定に依存するいくつかの Apex クラスが含まれます。アーキテクトはこの展開をどのように管理する必要がありますか?
A. 変更セットを使用して、本番環境でカスタム設定を手動で展開および入力します
B. Force.com 移行ツールを使用して、すべての機能の展開をスクリプト化します。
C. カスタム メタデータ タイプを作成し、これを本番環境へのデプロイに含めます。
D. Apex クラスをデプロイする前に、本番環境でカスタム設定を手動でデプロイして入力します。
正答：C
解説：
A. 変更セットを使用して、本番環境でカスタム設定を手動で展開および入力します。
変更セットではカスタム設定のデータを含めることができず、本番環境で手動入力が必要になります。これにより、手作業によるエラーが発生する可能性があります。
B. Force.com 移行ツールを使用して、すべての機能の展開をスクリプト化します。
移行ツール（ANT Migration Tool）はメタデータの移行に適していますが、カスタム設定のデータを含めることはできません。データの移行には別の方法が必要です。
C. カスタム メタデータ タイプを作成し、これを本番環境へのデプロイに含めます。
カスタムメタデータタイプはメタデータとして管理され、本番環境にデータとともにデプロイ可能です。カスタム設定のデータ管理を容易にするため、最適な選択肢です。
D. Apex クラスをデプロイする前に、本番環境でカスタム設定を手動でデプロイして入力します。
手動での設定はエラーのリスクがあり、再現性やスケーラビリティに欠けます。より自動化された手法を用いるべきです。
2.Universal Containers にはアクティブな本番組織があり、来月いくつかの新機能をリリースする予定です。チームは展開計画の準備に取り組んでおり、テクニカル アーキテクトに連絡を取り、ロールバック戦略に関する意見を求めました。
テクニカルアーキテクトは何を推奨すべきですか?
A. 本番環境からサンドボックスを作成して、既存のメタデータのバックアップを取ります。デプロイをロールバックするには、新しいコンポーネントを手動で削除してから、このサンドボックスのメタデータを使用して本番環境に再度デプロイします。
B. ANT 移行ツールを使用して、既存のメタデータをバックアップします。デプロイメントをロールバックするには、バックアップされたメタデータを使用して本番環境に再度デプロイします。
C. 本番環境からサンドボックスを作成して、既存のメタデータのバックアップを取ります。デプロイをロールバックするには、destructivechanges.xml を使用して新しいコンポーネントを削除し、このサンドボックスのメタデータを使用して本番環境に再度デプロイします。
D. ANT Migration Tool を使用して既存のメタデータをバックアップします。デプロイをロールバックするには、新しいコンポーネントを手動で削除し、バックアップされたメタデータを使用して本番環境に再度デプロイします。
正答：D
解説：
A. 本番環境からサンドボックスを作成して、既存のメタデータのバックアップを取ります。デプロイをロールバックするには、新しいコンポーネントを手動で削除してから、このサンドボックスのメタデータを使用して本番環境に再度デプロイします。
サンドボックスをバックアップとして使用する方法は、データの正確性に欠け、完全なロールバックを保証できません。特に、手動削除にはミスのリスクがあります。
B. ANT 移行ツールを使用して、既存のメタデータをバックアップします。デプロイメントをロールバックするには、バックアップされたメタデータを使用して本番環境に再度デプロイします。
この方法は一般的なバックアップ戦略として有効ですが、新しく追加されたコンポーネントの削除方法が明確ではありません。
C. 本番環境からサンドボックスを作成して、既存のメタデータのバックアップを取ります。デプロイをロールバックするには、destructivechanges.xml を使用して新しいコンポーネントを削除し、このサンドボックスのメタデータを使用して本番環境に再度デプロイします。
destructivechanges.xml は削除専用であり、完全なロールバックには適しません。また、事前に正確なリストを作成する必要があります。
D. ANT Migration Tool を使用して既存のメタデータをバックアップします。デプロイをロールバックするには、新しいコンポーネントを手動で削除し、バックアップされたメタデータを使用して本番環境に再度デプロイします。
この方法では、ANT 移行ツールを使用してメタデータをバックアップし、ロールバック時に適切な修正を加えることができます。最も確実な戦略といえます。
3.Universal Containers には、異なる地域に 7 つの組織があります。そのプロセスはグローバルで標準化されていますが、各地域には、グローバル コードを理解し、その地域に合わせていくつかの側面をカスタマイズできる柔軟性が必要です。
このニーズに最適化されている開発モデルはどれですか?
A. ロック解除済みパッケージを使用してグローバル コードを展開し、各国がカスタマイズされたロック解除済みパッケージ拡張機能を作成できるようにします。
B. グローバル コードには管理パッケージを使用し、すべての地域のコードには別の管理パッケージを使用します。
C. すべてのコードを含む一元化された Git を作成し、グローバル チームがローカル チームによる変更を承認します。
D. 管理パッケージを使用してグローバル コードをデプロイし、ローカル チームがそのパッケージ内のコードの追加を要求できるようにします。
正答：A
解説：
A. ロック解除済みパッケージを使用してグローバル コードを展開し、各国がカスタマイズされたロック解除済みパッケージ拡張機能を作成できるようにします。
ロック解除済みパッケージ（Unlocked Packages）は、各地域がカスタマイズを適用できる柔軟性を持ちつつ、グローバルな標準コードを維持するのに適した方法です。
B. グローバル コードには管理パッケージを使用し、すべての地域のコードには別の管理パッケージを使用します。
管理パッケージはロックされており、地域ごとのカスタマイズが困難です。そのため、柔軟なカスタマイズが求められるこのケースには適しません。
C. すべてのコードを含む一元化された Git を作成し、グローバル チームがローカル チームによる変更を承認します。
一元化された Git を使用することは可能ですが、ローカルのカスタマイズを適切に管理する方法が明示されていません。ロック解除済みパッケージの方が適しています。
D. 管理パッケージを使用してグローバル コードをデプロイし、ローカル チームがそのパッケージ内のコードの追加を要求できるようにします。
管理パッケージはロックされているため、ローカルの柔軟なカスタマイズができません。そのため、このアプローチは最適ではありません。
4.チームはスプリントを完了し、ビジネスの承認後にこれらの変更を展開する予定ですが、すぐに次のスプリントを開始します。
アーキテクトはどのような戦略を推奨すべきですか?
A. 開発ブランチにマージせずに、今後の変更を機能ブランチにコミットします。開発ブランチからデプロイし、新しいスプリント機能を開発ブランチにマージします。
B. Git を使用して、開発ブランチからリリース ブランチを作成します。すべての修正はリリース ブランチで行う必要があります。
デプロイ後、リリースと開発をマージします。
C. 現在のコードを UAT サンドボックスに移行します。Dev サンドボックスで新しいスプリント開発を開始します。UAT 環境で修正を行い、業務承認後に UAT を本番環境にデプロイします
D. 新しいスプリントの最初のタスクは、展開の承認でなければなりません。その後、スプリントの他のタスクは環境と Git で実行できます。
正答：C
解説：
A. 開発ブランチにマージせずに、今後の変更を機能ブランチにコミットします。開発ブランチからデプロイし、新しいスプリント機能を開発ブランチにマージします。
この方法では、開発ブランチの管理が複雑になり、新しいスプリントの変更がデプロイ前に混在してしまう可能性があります。
B. Git を使用して、開発ブランチからリリース ブランチを作成します。すべての修正はリリース ブランチで行う必要があります。デプロイ後、リリースと開発をマージします。
この方法も有効ですが、テスト環境（UAT）を活用する明確な戦略が示されていません。
C. 現在のコードを UAT サンドボックスに移行します。Dev サンドボックスで新しいスプリント開発を開始します。UAT 環境で修正を行い、業務承認後に UAT を本番環境にデプロイします。
この方法では、新しいスプリント開発を Dev サンドボックスで開始しつつ、UAT 環境で承認と修正を行うことができるため、最適な戦略です。
D. 新しいスプリントの最初のタスクは、展開の承認でなければなりません。その後、スプリントの他のタスクは環境と Git で実行できます。
展開の承認は重要ですが、それをスプリントの最初に組み込む必要はなく、継続的な開発と並行して進めるべきです。
5.Universal Containers には、複数のプロジェクトが並行して開発されています。プロジェクトの 1 つはテスト フェーズにあり、テスト チームは、運用環境にデプロイされるアイテムに関する問題のリストを発見しました。プロジェクトの締め切りが短いため、顧客チームはテスト サンドボックスで修正を行ってから本番環境にデプロイすることを提案します。
アーキテクトは何を推奨すべきですか?
A. 開発環境で問題を修正し、変更を本番環境にデプロイすることをお勧めします。
B. テスト環境で問題を修正し、変更を開発サンドボックスに移行することをお勧めします。
C. テスト環境で問題を修正し、本番環境にデプロイするという顧客チームの提案を推奨します。
D. 開発サンドボックスで問題を修正し、テストに移行し、テスト後に本番環境にデプロイすることをお勧めします。
正答：D
解説：
A. 開発環境で問題を修正し、変更を本番環境にデプロイすることをお勧めします。
テストをスキップして本番に直接デプロイすると、未検証の問題が発生するリスクがあります。
B. テスト環境で問題を修正し、変更を開発サンドボックスに移行することをお勧めします。
テスト環境での修正を開発サンドボックスに移行するのは非効率的であり、正しいフローとはいえません。
C. テスト環境で問題を修正し、本番環境にデプロイするという顧客チームの提案を推奨します。
テスト環境での直接修正は、開発環境との同期を崩し、バージョン管理が難しくなるため推奨されません。
D. 開発サンドボックスで問題を修正し、テストに移行し、テスト後に本番環境にデプロイすることをお勧めします。
この方法では、開発→テスト→本番の適切な流れを維持し、リスクを最小限に抑えられます。
6.Universal Containers では、常に 10 人の Apex 開発者が新しい機能を構築し、バグを修正しています。
開発者が他の変更を上書きするリスクを軽減するために、アーキテクトはどの分岐戦略を推奨する必要がありますか?
A. ソース管理を使用しないでください。Salesforce の組み込みの競合検出メカニズムに依存する
B. すべての開発者が同じブランチで作業し、回帰を継続的にテストします。
C. すべての開発者に新しいブランチで新しい機能を構築してもらいますが、HEAD でバグを修正します。
D. 開発者は別々のブランチで作業し、テストのために変更を共通のブランチにマージします。
正答：D
解説：
A. ソース管理を使用しないでください。Salesforce の組み込みの競合検出メカニズムに依存する
ソース管理を使用しないことは、開発者が同時に作業する環境ではリスクが高く、変更の競合や上書きが発生する可能性があります。組み込みの競合検出メカニズムに頼るのは、競合を事後的に検出するのみで、事前にリスクを管理することができません。
B. すべての開発者が同じブランチで作業し、回帰を継続的にテストします。
同じブランチで作業する方法は、競合のリスクを高め、開発者同士でのコードの衝突が頻発する可能性があります。回帰テストは重要ですが、複数の開発者が同時に作業する環境では、この戦略は適切ではありません。
C. すべての開発者に新しいブランチで新しい機能を構築してもらいますが、HEAD でバグを修正します。
新しい機能を別々のブランチで作成し、バグ修正を HEAD ブランチで行う方法は、機能の開発とバグ修正を分離するため、作業の衝突を避けやすくなります。しかし、バグ修正の頻繁な変更が問題を引き起こす可能性もあります。
D. 開発者は別々のブランチで作業し、テストのために変更を共通のブランチにマージします。
この方法は、複数の開発者が独立して作業でき、ブランチごとの競合を減らすことができるため、リスクを低減します。変更後、テストを行うために共通のブランチにマージする方法が最も効果的です。
7.Universal Containers (UC) は、Salesforce 開発に SFDX ツールと方法論を使用するハイテク企業です。T UC は、そのコードと構成の一部を Unlocked Packages に移動しました。
UC の新しいパッケージ開発戦略をサポートするために、アーキテクトが推奨する 2 つのベスト プラクティスはどれですか?
（2つ選んでください。）
A. メタデータ カバレッジ レポートを参照して、パッケージでサポートされている機能を特定します。
B. 既存のコードベースのすApex 開発戦略とベストプラクティスべてを単一のモノリシック パッケージに移動します。
C. 本番環境にインストールする前に、開発したパッケージをテスト環境でテストします
D. パッケージがすべてのコードと構成を管理するため、バージョン管理を使用する必要はありません。
正答：A,C
解説：
A. メタデータ カバレッジ レポートを参照して、パッケージでサポートされている機能を特定します。
メタデータカバレッジレポートは、パッケージ内の機能とコンポーネントが適切にサポートされているかを把握するために非常に重要です。このレポートを利用することで、パッケージの構成やコードが確実に機能することを確認できます。
B. 既存のコードベースのすべてを単一のモノリシック パッケージに移動します。
すべてを一つのモノリシックパッケージにまとめる方法は、スケーラビリティやメンテナンス性の観点からは適していません。分割されたパッケージの方が、個別に管理しやすく、更新やデプロイが効率的に行えます。
C. 本番環境にインストールする前に、開発したパッケージをテスト環境でテストします。
本番環境にリリースする前にテスト環境でパッケージを十分にテストすることは、品質確保のために非常に重要です。テスト環境での検証を行うことで、問題を事前に発見し、本番環境でのトラブルを避けることができます。
D. パッケージがすべてのコードと構成を管理するため、バージョン管理を使用する必要はありません。
バージョン管理は、複数の開発者が関与するプロジェクトでコードの変更履歴を追跡するために非常に重要です。パッケージ管理があっても、コードの変更履歴を追跡し、異なるバージョンを管理するためにバージョン管理を使用するべきです。
8.Universal Containers は、Sales Cloud の簡単な構成変更と機能強化をリリースする予定です。テクニカル アーキテクトは、変更セットの使用を推奨しています。このシナリオで変更セットが提供する利点を 2 つ選択してください。2つの答えを選択してください
A. 非常に多数のコンポーネントを簡単にデプロイできる機能。
B. 展開のためのシンプルで宣言的な方法。
C. コンポーネントへの変更を追跡する機能。
D. 関連するコンポーネントをデプロイする簡単な方法。
正答：B,D
解説：
A. 非常に多数のコンポーネントを簡単にデプロイできる機能。
変更セットは一度に複数のコンポーネントをデプロイできるものの、非常に多数のコンポーネントには適していません。多数のコンポーネントがある場合、より効率的なツール（例えば、ANTツールやSFDX）が必要です。
B. 展開のためのシンプルで宣言的な方法。
変更セットは、宣言的に設定や構成を展開できるため、テクニカルな知識が少ないユーザーでも簡単にデプロイできる方法として有効です。
C. コンポーネントへの変更を追跡する機能。
変更セット自体は変更を追跡する機能を持ちません。変更内容を追跡するには、バージョン管理や他のツールを使用する必要があります。
D. 関連するコンポーネントをデプロイする簡単な方法。
変更セットを使用することで、関連するコンポーネントを簡単にまとめてデプロイすることができます。これにより、設定が依存関係を持つコンポーネントの整合性を保ちつつ、効率的にデプロイできます。
9.Universal Containers (UC) は、いくつかの新機能のリクエストに関するフィードバックを現場から受け取りました。UC は、ビジネス目標において、フィードバックを迅速に取得し、これらのリクエストに優先順位を付ける方法を探しています。アーキテクトが推奨する 2 つのオプションはどれですか? 2つの答えを選択してください
A. 機能要求をテスト マネージャーに提出し、品質チェックを受けます。
B. センター オブ エクセレンス ミーティングで機能リクエストを提示します。
C. 年末に正式なレビューを行うために、要求を IT に送信します。
D. プロジェクト管理ツールでバックログまたは優先度リストを作成します。
E. 要求されている新機能に関する設計基準を作成します。
正答：B,D
解説：
A. 機能要求をテスト マネージャーに提出し、品質チェックを受けます。
機能要求をテストマネージャーに提出するだけでは、優先順位をつけるための情報が不足します。ビジネスの優先順位や要件に基づいて迅速にフィードバックを得ることが重要です。
B. センター オブ エクセレンス ミーティングで機能リクエストを提示します。
センター オブ エクセレンス (COE) ミーティングを活用することで、機能リクエストの優先順位を早期に共有し、ビジネスステークホルダーとともに最も重要な要求を識別できます。
C. 年末に正式なレビューを行うために、要求を IT に送信します。
年末にレビューを行うのはタイムリーではなく、迅速にフィードバックを取得する目的には不適切です。
D. プロジェクト管理ツールでバックログまたは優先度リストを作成します。
プロジェクト管理ツールを使用してバックログや優先順位リストを作成することで、リクエストの整理と管理がしやすくなり、ビジネス目標に対する優先順位を迅速に決定できます。
E. 要求されている新機能に関する設計基準を作成します。
設計基準の作成は重要ですが、最初にリクエストに優先順位をつけることが必要です。設計基準を作成するのはその後で行うべきです。
10.Universal Containers は、大規模な分散開発およびテスト チームが関与するプロジェクトを開始したばかりです。
開発チームのメンバーは要件を管理するツールにアクセスする必要があり、テスト チームは欠陥を管理するツールにアクセスする必要があります。さらに、利害関係者はアドホック ステータス レポートを要求しています。プロジェクトをサポートするためにアーキテクトが推奨するツールはどれですか?
A. ポート管理
B. コード リポジトリ
C. ウェーブ
D. スプレッドシート
正答：C
解説：
A. ポート管理
ポート管理は、IT インフラのネットワーク管理に関連する概念であり、要件管理やテスト管理には適していません。
B. コード リポジトリ
コードリポジトリ（GitHub、Bitbucket など）は、ソースコードのバージョン管理には適していますが、要件管理や欠陥追跡には適しません。
C. ウェーブ
Tableau CRM（旧称：Wave Analytics）は、リアルタイムのデータ可視化およびレポート作成に優れたツールです。これにより、開発チームとテストチームが進捗を確認でき、利害関係者向けのアドホックレポートを作成することが可能になります。
D. スプレッドシート
スプレッドシートは一時的なデータ管理には使えますが、スケールが大きいプロジェクトでは適切なツールではありません。データの一貫性やリアルタイムの可視化に課題があるため、適していません。
ここから先は
この記事が気に入ったらチップで応援してみませんか？