Refresh exam

PhotoRobot Integrator — Refresh Exam

25 questions · pass 75% · 45 min

Q1 scenario · i01-secret-leak · weight 2

Junior developer on your customer’s team commits a PhotoRobot API key to their public GitHub repo. You discover it 3 hours later.

A) Email PhotoRobot support and wait
B) (1) Immediately revoke + rotate the key; (2) audit application logs + PhotoRobot API call log for unauthorized calls during the 3-hour exposure window; (3) audit Git history for the key (delete doesn’t remove from history — assume permanently exposed); (4) retrain the developer + reinforce secrets-vault discipline. The key is gone forever; recovery is rotation + audit, not deletion from Git.
C) Delete the commit and force-push
D) Set the repo private and move on

Q2 scenario · i02-silent-failure · weight 2

Your webhook integration was working fine for 9 months. Then customer reports items aren’t reaching DAM. Investigation shows DAM started returning 500 for every webhook 5 weeks ago. PhotoRobot retried for ~24 hours per event, then stopped delivering. Subscription is in degraded state.

A) PhotoRobot bug — file ticket
B) Missing monitoring contract (named owner, alert thresholds, response-time SLA, tested failure). Recovery: fix DAM endpoint → re-enable subscription in Developer Portal → reconciliation poll for modified_since=<last-successful-delivery> to catch events during outage. Idempotent processing handles duplicates. Going forward: monitoring contract signed BEFORE integration goes back to production.
C) PhotoRobot should have alerted you sooner
D) Just re-enable subscription — events are lost

Q3 multiple-choice · i02-receiver-sequence

In what order does a correct webhook receiver process an incoming event?

A) Parse JSON → check user → save to DB → return 200
B) Verify signature → verify timestamp → dedup by event ID → fast acknowledge (< 2s) → enqueue async
C) Process inline → return 200 after
D) Decompress → decrypt → parse → route → respond

Q4 scenario · i03-csv-duplicates · weight 2

Customer’s catalog ETL pushes the same Excel CSV to PhotoRobot every Friday. 6 months in, you discover 30 % of items are duplicated — same product, different SKU formats (RED-SHIRT-M, red_shirt_m, Red-Shirt-M).

A) Switch to JSON
B) SKU canonicalization missing — your import handler isn’t normalizing SKUs before sending to PhotoRobot. Fix: add canonicalize step (trim + uppercase + strip non-alphanumeric + collapse separators) + maintain mapping table (canonical SKU ↔ PhotoRobot item ID) + use bulk import on_conflict: update. Document the canonicalization rule for the customer’s ERP team.
C) PhotoRobot should auto-merge — file ticket
D) Hard-delete duplicates manually

Explanation: Dedup is the integrator’s responsibility. PhotoRobot accepts SKUs as-provided. Without canonicalization + mapping table, identifier variants multiply into duplicate items. Fix structurally: canonicalization rule + mapping table + on_conflict: update for convergent re-imports.

Q5 multiple-choice · i01-rate-limit-pause

PhotoRobot returns HTTP 429. Which header indicates the recommended retry pause?

A) X-Wait-For
B) Retry-After
C) X-Rate-Reset
D) Cooldown-Seconds

Explanation: Retry-After is the canonical HTTP header (per RFC) for “wait N seconds before retrying.” Always honor it; combine with exponential backoff + jitter for resilience.

Q6 scenario · i02-receiver-back-pressure · weight 2

Your webhook receiver is being overwhelmed by an unexpected spike in events. Queue depth growing, workers can’t drain.

A) 200 OK — to prevent retries and absorb silently
B) 503 Service Unavailable — signals back-pressure honestly; PhotoRobot retries with backoff and replays events when you recover. 200 silently drops events.
C) 401 Unauthorized
D) 500 Internal Server Error

Q7 scenario · cross-foundation-before-tech · weight 2

New customer engagement: 200 studios, ERP team wants real-time API sync, marketing wants DAM auto-publish, IT wants single sign-on, CTO wants “Industry 4.0 in 90 days.”

A) Yes, build all of it
B) Convert deadlines into structured diagnostic. Phase 1 (Foundation per B26 §8): SKU→preset mapping (I03 §3), export template library (B22 §5), recipe audit. Without Phase 1, building API + DAM + SSO produces “occasional failures” pattern (Q48 of cert exam — foundation drift). Propose 30-day diagnostic; phased roadmap from there. Real answer may be 6-24 months; phased rollout with monitoring contracts per phase.
C) Refuse engagement
D) Hire more developers

Q8 multiple-choice · i03-external-id

What’s the role of external_id field on a PhotoRobot item?

A) PhotoRobot’s internal item identifier
B) Upstream system’s primary key — bridges PhotoRobot webhook (which tells you item.id) back to the upstream system’s record for status round-trip
C) Random UUID
D) Backup SKU

Explanation: external_id is the round-trip bridge. Without it, PhotoRobot webhook fires for an item but your handler can’t find the matching upstream record to update. Set it on every item created via integration.

Q9 scenario · i03-bulk-partial · weight 2

Bulk import returns HTTP 200, total 500, succeeded 487, failed 13. Your handler treats 200 as total success and moves on.

A) Status 200 means everything succeeded — no fix needed
B) Bulk imports return per-item results — status: 200 means the request was processed, not that all items succeeded. Handler must parse each result: record successes in mapping, retry retriable errors individually, surface non-retriable (validation, duplicate_sku) to human review. Partial success is normal.
C) Roll back the entire batch
D) Retry the entire batch

Q10 multiple-choice · i02-replay-window

What’s the recommended timestamp tolerance window for webhook replay protection?

A) ±0 seconds — exact match required
B) ±30 seconds
C) ±5 minutes
D) ±24 hours

Q11 scenario · i04-no-ocr-api · weight 2

Customer’s product team wants OCR-extracted ingredient lists available “within seconds of capture” via API call from their content management system.

A) Yes — wire it up via OCR API endpoint
B) Push back on the “within seconds via API” architecture. PhotoRobot OCR has NO API endpoint (per I04 §1) — it’s semi-automated (operator triggers in CAPP Cloud), output flows through item export’s data.json. Real-time API access doesn’t exist. Counter-propose: export-driven worker that watches the export destination, parses data.json, pushes to CMS via CMS’s API. Latency = minutes (not seconds), but matches actual architecture.
C) Build a custom OCR engine
D) Refuse the engagement

Q12 multiple-choice · i01-data-wrapper

V2 list endpoints wrap response under which JSON key?

A) Root (no wrapper)
B) data
C) results
D) items

Explanation: V2 envelope: { "data": [...], "meta": {...}, "links": {...} }. The biggest V1→V2 migration footgun — code reading response.id from V1 silently breaks on V2.

Q13 scenario · cross-monitoring-contract · weight 2

You’re inheriting an integration built 14 months ago by a developer who left the company. Customer reports it’s been working “mostly fine.” You audit and find: no error alerting, application logs rotated weekly so only last 7 days exist, no monitoring dashboard, no documented owner.

A) Rewrite integration from scratch
B) Sign a monitoring contract first — named owner (you, until reassigned), alert thresholds (per I02 §8 baselines), response-time SLA, log retention extended to ≥ 90 days, tested failure scenario. Then audit existing code for the canonical failure modes (canonicalization, idempotency, request_id logging, timeout handling). Don’t touch code before monitoring exists — you’ll create new failures without the ability to detect them.
C) Add unit tests
D) Refactor to TypeScript

Q14 multiple-choice · i03-discontinued

Customer’s ERP marks SKU as “discontinued.” Right PhotoRobot action?

A) Hard-delete immediately
B) Archive (PATCH status: archived + tag discontinued_date). Do NOT hard-delete — historical assets must remain accessible (past orders, support, legal). Hard deletes require explicit operator authorization for rare legitimate cases.
C) Wait 30 days then hard-delete
D) Move to “deleted” project

Q15 scenario · i02-idempotency-layers · weight 2

Customer reports duplicate DAM uploads after webhook retries. Your receiver dedups by event ID — yet duplicates appear.

A) Increase dedup retention from 48h to 7 days
B) Side-effect idempotency. Receiver dedup prevents duplicate processing of same delivery attempt; side-effect idempotency prevents duplicates at downstream. Fix: use item ID as DAM asset identifier — re-uploads overwrite instead of creating new entries. Both layers required.
C) Disable PhotoRobot retries
D) Switch DAM vendor

Q16 multiple-choice · b22-cloud-link-expiry

PhotoRobot Cloud export link validity period?

A) 24 hours
B) 48 hours
C) 7 days
D) 30 days

Q17 scenario · cross-when-not-to-build · weight 2

Customer requests custom real-time OCR pipeline + auto-publish + auto-email team for every item. Volume: 10 items/day.

A) Build it; charge premium
B) Push back on scope: (1) OCR has no real-time API (I04 §1) — “seconds of capture” not achievable; (2) 10/day is below industrialization threshold (B26 §4); (3) auto-email per item = notification noise. Counter-propose: nightly batch export + parse OCR data.json + push to e-commerce once daily + summary email of day’s items. Same business value, vastly less complexity.
C) Yes — build all of it
D) Refuse engagement

Q18 multiple-choice · i01-jitter-rationale

Why use jitter in exponential backoff for API retries?

A) Makes retries faster
B) Required by HTTP spec
C) Without jitter, concurrent integrations retry simultaneously after a 429, overloading the recovery window — jitter spreads them across a wider window
D) Logs are clearer

Explanation: Many clients with deterministic backoff = synchronized retry herd that re-triggers rate limits. Random jitter (e.g., Math.random() * 1000ms) spreads the herd across the recovery window.

Q19 scenario · i02-signature-failure · weight 2

Webhook receiver suddenly returning 401 Invalid Signature for every delivery. Secret hasn’t changed. Worked yesterday.

A) PhotoRobot changed signing scheme
B) TLS certificate expired
C) New middleware was added that parses the request body before signature verification — body is no longer raw bytes the HMAC was computed against (most common: express.json() added before express.raw()). Fix: capture raw body BEFORE any JSON / URL-encoded parser.
D) Clock drift exceeded 5 minutes

Explanation: Raw body integrity is fragile. HMAC was computed over exact bytes PhotoRobot sent; any middleware that re-parses (normalizing whitespace, re-stringifying JSON) breaks verification. Most common: forgotten express.raw({ type: 'application/json' }) before express.json().

Q20 multiple-choice · i04-data-json-format

OCR text in data.json is returned as:

A) Structured fields per language
B) Array of raw text strings per frame — extractedOcrData: ["INGREDIENTS: ...", "Net weight: ...", ...]
C) PDF attached separately
D) Markdown with semantic headers

Q21 scenario · b26-bottleneck-pattern · weight 2

Customer’s studio could shoot 30 % more items/day if more came in. Operators not at capacity. Downstream publishing fast.

A) Pattern A — Volume / upstream. Stage 1 (Scan & Measure) automation: ERP-pushed shooting lists, barcode scanning at receiving, batch RFID.
B) Pattern B — Operator. Automate capture and edit.
C) Pattern C — Delivery. Automate Stage 5.
D) Balanced — no automation needed.

Q22 scenario · cross-occasional-failures · weight 2

6 months into a complex integration: customer reports occasional duplicate DAM uploads, sometimes items missing from e-commerce catalog, occasionally items in wrong project. No single thing is broken — everything works “most of the time.”

A) Switch DAM vendor
B) Rebuild from scratch
C) Cross-module symptom of foundation drift. Check (1) SKU canonicalization rule applied uniformly across all import paths (I03 §3); (2) idempotency at BOTH receiver dedup AND side-effect layers (I02 §5); (3) project structure routing logic vs. current customer ERP categorization (I03 §7). Each “occasional” failure typically maps to one canonicalization-or-idempotency-or-routing gap.
D) Add more retries

Q23 multiple-choice · b26-monitoring-contract-4

A monitoring contract for a production integration minimally includes:

A) Signed SLA with PhotoRobot
B) Named person who notices when integration breaks, named fixer, response-time SLA, tested failure scenario
C) Slack channel
D) Cloudflare monitoring dashboard

Q24 scenario · i01-secret-storage · weight 2

New team member asks: “where do I put the PhotoRobot API key for the new integration project?”

A) Hardcode in source file, comment “rotate later”
B) Config.json in repo
C) Secrets vault (env variable, AWS Secrets Manager, GitHub Actions secret, etc.) — server-side only, never in source code, never in client-side JS, never logged. Rotate on personnel change + every 90 days.
D) Browser localStorage

Ready to commit? You can review and change your answers before submitting. Once submitted, this attempt is final and we'll show you your score, correct answers, and explanations.