Multiple-Response Questions and All-or-Nothing Credit

A multiple-response question gives you five or more options and tells you exactly how many to pick: "Choose TWO", occasionally "Choose THREE". The critical fact is that AWS scores these all or nothing. Getting one of two correct earns you exactly the same as getting none of them. There is no partial credit, and there is no penalty for a wrong pick beyond losing the item. That asymmetry should change how you play them.

Why they are worth more attention than their count suggests

A multiple-choice question with four options gives a blind guess a 25% chance. A "choose TWO from five" question gives a blind guess a 10% chance, because there are ten possible pairs. If you can eliminate one option confidently you are at 1 in 6; eliminate two and you are at 1 in 3. Every elimination is worth far more here than on a single-answer question, which is why the elimination pass matters more than the selection pass.

The method

1. Read the instruction line before the options. Note the number. Candidates routinely select one answer on a "choose TWO" and move on, or select three on a "choose TWO" and have the item marked invalid by the interface. The exam software will usually stop you selecting too many, but it will not stop you selecting too few.
2. Find the constraint in the stem, exactly as you would for a single-answer question. It still governs.
3. Eliminate the impossible before you rank the plausible. Most "choose TWO" sets contain at least one option that is factually wrong — a service that does not exist in that shape, a gateway endpoint for a service that has none, a feature attributed to the wrong product. Cross those out first.
4. Look for the pairing pattern. Correct answers in these questions very often form a complementary pair: one option addresses the control-plane or identity side, the other the data-plane or content side. Two options that do the same thing by different means are rarely both correct — the writer included them as alternatives to each other.
5. Sanity-check the pair together. Ask: if I implemented both of these, would the stated requirement actually be met? If one of them makes the other redundant, you have probably picked the wrong second option.

The complementary-pair pattern in practice

Consider a stem that requires every model invocation in an account to be filtered for personal data and to be attributable to a named principal. The five options might include: attach a guardrail with a sensitive-information filter; enable model invocation logging to Amazon S3; use an IAM policy with a condition on the guardrail identifier; enable AWS CloudTrail; run a Lambda function to scan responses. Two of those are the complementary pair — the content control and the identity control. The logging options are attractive but answer a different question (evidence after the fact, not enforcement at the time), and the Lambda is the do-it-yourself distractor that a managed feature already covers.

Guessing, honestly

Because there is no penalty for a wrong answer, you should never leave a multiple-response question incomplete. If you are down to three candidates for two slots, pick the two that address different layers of the problem rather than two that address the same layer, and flag the item. That heuristic is not a guarantee, but it beats picking the two that sound most familiar.

The trade-off

Multiple-response items eat time. A five-option question requires you to evaluate five statements rather than four, and the all-or-nothing scoring tempts you to keep re-reading. Give them a hard ceiling — three minutes — then commit, flag and move on. A flagged item you return to with fifteen minutes left is far more likely to be recovered than one you agonised over at minute forty and still got wrong.

// The identity half of a typical complementary pair. Statement one limits
// WHICH models a role may invoke; statement two makes the approved guardrail
// non-optional. Together they answer "restrict model access AND enforce
// content filtering" — a classic "choose TWO" pairing.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOnlyApprovedModels",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:eu-west-1::foundation-model/amazon.nova-pro-v1:0",
        "arn:aws:bedrock:eu-west-1:111122223333:inference-profile/eu.amazon.nova-pro-v1:0"
      ]
    },
    {
      "Sid": "DenyInvokeWithoutTheApprovedGuardrail",
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "bedrock:GuardrailIdentifier": "arn:aws:bedrock:eu-west-1:111122223333:guardrail/abc123guard:3"
        }
      }
    }
  ]
}

// Note the two ARN shapes in the Allow: when you call through a
// cross-Region inference profile, the request is authorised against the
// PROFILE ARN as well as the underlying foundation model. Omitting one of
// them is a favourite distractor.