Salesforce 認定 Platform デベロッパー 1-10

do-while文は条件判定の前に必ず1回は処理が実行される構文です。
最初にxは0で初期化されますが、ループ内でx = 1が実行され、その後x++によりxは2になります。
その後、while (x < 1) の条件が評価されますが、xはすでに2のため条件はfalseとなりループは終了します。
したがってSystem.debugで出力される値は2です。
この問題はwhile文との違い、特に初回実行の有無を理解しているかを問う基本問題です。
デューフループ

Lightningコンポーネント（AuraおよびLWC）からApexを呼び出すには、Apexメソッドやプロパティに@AuraEnabledを付与する必要があります。
これによりクライアントサイドからサーバサイド処理へアクセス可能になります。
@RestResourceはREST API公開用、@RemoteActionはVisualforce向けの旧方式、@HttpInvocableは外部サービス連携用であり用途が異なります。
したがって、LightningコンポーネントとApexの連携に使用する正しいアノテーションは@AuraEnabledです。
AuraEnabled 注釈

非同期Apex（Future、Queueable、Batchなど）では、同期処理よりもガバナ制限が緩和される項目が存在します。具体的にはヒープの合計サイズ（6MB⇒12MB）、最大CPU時間（10,000ms⇒60,000ms）、およびSOQLクエリ発行総数（100⇒200）が拡張されます。
一方で、SOQLクエリで取得できるレコードの合計数（上限は5万5,000件）や、Apexトランザクションの最大実行時間は同期・非同期で変わりません。
したがって、非同期処理ではリソース消費の大きい処理を安全に実行できるよう一部制限が引き上げられる一方で、レコード件数に関する制限は不変である点が重要です。
執行の総督と制限

このコードではループ内でinsertが2回実行されますが、1トランザクション内のDML文の上限（150回）を超えると例外が発生します。
try-catchで囲まれているのは最初のinsertのみであり、後続のinsertは例外処理されません。
そのためガバナ制限に達した時点で未処理例外となり、トランザクション全体がロールバックされてすべてのレコード追加が取り消されます。
結果として、元の100件のまま変化しません。
執行の総督と制限

Salesforceのトリガー実行順序では、まずbeforeトリガーが実行され、その後にシステム検証および入力規則の再チェックが行われます。
続いて重複ルールが適用され、問題なければレコードはデータベースに保存（まだ未コミット）されます。その後にafterトリガーが実行されます。
したがって、beforeトリガーの後に検証→重複チェック→保存→afterトリガーの順序になる点が重要です。
トリガーと実行順序

レコード数が不明なコレクション（ListやSet）を処理する場合は、拡張for文（for-each構文）を使用するのが最適です。
この構文では.size()などで件数を取得する必要がなく、コレクション内の全要素を安全かつ簡潔に処理できます。
他のfor文やwhile文は件数管理や条件制御が必要となり冗長になります。
したがって、コレクション処理ではfor(variable :list_or_set)構文を使うのがベストプラクティスです。
ループのために

Apexではwith sharingやwithout sharingにより共有ルールの適用を制御しますが、内部クラスは外部クラスの共有設定を自動的には継承しません。
そのため、それぞれのクラスで明示的に指定する必要があります。
また、内部クラスと外部クラスは独立して宣言できるため、両方のクラスに対して個別にsharing設定を定義することが可能です。
この仕様はセキュリティ制御の明確化のために重要です。
共有付き、共有なし、そして継承共有キーワードを使います

共有設定の指定を省略した場合、クラスの種類によってデフォルトの振る舞いが異なります。匿名ブロック（Execute Anonymous）は実行するユーザーの権限と共有設定に自動的に従います。
一方、クラスとして定義されるトリガーやカスタムコントローラなどは、指定を省略するとwithout sharingとして扱われるのが原則です。
したがって、実行ユーザーの設定に自動的に従うのは匿名ブロックです。
共有付き、共有なし、そして継承共有キーワードを使います

スクラッチ組織は、Dev Hubを有効化した本番組織から作成・管理する必要があります。
Dev HubはSalesforce DXの中心機能であり、スクラッチ組織の作成上限や履歴を管理します。
環境ハブはリリース管理用の別機能であり、SandboxはDev Hubとは異なる仕組みです。
したがって、スクラッチ組織の導入にはDev Hubの有効化が必須です。
Dev Hub Orgを選択して有効化する

Apexテストでは外部データに依存せず、テストデータを自前で用意することが重要です。CSVファイルを静的リソースとして組織に格納し、Test.loadData()で読み込む方法が推奨されます。
この方法ではテストデータを効率的に管理・再利用できます。
HttpCalloutMocksやWebServiceTests（Test.setMockなど）は外部Webサービスコールアウトをモックするための仕組みであり、データ投入用途ではありません。
したがって、テストデータの読み込みにはCSVと静的リソースの組み合わせがベストプラクティスです。
ユニット内の組織データからのテストデータの分離 テスト