Platform availability, and the decision table
Last lesson of the course, and it is the one that quietly overrules the other nine. Every capability you have learned is conditional on where you deploy.
This is the target-platform problem you already know from every other part of engineering. The language has the feature, the runtime you ship to does not, and you find out at the end. Here the gap is not syntax, it is entire modules of this course.
The gap list
Not available on Bedrock or Vertex:
- Files API
- Skills
- The MCP connector
- Code execution
- Web fetch
- Programmatic tool calling
The MCP connector is available on Foundry. So “MCP does not work on cloud platforms” is too broad a summary, and being sloppy about that is how you talk yourself out of a valid architecture.
The one that breaks the pattern
Web search is available everywhere except Bedrock. Vertex has it.
Compression is the failure mode worth naming, because it is not laziness. Six facts that all point the same way genuinely should collapse into one rule; that is how you are supposed to learn. The exam writer knows that, and the seventh fact is where the marks are. Carry this list as six plus one, never as seven.
Read the table before the design, not after
Look at what is actually in that list. Skills, code execution, the MCP connector: those are not garnish, they are three of the four modules of this course. A platform decision made for procurement reasons can delete most of your architecture, and it usually gets made by someone who was not in the design conversation.
So the order of operations is: know the deployment target first, then design. If the answer is Bedrock, you are building tools by hand, you are not using Skills, and you have no web access through these tools at all. That is a perfectly workable agent. It is just a different one, and finding out at integration time is expensive.
The whole course, as one sequence
Pick the product, because it decides who writes the loop. Pick the pattern, and be honest about whether you needed an agent at all. Pick the model, capability first. Build the loop: stop_reason, tool_use, results back as a user message. Define tools carefully, put strict on the definition and disable_parallel_tool_use on tool_choice. Reach for built-ins before writing your own, and know what they cost. Use MCP with both objects present. Then check the platform table, and be ready to redo any of it.
Try it yourself
Where web search runs
Web search has a different availability story from the rest of the list, which is exactly why it makes a good question.
Show answer
Correct answer: C — Everywhere except Bedrock
Web search is available everywhere except Bedrock. The like-the-MCP-connector answer is the designed trap: most of the gaps on this topic hit Bedrock and Vertex together, so pattern-matching gets you the wrong answer on the one item that breaks the pattern. Vertex has web search. Vertex does not have web fetch. They are separate facts.
The Bedrock and Vertex gap list
The list is most of this lesson, and one of its members behaves differently from the rest. Scope is availability only, not what each feature does.
Which features are missing on Bedrock and Vertex, and which feature has a different story?
Reveal answer
Files API, Skills, the MCP connector, code execution, web fetch, and programmatic tool calling are all unavailable on Bedrock and Vertex. Web search is the odd one out: unavailable on Bedrock only, so Vertex has it. The MCP connector is available on Foundry.
Procurement says Bedrock
Your design uses Agent Skills, the MCP connector, web search and web fetch. The deployment target has just been fixed as Bedrock. What survives?
Show answer
Correct answer: B — You lose all four, because web search is unavailable on Bedrock specifically
Bedrock is the single platform where web search is also missing, so all four of these go. The first option is the trap and it is a precise one: it is the correct answer for Vertex, which does have web search and does not have web fetch. Producing Vertex's answer to a Bedrock question is exactly the failure the odd-one-out fact exists to prevent, and it is what happens when you compress the gap list into one rule about cloud platforms. Skills and the MCP connector are unavailable on both.
Two minutes, docs open, does it run on Bedrock
A question turns on whether a feature you have not memorised is available on Bedrock, and you are semi-open-book with the clock running.
Show answer
Correct answer: D — The feature's own page, and its platform availability section
Availability is documented feature by feature, so the fastest reliable route is the page for the feature the question is about. The provider-overview answer is the tempting one, because a single authoritative list would be the better design and you will go looking for it, but an absence from an overview page is weak evidence: you cannot distinguish unsupported from merely undocumented, and on a timed paper weak evidence is worse than no lookup at all. Pricing does not track availability, and the model comparison table compares models rather than platform capability.
Cross off your own design
Take the agent you specced in the capstone brief and put it on Bedrock.
A list of every feature you would lose, and a decision: redesign, or pick a different platform. If nothing on your design touches the gap list, say so explicitly, because that is a real and useful finding rather than a failed exercise.